>On 28/3/07 16:51, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:
>
>> Better use of VMX execution controls MSR.
>>
>> Signed-off-by: Xin Li<xin.b.li@xxxxxxxxx>
>
>Is this actually to fix a problem with a future processor?
No, this is just for better coding for hardware features that may not be
available
on all processors.
>This whole bit-forcing thing seems extremely odd to me. We set the
controls
>that Xen currently needs to do its job as a VMM properly -- we can't
just
>clear some of those controls because the processor says to do so. So I
think
>our current treatment of the MSR high bits is appropriate (if it tells
us to
>zero one of the control bits that we make use of, we are in trouble --
we
>have a processor that isn't backwards compatible!).
I also think its appropriate.
>I also feel uneasy about setting extra bits (as specified by the MSR
low bits),
>but I reason that if we are told to set bits of flags which are
currently
>architecturally-undefined then it is reasonable to let the processor
tell us what
>to do with them. Which is why I do respect the MSR low bits.
Yes, we must repect MSR low bits.
>
>Why did Intel ever choose this insane scheme? Would it have been so
hard to
>have defined bitmaps with set-to-enable semantics, and always require
zero
>for reserved bits? Actually I suppose you do have set-to-enable
semantics
>(otherwise my current asymmetric treatment of MSR high and low words
would
>not make sense). But all this messing with setting vs. clearing
reserved
>bits seems pretty stupid.
Yeah, I think the basic logic is still set-to-enable semantics here.
I made this patch when we add VMX MSR bitmap support, which is used to
avoid
FS_BASE and GS_BASE MSR accesses VMExits in 64 bit guests. But some
early
precessors may not support this feature, so the MSR reports 0 in high
bits, meaning we
must set the bit to zero in VMCS. So a straightforward way is to check
if the feature
is availale and then set to VMCS accordingly. But we have lots of
hardware features,
with new features being added to hareware, and I really don't like to
add the almost
same code just for another new feature detection. The idea here is to
use the control MSR
to adjust the input controls we _hardcoded_ in Xen, for the features
we've supported in Xen,
we always set to 1 in the input control, like in
MONITOR_CPU_BASED_EXEC_CONTROLS,
then on processors supporting this feature, We get 1, while on
processors not supporting this
feature, we get 0. This adjusted output control value can be also used
to choose code
path on different processors, and the attached patch can be an example.
-Xin
vmx_msr_bitmap.patch
Description: vmx_msr_bitmap.patch
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home