On Wed, 2023-10-25 at 19:56 +0100, Andrew Cooper wrote: > On 25/10/2023 7:26 pm, David Woodhouse wrote: > > > On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote: > > > > > On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote: > > > > > > > > > + > > > > +Booting Xen PV guests > > > > +--------------------- > > > > + > > > > +Booting PV guest kernels is possible by using the Xen PV shim (a > > > > version of Xen > > > > +itself, designed to run inside a Xen HVM guest and provide memory > > > > management > > > > +services for one guest alone). > > > > + > > > > +The Xen binary is provided as the ``-kernel`` and the guest kernel > > > > itself (or > > > > +PV Grub image) as the ``-initrd`` image, which actually just means the > > > > first > > > > +multiboot "module". For example: > > > > + > > > > +.. parsed-literal:: > > > > + > > > > + |qemu_system| --accel kvm,xen-version=0x40011,kernel-irqchip=split \\ > > > > + -chardev stdio,id=char0 -device xen-console,chardev=char0 \\ > > > > + -display none -m 1G -kernel xen -initrd bzImage \\ > > > > + -append "pv-shim console=xen,pv -- console=hvc0 > > > > root=/dev/xvda1" \\ > > > > + -drive file=${GUEST_IMAGE},if=xen > > > Is the space between -- and console= intentionsl? > > Yes, that one is correct. The -- is how you separate Xen's command line > > (on the left) from the guest kernel command line (on the right). > > To expand on this a bit. > > Multiboot1 supports multiple modules but only a single command > line. As one of the modules passed to Xen is the dom0 kernel, we > need some way to pass it's command line, hence the " -- ". > > Multiboot2 and PVH support a command line per module, which is the > preferred way to pass the commandlines, given a choice. >
Thanks. Indeed, I had *originally* thought I was going to need to implement Multiboot2 in qemu in order to boot Shim + PV guest, but it turns out we can make it work with just Multiboot1 support. As long as the guest kernel doesn't want an *actual* initrd, that is ;)
smime.p7s
Description: S/MIME cryptographic signature