Add MTRR virtualization to set right memory type for direct IO space. Otherwise setting "WB" for memory backed RAM space. Signed-off-by: Eddie Dong <Eddie.dong@intel.com> Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
On 19 Jun 2006, at 09:29, Dong, Eddie wrote:> 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.The correct approach right now is to set WB for everything. HVM guests currently never directly map I/O resources. Anything more complicated than that, until we actually support direct I/O access, is quite mad. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel