[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.