[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Linux Stubdom Problem
On Wed, 9 Nov 2011, Jiageng Yu wrote: > 2011/11/9 Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> > > > > 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. > > > > Indeed! > > > 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? > > > Sorry, it did not succeed. The Linux stubdom kernel crashed during > booting. The debug info is as follows. The kernel is tring to access some memory < ISA_END_ADDRESS that is supposed to be translated (pfn->mfn), but it doesn't happen anymore because of that patch. At this point the only solution I can think of is changing remap_area_mfn_pte_fn: diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3dd53f9..dd088f2 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -2350,7 +2350,8 @@ 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)); + pte_t pte = pte_mkspecial(native_make_pte(((phys_addr_t)(rmd->mfn++) + << PAGE_SHIFT) | massage_pgprot(rmd->prot))); rmd->mmu_update->ptr = virt_to_machine(ptep).maddr; rmd->mmu_update->val = pte_val_ma(pte); _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |