| Message ID | 20200519190230.29519-23-ian.jackson@eu.citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Upgrade most hosts/guests to buster | expand |
Hi Ian, On 19/05/2020 20:02, Ian Jackson wrote: > CC: Julien Grall <julien@xen.org> > CC: Stefano Stabellini <sstabellini@kernel.org> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Julien Grall <jgrall@amazon.com> > --- > Osstest/Debian.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm > index 6fed0b75..77508d19 100644 > --- a/Osstest/Debian.pm > +++ b/Osstest/Debian.pm > @@ -1064,7 +1064,7 @@ END > logm("\$arch is $arch, \$suite is $suite"); > if ($xopts{PvMenuLst} && > $arch =~ /^arm/ && > - $suite =~ /wheezy|jessie|stretch|sid/ ) { > + $suite =~ /wheezy|jessie|stretch|buster|sid/ ) { > > # Debian doesn't currently know what bootloader to install in > # a Xen guest on ARM. We install pv-grub-menu above which OOI, what does Debian install for x86 HVM guest? Is there any ticket tracking this issue? Cheers,
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"):
> On 19/05/2020 20:02, Ian Jackson wrote:
> > CC: Julien Grall <julien@xen.org>
> > CC: Stefano Stabellini <sstabellini@kernel.org>
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> Acked-by: Julien Grall <jgrall@amazon.com>
Thanks.
> > # Debian doesn't currently know what bootloader to install in
> > # a Xen guest on ARM. We install pv-grub-menu above which
>
> OOI, what does Debian install for x86 HVM guest? Is there any ticket
> tracking this issue?
On x86, it installes grub. (grub2, x86, PC, to be precise.)
I'm not aware of any ticket or bug about this.
Ian.
Hi Ian, On 20/05/2020 15:57, Ian Jackson wrote: > Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"): >> On 19/05/2020 20:02, Ian Jackson wrote: >>> CC: Julien Grall <julien@xen.org> >>> CC: Stefano Stabellini <sstabellini@kernel.org> >>> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> >> >> Acked-by: Julien Grall <jgrall@amazon.com> > > Thanks. > >>> # Debian doesn't currently know what bootloader to install in >>> # a Xen guest on ARM. We install pv-grub-menu above which >> >> OOI, what does Debian install for x86 HVM guest? Is there any ticket >> tracking this issue? > > On x86, it installes grub. (grub2, x86, PC, to be precise.) I have just realized that on x86 you will always have a firmware in the guest. On Arm we commonly boot the kernel directly. So maybe we are closer to PV here. Do you also install GRUB in that case? Note that we do support EDK2 at least on Arm64. It would be nice to get some tests for it in Osstest in the future. > I'm not aware of any ticket or bug about this. It might be worth creating one then.
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"):
> On 20/05/2020 15:57, Ian Jackson wrote:
> > Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"):
> >> On 19/05/2020 20:02, Ian Jackson wrote:
> >>> # Debian doesn't currently know what bootloader to install in
> >>> # a Xen guest on ARM. We install pv-grub-menu above which
> >>
> >> OOI, what does Debian install for x86 HVM guest? Is there any ticket
> >> tracking this issue?
> >
> > On x86, it installes grub. (grub2, x86, PC, to be precise.)
>
> I have just realized that on x86 you will always have a firmware in the
> guest. On Arm we commonly boot the kernel directly.
Yes. At leave, for HVM.
> So maybe we are closer to PV here. Do you also install GRUB in that case?
It's Complicated. There are several options, but the usual ones are:
1. pygrub: Install some version of grub, which generates
/boot/grub.cfg. It doesn't matter very much which version of grub
because grub.cfg is read by pygrub in dom0 and that fishes out the
kernel and initrd. Many of osstest's tests do this.
2. host kernel: Simply pass the dom0 kernel *and initramfs* as the
kernel image to the guest. This works if the kernel has the right
modules for the guest storage, which it can easily do. On x86 an
amd64 kernel can run an i386 userland.
3. pvgrub.
> Note that we do support EDK2 at least on Arm64. It would be nice to get
> some tests for it in Osstest in the future.
Is this the same as "EADK" ? I'm afraid I don't follow...
> > I'm not aware of any ticket or bug about this.
>
> It might be worth creating one then.
Where should I do that ? I guess I mean, in which bugtracker ?
Thanks,
Ian.
Hi, On 28/05/2020 15:53, Ian Jackson wrote: > Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"): >> On 20/05/2020 15:57, Ian Jackson wrote: >>> Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"): >>>> On 19/05/2020 20:02, Ian Jackson wrote: >>>>> # Debian doesn't currently know what bootloader to install in >>>>> # a Xen guest on ARM. We install pv-grub-menu above which >>>> >>>> OOI, what does Debian install for x86 HVM guest? Is there any ticket >>>> tracking this issue? >>> >>> On x86, it installes grub. (grub2, x86, PC, to be precise.) >> >> I have just realized that on x86 you will always have a firmware in the >> guest. On Arm we commonly boot the kernel directly. > > Yes. At leave, for HVM. > >> So maybe we are closer to PV here. Do you also install GRUB in that case? > > It's Complicated. There are several options, but the usual ones are: > > 1. pygrub: Install some version of grub, which generates > /boot/grub.cfg. It doesn't matter very much which version of grub > because grub.cfg is read by pygrub in dom0 and that fishes out the > kernel and initrd. Many of osstest's tests do this. > > 2. host kernel: Simply pass the dom0 kernel *and initramfs* as the > kernel image to the guest. This works if the kernel has the right > modules for the guest storage, which it can easily do. On x86 an > amd64 kernel can run an i386 userland. > > 3. pvgrub. Thanks for the explanation. How do you select it in the Osstest today? Is it a option for the debian installer or you do it manually as part of your install script? >> Note that we do support EDK2 at least on Arm64. It would be nice to get >> some tests for it in Osstest in the future. > > Is this the same as "EADK" ? I'm afraid I don't follow... Sorry, I should have been more precise. I meant that we are able to boot a Arm guest using UEFI as we added support in EDK2 (I think in Xen we use the term ovmf). When using EFI, the guest can boot exactly the same way as it would on baremetal. The toolstack is just loading the firmware in the guest memory. IIRC we have already regular EFI testing on x86 in Osstest. I am thinking to extend them to Arm at some point. > >>> I'm not aware of any ticket or bug about this. >> >> It might be worth creating one then. > > Where should I do that ? I guess I mean, in which bugtracker ? From the comment in the code, I would assume this is a bug/enhancement against the Debian installer. But I may have misundertood it. Cheers,
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"):
> On 28/05/2020 15:53, Ian Jackson wrote:
> > It's Complicated. There are several options, but the usual ones are:
> >
> > 1. pygrub: Install some version of grub, which generates
> > /boot/grub.cfg. It doesn't matter very much which version of grub
> > because grub.cfg is read by pygrub in dom0 and that fishes out the
> > kernel and initrd. Many of osstest's tests do this.
> >
> > 2. host kernel: Simply pass the dom0 kernel *and initramfs* as the
> > kernel image to the guest. This works if the kernel has the right
> > modules for the guest storage, which it can easily do. On x86 an
> > amd64 kernel can run an i386 userland.
> >
> > 3. pvgrub.
>
> Thanks for the explanation. How do you select it in the Osstest today?
I think osstest does all three (not very sure about (2). Installs
made with the Debian xen-tools package tend to do (2) by default.
Installs made with d-i can do (2) or (3).
> > Is this the same as "EADK" ? I'm afraid I don't follow...
>
> Sorry, I should have been more precise. I meant that we are able to boot
> a Arm guest using UEFI as we added support in EDK2 (I think in Xen we
> use the term ovmf).
Right.
> When using EFI, the guest can boot exactly the same way as it would on
> baremetal. The toolstack is just loading the firmware in the guest memory.
>
> IIRC we have already regular EFI testing on x86 in Osstest. I am
> thinking to extend them to Arm at some point.
Our arm64 boxes are all booting via UEFI right now.
We have to do a different bodge to load xen.efi rather than grub;
osstest makes a xen.cfg. That bodge is extended to buster by
Subject: [OSSTEST PATCH 34/38] buster: grub, arm64: extend
chainloading workaround
> > Where should I do that ? I guess I mean, in which bugtracker ?
>
> From the comment in the code, I would assume this is a bug/enhancement
> against the Debian installer. But I may have misundertood it.
Oh I see. I think amybe the problem was the lack of grub support. Is
that all sorted in current Debian unstable/testing ? If so it may
well all come out in the wash.
Ian.
Hi, On 28/05/2020 16:41, Ian Jackson wrote: > Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader workaround"): >> On 28/05/2020 15:53, Ian Jackson wrote: >>> It's Complicated. There are several options, but the usual ones are: >>> >>> 1. pygrub: Install some version of grub, which generates >>> /boot/grub.cfg. It doesn't matter very much which version of grub >>> because grub.cfg is read by pygrub in dom0 and that fishes out the >>> kernel and initrd. Many of osstest's tests do this. >>> >>> 2. host kernel: Simply pass the dom0 kernel *and initramfs* as the >>> kernel image to the guest. This works if the kernel has the right >>> modules for the guest storage, which it can easily do. On x86 an >>> amd64 kernel can run an i386 userland. >>> >>> 3. pvgrub. >> >> Thanks for the explanation. How do you select it in the Osstest today? > > I think osstest does all three (not very sure about (2). Installs > made with the Debian xen-tools package tend to do (2) by default. > Installs made with d-i can do (2) or (3). > >>> Is this the same as "EADK" ? I'm afraid I don't follow... >> >> Sorry, I should have been more precise. I meant that we are able to boot >> a Arm guest using UEFI as we added support in EDK2 (I think in Xen we >> use the term ovmf). > > Right. > >> When using EFI, the guest can boot exactly the same way as it would on >> baremetal. The toolstack is just loading the firmware in the guest memory. >> >> IIRC we have already regular EFI testing on x86 in Osstest. I am >> thinking to extend them to Arm at some point. > > Our arm64 boxes are all booting via UEFI right now. > > We have to do a different bodge to load xen.efi rather than grub; > osstest makes a xen.cfg. That bodge is extended to buster by > > Subject: [OSSTEST PATCH 34/38] buster: grub, arm64: extend > chainloading workaround We should also be able to use EFI in the guest directly as well :). > >>> Where should I do that ? I guess I mean, in which bugtracker ? >> >> From the comment in the code, I would assume this is a bug/enhancement >> against the Debian installer. But I may have misundertood it. > > Oh I see. I think amybe the problem was the lack of grub support. Is > that all sorted in current Debian unstable/testing ? If so it may > well all come out in the wash. I haven't tried a recent Debian installer on Xen on Arm. I will have a try and see what it installs now. Cheers,
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm index 6fed0b75..77508d19 100644 --- a/Osstest/Debian.pm +++ b/Osstest/Debian.pm @@ -1064,7 +1064,7 @@ END logm("\$arch is $arch, \$suite is $suite"); if ($xopts{PvMenuLst} && $arch =~ /^arm/ && - $suite =~ /wheezy|jessie|stretch|sid/ ) { + $suite =~ /wheezy|jessie|stretch|buster|sid/ ) { # Debian doesn't currently know what bootloader to install in # a Xen guest on ARM. We install pv-grub-menu above which
CC: Julien Grall <julien@xen.org> CC: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> --- Osstest/Debian.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)