[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Discussion: xen hvm guest direct kernel boot
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? > 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 > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |