RE: [Xen-devel][Patch] MTRR virtualization

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Keir Fraser wrote:
> On 19 Jun 2006, at 08:18, Dong, Eddie wrote:
> 
>> Add MTRR virtualization to set right memory type for direct IO space.
>> Otherwise setting "WB" for memory backed RAM space.
> 
> Two things:
>   1. What is this for? I don't understand the higher-level purpose of
> this MTRR support, since HVM guests don't currently do direct I/O.
This patch is a preparation for direct IO feature coming, and also fix
for potential bugs.
We need to set right PAT entry in shadow PTE even for those non direct
IO space.
For example, a guest may set video frame buffer to be "WC". But in Xen 
environment, as we are using memory (RAM) to back for guest video frame,

we have to set the memory type to be "WB" otherewise the access using 
aliase address in Qemu (WB attribute) may cause mca.
Current shadow simply copy guest PAT entry to shadow PTE even for video 
frame buffer, this works as if the guest is setting PAT as "WB" and MTRR
as "WC".
On the otherhand, if guest is setting PAT as "WC", and MTRR as "WB", we
have 
problem. Because in this case, shadow PAT="WC", machine MTRR = "WB", 
and thus we get "WC" for this video frame. MCA may happen.

>   2. MTRR MSRs are architectural -- the big blob of support you've
> added for those belongs in an hvm-generic file. In general I think we
> need common msr read/write functions for dealing with
> non-processor-specific MSRs. There's way too much almost-identical or
> actually-identical vmx and svm-specific code right now.
I think so, but I have no SVM platform for development and debug so far
and also
may be lack of SVM knowledge :-(
Probably we enable this for VMX, and then SVM guys followup. If SVM
logic
is similar with VMX, then SVM guys should move some of them to
HVM common code (I actually did some cleanup for APIs like
get_guest_time etc
that SVM adopts same mechanism with VMX).
What is your suggestion?

thx,eddie

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