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

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 6/3/2014 at 12:58 AM, in message
<20140602165836.GD5127@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote: 
> 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 :-) 

Thanks. Understand. All files including 'kernel', 'initrd' and 'linuxboot.bin' 
could not be
accessed directly in stubdom-dm. Have to find a way to let qemu discover them.
I'll look at and see how to properly handle it. 

Now I wonder how does it handle device? (A backend file or partition is also a 
place
on host.) Stubdom uses qemu-xen-traditional, maybe there is some special 
handling?
Will have a look.

- Chunyan
> >  
> > Ian. 
> >  
>  
> _______________________________________________ 
> 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