Re: [Qemu-devel] [Xen-devel] Discussion: xen hvm guest direct kernel boot

[Ian Campbell]

On Mon, 2014-04-28 at 16:36 +0100, Ian Campbell wrote:
> On Fri, 2014-04-25 at 01:08 -0600, Chun Yan Liu wrote:
> > Hi, 
> > 
> > I'm looking at xen hvm guest direct kernel boot and interested to do
> > it. I found there were some discussions about it and an early work
> > around by Daniel (based on xen qemu-dm).
> > [1]http://old-list-archives.xenproject.org/xen-devel/2011-08/msg00414.html
> > [2]http://old-list-archives.xenproject.org/archives/html/xen-devel/2007-12/msg00723.html
> > 
> > In xen, the BIOS is provided by hvmloader, which is loaded to RAM in
> > libxc. When hvmloader finishes, it jumps to BIOS entry point. BIOS
> > will probe for MBR from qemu disk, through grub loading kernel and
> > initrd to correct address and then start the guest kernel.
> > 
> > In [2], the work around implementation is to pass kernel and initrd
> > to qemu, qemu reads kernel and initrd to certain address and generate
> > a boot sector on the 1st disk for BIOS probing.
> > 
> > But in current qemu code, the load_linux() way is different. It reads
> > kernel and initrd to certain address, then put linuxboot.bin and
> > multiboot.bin to option roms which will intercept boot process, so
> > that boot process will jump to linuxboot.bin/multiboot.bin instead
> > of normal int19 probing MBR stage. This sounds much cleaner then
> > generating a boot sector. And in current xen hvmloader, it uses
> > seabios, which is also the one upstream qemu uses.
> > 
> > So, back to xen direct kernel boot, I wonder if not generate a boot
> > sector for BIOS probing, could we break hvmloader limitation and
> > borrow qemu load_linux() way to achieve the goal? Then, where is the
> > right place to load the kernel and initrd, any way to intercept boot
> > process?
> 
> The option ROM way does sound like a neater mechanism. The only issue I
> can think of is that it may be incompatible with putting qemu into a
> stubdom, because it requires that qemu can read the file from disk.
> 
> For save restore I think the same problem is solved by wiring the save
> file up to a qemu chr device attached to a secondary PV console, so qemu
> within the stubdom can stream the save image once. Perhaps something
> similar could be done here?

Or, perhaps the firmware table stuff in xc_hvm_build_args (used for
adding extra firmware tables) could be extended to cause the kernel
+initrd to end up in some know location for seabios/qemu/someone to pick
up?

> 
> >  Could we touch hvmloader?
> 
> If the patches are clean I don't see why not, but solving it in qemu
> sounds like it could be cleaner, at least for the 10,000 foot view I
> have of it right now.
> 
> > My knowledge is limited in this part. Welcome experts' clues or ideas
> > or discussions. Thanks.
> > 
> > Regards,
> > Chunyan
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > address@hidden
> > http://lists.xen.org/xen-devel
>