[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Linux Stubdom Problem
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |