RE: more segment/selector handling woes

["Jan Beulich" <jbeulich@novell.com>]

>> 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).

Jan