| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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 10:43
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [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.
* Data sgemnents referenced by FS and GS segmente registers receive
special treatment in 64-bit mode. For these segments, the base address
field is not ignored, and a non-zero value can be used in a
virtual-address calculations. A 64-bit segmnet base addres can be
spciefied using model specific registers. See "FS and GS Registers in
64-bit mode" on page 88 for more information.
So FS/GS should be considered for VA calculation in the code you refer
to. Sorry I missed that when I wrote it.
>
> 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... ;-)
--
Mats
>
> Thanks, 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
|
|
|
| |
|
Home