[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Draft A] Boot ABI for HVM guests without a device-model
El 10/06/15 a les 17.57, Andrew Cooper ha escrit: >>>> Do we want to keep using the start_info page? Most of the fields there >>>> are not relevant for auto-translated guests, but without it we have to >>>> figure out how to pass the following information to the guest: >>>> >>>> - Flags: SIF_xxx flags, this could probably be done with cpuid instead. >>>> - cmd_line: ? >>>> - console mfn: ? >>>> - console evtchn: ? >>>> - console_info address: ? >>> All console information should be available from the HVMPARAMS. I see >>> no reason to prevent a PVH guest getting at these. >>> >>> This just leaves the command line being awkward. >> I've forgot to add the kernel payload (initramfs), which could also be >> fetched using a HVMPARAM, so that just leaves the cmd_line, which could >> be passed as a physical memory address in one of the gp registers. I >> don't have a strong opinion on whether we should create a new >> hvm_start_info struct that contains those, or whether we should just add >> new HVMPARAMS. > > I should have remembered as well, as I have a curiously-pvh-like usecase > which wants similar bits. > > The reason I suggested multiboot was for modules and command line > support. If we are not going for exactly multiboot, but something > similar, we might want to make a pvh_start_info with a module list and > cmdline pointer in it. I don't think we can go for multiboot as-is. It implicitly requires an ELF32 binary unless you want to setup the address header of multiboot, and even in that case it lacks a proper way to load a symtab/strtab for example, which the generic Xen ELF loader has. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |