[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Mon, 19 Jun 2006 16:29:49 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 19 Jun 2006 01:30:51 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcaTdVjqAM8PapUaTqCv6E9868SxaAAAuNOw
  • Thread-topic: [Xen-devel][Patch] MTRR virtualization

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
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
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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.