[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 11:45 > To: Petersson, Mats > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Xen-devel] more segment/selector handling woes > > >> Not only on VMX and in generic code, but also on SVM now: > >> svm_get_io_address() uses the segment base only when the guest > >> is not in long mode - what if outs has an fs/gs override? > I'm pretty > >> sure the base address is needed then, which opens the question - > >> does the CPU guarantee a valid (zero) base also for the other > >> segment register, or does this need to be conditionalized? > > > >Good question. I think you've found a bug, fs/gs should be taken into > >consideration in 64-bit mode. > > > >The x86-64 architecture "guarantees" that the base is zero > in long-mode. > > > > > >More precisely, page 110 in the December 2005 AMD64 PRM Vol 2: > >* In data-segment descriptors referenced by DS, ES and SS segment > >registers, the base-address field is ignored,. For the purpose of > >virtual-address calculations, the base address is treates as > if it has a > >value of zero. > > 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). > > >> Further, in the same function (and likely elsewhere) the injection > >> of GP faults seems pretty pointless - if either of the two > >> conditions is true, then the CPU itself should have raised a GP > >> fault for the guest already (i.e. execution flow would never get > >> here). > > > >INS/OUTS will be checked by the processor for the first > access only in > >the virtualized case, whilst the range is checked on every > iteration of > >the instruction in the "real" processor case. Since we only take one > >intercept for the first operation and then does as much as > possible (up > >to a page boundary), it's possible that the code would be faulty and > >make GP fault on the consecutive accesses. Of course, if you > trust the > >code to be correct, then it's fine to eliminat the GP fault > checking - > >but I put those in there to make sure that the virtual model > is as close > >to the real processor as possible. They shouldn't fire very > often, I'm > >sure... ;-) > > But that isn't really done: svm_get_io_address() gets called once > from svm_io_instruction(), and then up to a full page is being copied. > The next part is copied only after having returned to the guest and > having received the next exit. > Further, even if the checks were done for each iteration, the present > bit check would still be useless, only the limit check then > is relevant > (and should supposedly be done only when count > 1). I agree that the limit check is the "necessary" part of the check. There is no need to check present, as that's (unless someone is changing the descriptor table - and even so, it wouldn't really make any difference, as the VMCB wouldn't get filled with the not-present segment, as the processor would GP-fault FIRST...) already been checked by the processor. Count = 0 .. 1 is a rare case, so checking if count > 1 is probably meaningless.... -- 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 |