[Xen-changelog] [xen-unstable] x86 mm: revert check in clear_mmio_p2m_entry() changed in 21940:e7afe98afd43

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User Allen Kay allen.m.kay@xxxxxxxxx
# Date 1283330932 -3600
# Node ID 73b131807d87df9b6c3b657dfcf9bdbcc3a27b1b
# Parent  573ddf5cc145394cf54b7a068e72f2a60c1594e4
x86 mm: revert check in clear_mmio_p2m_entry() changed in 21940:e7afe98afd43

valid_mfn() cannot be used here as MMIO pages are always above max_mem.
Also added sanity checking for type == p2m_mmio_direct before clearing
page table entry.  This should fix both VT-d and SR-IOV issues reported
recently as there are no SR-IOV specific code in Xen.  As far as Xen
is concern, SR-IOV virtual function is just another PCI device.

Signed-off-by: Allen Kay allen.m.kay@xxxxxxxxx
Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
---
 xen/arch/x86/mm/p2m.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -r 573ddf5cc145 -r 73b131807d87 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c     Tue Aug 31 19:16:23 2010 +0100
+++ b/xen/arch/x86/mm/p2m.c     Wed Sep 01 09:48:52 2010 +0100
@@ -2620,7 +2620,9 @@ clear_mmio_p2m_entry(struct p2m_domain *
         return 0;
 
     mfn = gfn_to_mfn(p2m, gfn, &t);
-    if ( !mfn_valid(mfn) )
+
+    /* Do not use mfn_valid() here as MMIO pages are always above max_page */
+    if ( (INVALID_MFN == mfn_x(mfn)) || (t != p2m_mmio_direct) )
     {
         gdprintk(XENLOG_ERR,
             "clear_mmio_p2m_entry: gfn_to_mfn failed! gfn=%08lx\n", gfn);

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