[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Linux Stubdom Problem
On Thu, 27 Oct 2011, Jiageng Yu wrote: > Hi Stefano, > > I have some progress in linux based stubdom project. As shown in the > attached video, I have started the emulated vga device in the linux > based stubdom. > > In a short conclusion, for the linux based stubdom, there are two > major problems about vga device emulation. The first is the vram > mapping, which we discussed a lot previously and handled it. Do you have an updated version of the patch you used? > Another > is the vga BIOS mapping (address 0xc0000-0xc8fff of hvm guest). This is caused by qemu trying to map that memory area in its own address space, right? > I found the vga BIOS mapping problem in remap_area_mfn_pte_fn() > function. The pte_mkspecial() will return invalid value when I try to > map 0xc0000-0xc8fff into linux based stubdom. What is exactly the error you are seeing? > pte_mkspecial() > ->pte_set_flags() > ->native_pte_val() > ->native_make_pte() > > According to my test, the root cause of vga BIOS mapping problem is > native_xxx functions. We could avoid the problem by invoking functions > defined in paravirt.h instead. The patch is as follows. But I think it > is not a good way to handle the problem. Maybe you can give me some > suggestions. > > I also found the hard disk > didn�??�?????�??�????�??�???�??�??�??�?�¢??t work well. I will > investigate it these days. > > > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -2639,12 +2640,16 @@ 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)); > + if((rmd->mfn & 0xfffffff0) == 0xc0){ > + pte_t pte = pfn_pte(rmd->mfn++, rmd->prot); > + rmd->mmu_update->val = pte_val(pte); > + }else{ > + pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot)); > + rmd->mmu_update->val = pte_val_ma(pte); > + } Even if the fix is not the correct one I think I might understand what the real problem is: pfn_pte -> xen_make_pte if (unlikely(pte & _PAGE_IOMAP) && (xen_initial_domain() || addr >= ISA_END_ADDRESS)) { pte = iomap_pte(pte); } else { pte &= ~_PAGE_IOMAP; pte = pte_pfn_to_mfn(pte); } considering that in this case xen_initial_domain() returns false and addr is < ISA_END_ADDRESS (it is a gpfn address), xen_make_pte is going to threat the mfn as a pfn erroneously. In your patch you replaced pte_val_ma with pte_val that does the opposite translation (mfn -> pfn) so the end result is that you get the original mfn in rmd->mmu_update->val. 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |