Re: [Xen-devel] [Qemu-devel] [RFC PATCH 0/2] support xen HVM direct kernel boot

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 30 May 2014, Konrad Rzeszutek Wilk wrote:
> On Thu, May 29, 2014 at 11:23:22AM +0800, Chunyan Liu wrote:
> > Following previous discussion:
> > https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg03843.html
> > 
> > I spent lot of time to understand xen xc_hvm_build, hvmloader code,
> > and qemu pc_memory_init, xen_ram_init code, and wrote experimental
> > code to test. Now it's basically working based on seabios.
> 
> Excellent!
> > 
> > Talking about qemu linuxboot.bin/multiboot.bin first, they are
> > implemented to intercept boot process, originally by override int19,
> > later changed to provide BEV entry which will be called by seabios
> > if option rom is selected for booting. linuxboot.bin/multiboot.bin
> > will load kernel/initrd and jump to execute kernel directly.
> > 
> > In qemu load_linux() code, it first read out kernel/initrd file and
> > store related ADDRs to fw_cfg (from where linuxboot.bin/multiboot.bin
> > will get the ADDRs and load kernel/initrd data), then add
> > linuxboot.bin/multiboot.bin to option rom with bootindex=0.
> > 
> > In seabios side, it could load and execute ROMs by itself, and according
> > to boot order, it will boot from the BEV entry on the option rom. That
> > will then be taken over by linuxboot.bin/multiboot.bin.
> > 
> > So, in theory, qemu load_linux() code almost does the work. I just tried
> > to reuse it for xen.
> > 
> > xen side patch: pass kernel/initrd/append parameters to qemu-dm
> > qemu side patch: reuse load_linux() for xen hvm direct kernel boot.
> >     Different from pc_memory_init which does lots of ram alloc work
> >     and rom/bios loading work, for xen, we only need to init a basic
> >     fw_cfg device used by load_linux() to store ADDRs and
> >     linuxboot.bin/multiboot.bin to retrive ADDRs, then load_linux(),
> >     after that, do real add option rom work to add
> >     linuxboot.bin/multiboot.bin to system option rom. Other things
> >     would be done by seabios smoothly.
> > 
> > In my testing, it's working based on seabios.
> > Rombios case is not working. But now that xen prefers qemu upstream,
> > seabios will be default, do we need to put effort to make rombios work?
> 
> No. But the code (libxl) should detect whether you are using the
> traditional QEMU - which would be using ROM BIOS. If it detects that
> it shouldn't allow you to pass the arguments.
> 
> You probably will also need to an docs/ change to document these
> new parameters.
> > And stubdom case, since I didn't make my guest started even without direct
> > kernel boot, I don't know if it works. And I still could not well
> > understand about the differences to stubdom and non stubdom this work
> > may cover. Any problems please point out.
> 
> Hmm, you would have to somehow 'transfer' the images from one domain
> (the control domain) to the stubdomain which would do the execution.
> 
> At least the multiboot.bin image.

Yeah, unfortunately the approach of implemeting direct kernel boot for
HVM guests via QEMU wouldn't work for stubdomains.

If we want this to work with stubdoms, it would be best to reimplement
kernel and initrd loading in libxl/libxc.

I have to admit that given the extreme simplicity of this patch series,
I wouldn't be against merging it, even if it cannot be made to work with
stubdoms.  However like in the rombios case, libxl would need to
understand that this feature doesn't work with stubdoms and print an
appropriate message.


> > Personally I'm not quite familiar with the details in this part of code,
> > so there might be things not considered, or there might be better method.
> > I'm very willing to hear suggestions to improve the work. Any comment or
> > feedback would be very appreciated! Thanks.
> >  
> > Chunyan Liu (2):
> >   xen: pass kernel initrd to qemu
> >   qemu: support xen hvm direct kernel boot
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel