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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Jun 02, 2014 at 04:19:31PM +0100, Ian Campbell wrote:
> 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.

Or some form of FTP over XenBus :-)
> 
> Ian.
>