|
[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 15.18, Andrew Cooper ha escrit: >> * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits >> are all undefined. > > "unspecified" is perhaps better phrasing. Most will be 0, but ET will > be set as it is a read-only bit in all processors Xen will function on > these days. OK. I think we can say that: * cr0: bit 0 (PE) and bit 4 (ET) will be set. All the other bits are cleared. > Perhaps also worth calling out cr4 as well, which typically starts as > all zeroes. * cr4: all bits are cleared. >> >> * cs: must be a 32-bit read/execute code segment with an offset of â0â >> and a limit of â0xFFFFFFFFâ. The exact value is undefined. >> >> * ds, es, fs, gs, ss: must be a 32-bit read/write data segment with an >> offset of â0â and a limit of â0xFFFFFFFFâ. The exact values are all >> undefined. > > I would be tempted to only define ds and possibly es. Any code using > this boot protocol will load its gdt and reload the segments in very > short order, and ss is useless until esp has been set up appropriately. I would rather prefer to have ss already defined according to the above text, this way you just need to load a valid stack into esp, but I'm not going to strongly argue about it. >> 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |