[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] more segment/selector handling woes
> -----Original Message----- > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Jan Beulich > Sent: 22 November 2006 13:08 > To: Petersson, Mats > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Xen-devel] more segment/selector handling woes > > >> Note the wording 'as if' - this doesn't tell me whether the > >> internal base > >> address field (which gets stored to the vmcb) can indeed be > >> relied upon. > >> But obviously the code would be simpler if that was the case > >> in reality > >> (and then perhaps the documentation could be updated accordingly). > > > >I believe it would contain whatever is in the [GL]DT... It's > ignored by > >the processor (treated as zero). So, you'd have to check if > it's GS/FS > >or not, and then use either 0 or [fg]s.base accordingly. > > Can you verify this with you hardware guys? It would mean that I'd > also have to change the implementation of get_segment_base() > that I introduced with a patch yesterday. I'll check with someone. I'll hopefully have a reply early afternoon, but no guarantees... > > >Note that one bit in EFER also allows limits for 64-bit > segments, but I > >think it's only ever used by VMWare, so it's probably OK to > ignore the > >limits completely (in 64-bit mode at least). > > Is this being detailed anywhere? Namely, whether there's a CPUID > feature flag for this (or is it always available), and how one would > obtain 64-bit wide limits? I merely can see the flag being defined in > the NPT BIOS And Kernel Developer's Guide (the public > Programmer's Manual doesn't even know this). There's no 64-bit segment limit, it's a 32-bit value (actually 20 bit, with an optional 12 bit shift-and-fill-with-ones) just as in 32-bit mode. There's no other public documentation at the moment. I've seen a presentation set that describes it in more detail, I'll see if I can dig that out [and see if it's marked "NDA" or not!]. It's safe to ignore it for now, I should think. -- Mats > > Jan > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |