Re: [Xen-devel] [Draft A] Boot ABI for HVM guests without a device-model

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

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