Re: [Xen-devel] [PATCH] vmx: last branch recording MSR emulation

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 9/8/07 13:20, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> .. to have feature parity with SVM.
> 
> This required adding infrastructure to make use of VMX' MSR save/
> restore feature as well as making the MSR intercept bitmap per-VM.

> +    rdmsr(MSR_IA32_VMX_MISC, vmx_msr_low, vmx_msr_high);
> +    /* 16-byte entries in 512-entry steps */
> +    vmx_msr_max_order = ((vmx_msr_low >> 25) & 7) + 13 - PAGE_SHIFT;

It's not clear to me from the reference manual how VMX_MISC[25:27] is
supposed to be interpreted. The manual claims in G.5 that if the value is N
then the maximum number of MSRs is (N+1)*512. Note that the formula is
linear in N, not exponential, so I think turning N into an order variable
(vmx_msr_max_order) is incorrect.

However, the manual then confuses me. In 20.7.2 it says "it is recommended
that [MSR-store] count not exceed 512 bytes". This doesn't tally with the
formula G.5 which would imply that the smallest limit would be 512 *MSRs*,
not 512 bytes. I wonder if 20.7.2 is incorrect?

I'd like to get this latter point clarified (I cc'ed Xin Li at Intel to see
if he has any idea). If the smallest limit is indeed 512 MSRs then I see
little point in interrogating VMX_MISC at all, or including limit-checking
code. We're absolutely nowhere near pushing the limit of 512 MSRS. Also that
limit requires 8kB of MSR data -- we can't really guarantee success of
contiguous multi-page allocations anyway (as you have seen) so actually we'd
like to keep to a 256-MSR limit for that reason.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel