From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: Re: [GIT PULL] pv/pcifront-2.6.32
Date: Wed, 3 Mar 2010 09:22:25 -0500 [thread overview]
Message-ID: <20100303142225.GA18466@phenom.dumpdata.com> (raw)
In-Reply-To: <4B8D956D.9030406@goop.org>
>> I needed it for v2.6.32 + jeremy/xen/dom0/konrad-swiotlb-2.6.32 +
>> konrad/pv/pcifront-2.6.32. Otherwise I would get this:
>>
>
> OK, so I guess Xen does complain if you try to set UC/WT ptes but are
> non-privileged. But still, with that patch in place, it means that even
> a passthrough hardware mapping may lack UC/WT. Perhaps that doesn't
> matter? I bet it will when we get around to fixing up PAT.
It is more than just the UC/WT PTEs. Here is the commit:
>
commit f6a09fcc104ca416e98feb1cecc3ee16509dc376
Author: Alex Nixon <alex.nixon@citrix.com>
Date: Mon Feb 9 15:05:46 2009 -0500
xen: Allow unprivileged Xen domains to create iomap pages
PV DomU domains are allowed to map hardware MFNs for PCI passthrough,
but are not generally allowed to map raw machine pages. In particular,
various pieces of code try to map DMI and ACPI tables in the ISA ROM
range. We disallow _PAGE_IOMAP for those mappings, so that they are
redirected to a set of local zeroed pages we reserve for that purpose.
[ Impact: prevent passthrough of ISA space, as we only allow PCI ]
Signed-off-by: Alex Nixon <alex.nixon@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Conflicts:
arch/x86/xen/enlighten.c
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index dfbf70e..cc2829a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1138,6 +1138,10 @@ asmlinkage void __init xen_start_kernel(void)
pgd = (pgd_t *)xen_start_info->pt_base;
+ if (!xen_initial_domain())
+ __supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
+
+ __supported_pte_mask |= _PAGE_IOMAP;
/* Don't do the full vcpu_info placement stuff until we have a
possible map and a non-dummy shared_info. */
per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 2630313..0bc8fa9 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -50,6 +50,7 @@
#include <asm/mmu_context.h>
#include <asm/setup.h>
#include <asm/paravirt.h>
+#include <asm/e820.h>
#include <asm/linkage.h>
#include <asm/page.h>
@@ -387,7 +388,7 @@ static bool xen_page_pinned(void *ptr)
static bool xen_iomap_pte(pte_t pte)
{
- return xen_initial_domain() && (pte_flags(pte) & _PAGE_IOMAP);
+ return pte_flags(pte) & _PAGE_IOMAP;
}
static void xen_set_iomap_pte(pte_t *ptep, pte_t pteval)
@@ -589,10 +590,21 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);
pte_t xen_make_pte(pteval_t pte)
{
- if (unlikely(xen_initial_domain() && (pte & _PAGE_IOMAP)))
+ phys_addr_t addr = (pte & PTE_PFN_MASK);
+
+ /*
+ * Unprivileged domains are allowed to do IOMAPpings for
+ * PCI passthrough, but not map ISA space. The ISA
+ * mappings are just dummy local mappings to keep other
+ * parts of the kernel happy.
+ */
+ if (unlikely(pte & _PAGE_IOMAP) &&
+ (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
pte = iomap_pte(pte);
- else
+ } else {
+ pte &= ~_PAGE_IOMAP;
pte = pte_pfn_to_mfn(pte);
+ }
return native_make_pte(pte);
}
prev parent reply other threads:[~2010-03-03 14:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 3:12 [GIT PULL] pv/pcifront-2.6.32 Konrad Rzeszutek Wilk
2010-03-02 9:21 ` Ian Campbell
2010-03-02 13:55 ` Konrad Rzeszutek Wilk
2010-03-02 14:45 ` Ian Campbell
2010-03-02 14:15 ` Konrad Rzeszutek Wilk
2010-03-02 20:12 ` Jeremy Fitzhardinge
2010-03-02 21:54 ` Konrad Rzeszutek Wilk
2010-03-02 22:20 ` Konrad Rzeszutek Wilk
2010-03-02 23:13 ` Jeremy Fitzhardinge
2010-03-02 22:47 ` Jeremy Fitzhardinge
2010-03-03 14:22 ` Konrad Rzeszutek Wilk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100303142225.GA18466@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=jeremy@goop.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.