[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
>>> On 10.06.15 at 16:53, <roger.pau@xxxxxxxxxx> wrote: > El 10/06/15 a les 15.15, Jan Beulich ha escrit: >>>>> On 10.06.15 at 14:34, <roger.pau@xxxxxxxxxx> wrote: >> For my taste, it's getting too >> close to something that could be a legitimate 32-bit kernel pointer >> (agreed, all values could be valid pointers in 32-bit OSes, but with >> OSes tending to place themselves high in memory, a value numerically >> closer to what multiboot1 uses would seem more desirable). > > I don't have any strong opinions here, does the following seem more > suitable: > > 0x336ec578 ("xEn3" with the 0x80 bit of the "E" set) > > (from xc_dom_binloader.c) That would seem fine to me. >>> * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits >>> are all undefined. >> >> I see that grub1 documentation says so, but I doubt this is realistic >> (even less so for cr4 bits): Some of the bits (including ones not >> currently defined) may have a meaning even in non-paged protected >> mode, and the environment should be as completely defined as possible. >> I.e. I think most other bits should be defined to be zero upon handoff. >> >>> * 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. >> >> I guess "exact value" really means "selector value". > > I think so, it's a literal copy from the multiboot1 spec. In which case let's please try to be more accurate. >>> Comments for further discussion: >>> >>> 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: ? >> >> Yeah, settling on ideally a reasonably arch-independent mechanism >> that doesn't place undue constraints on future ports would be nice. >> And considering a hypothetical variant of x86 Xen not supporting PV >> guests anymore, this would no longer define XEN_HAVE_PV_GUEST_ENTRY >> and hence no longer have a struct start_info. So from a puristic pov >> the information should indeed be conveyed another way. > > What about the following layout: > > struct hvm_start_info { I mean, if you want to go with another structure, then I can't see why you wouldn't want to use what is there. I was rather understanding you'd like to go without any such structure, and would allow the guest to retrieve the respective data another way (CPUID, HVM param, ...). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |