Re: [Xen-devel] Re: Linux Stubdom Problem

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 9 Nov 2011, Konrad Rzeszutek Wilk wrote:
> > The real fix should something along these lines:
> > 
> > 
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index 3dd53f9..f2fadfc 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -422,7 +422,7 @@ static pteval_t xen_pte_val(pte_t pte)
> >             pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
> >     }
> >  
> > -   if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
> > +   if (pteval & _PAGE_IOMAP)
> >             return pteval;
> >  
> >     return pte_mfn_to_pfn(pteval);
> > @@ -483,8 +483,7 @@ static pte_t xen_make_pte(pteval_t pte)
> >      * 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)) {
> > +   if (unlikely(pte & _PAGE_IOMAP)) {
> >             pte = iomap_pte(pte);
> >     } else {
> >             pte &= ~_PAGE_IOMAP;
> > ---
> > 
> > Could you please confirm whether this patch fixes your problem?
> > 
> > Konrad, do you know if this could have any unintended consequences?
> > I don't think it can be a problem security wise because Xen is going to
> > do all the permission checks anyway.
> > The only problem I can see is if a domU is going to call xen_make_pte
> > with _PAGE_IOMAP and a pfn->mfn translation is supposed to happen.
> 
> I am not sure. I think I tried this at some point but ran in some problems, 
> but
> I can't recall which ones. Let me stick this in my #testing branch and see 
> how it
> fares with Dom0/DomU/DomU PCI/ etc.


Actually the patch above caused troubles at boot time because when the
guest tries to map memory below ISA_END_ADDRESS pfns don't get converted
to mfns anymore.
I ended up suggesting to modify remap_area_mfn_pte_fn instead, see patch
below.

---

Use native_make_pte in remap_area_mfn_pte_fn because
remap_area_mfn_pte_fn gets always called with _PAGE_IOMAP set so no
pfn->mfn translations are necessary. At the same time
xen_initial_domain() returns false in stubdoms so if we are trying to
remap memory < ISA_END_ADDRESS from another guest xen_make_pte would
force a pfn->mfn translation.

Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 3dd53f9..f628441 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2350,10 +2350,19 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t 
token,
                                 unsigned long addr, void *data)
 {
        struct remap_data *rmd = data;
-       pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));
-
+       /* Use the native_make_pte function because we are sure we don't
+        * have to do any pfn->mfn translations but at the same time we
+        * could in a stubdom so xen_initial_domain() would return false. */
+       pte_t pte = pte_mkspecial(native_make_pte(((phys_addr_t)(rmd->mfn++)
+                                       << PAGE_SHIFT) | 
massage_pgprot(rmd->prot)));
+       pteval_t val = pte_val_ma(pte);
+
+       if (pat_enabled && !WARN_ON(val & _PAGE_PAT)) {
+               if ((val & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
+                       val = (val & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
+       }
        rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
-       rmd->mmu_update->val = pte_val_ma(pte);
+       rmd->mmu_update->val = val;
        rmd->mmu_update++;
 
        return 0;


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