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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-05-30 at 12:04 -0400, 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.

Yes, at the very least the manpages...

> > 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.

Yes, which most likely involves preseeding the guest RAM with the files
at a discoverable location. Icky.

Ian.


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