WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jiageng Yu <yujiageng734@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: Linux Stubdom Problem
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Wed, 9 Nov 2011 13:47:36 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx>, Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "Tim \(Xen.org\)" <tim@xxxxxxx>, Konrad, Samuel, Anthony PERARD <anthony.perard@xxxxxxxxx>, Thibault <samuel.thibault@xxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Wed, 09 Nov 2011 05:48:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAJ0pt154u9GY-6x6ZJA2UDyfgE135hZkr27XHnJ2ooaaNtTEmw@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1109021401000.12963@kaball-desktop> <CA8694A1.20379%keir.xen@xxxxxxxxx> <CAJ0pt17eoZbEnmziLaSd1Cxi+sU90rJ-c8TSgt+ikE3wZj1jhA@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1109151110020.12963@kaball-desktop> <CAJ0pt15daSuXGi_8T3NS53E2Xv0bYV90b94100Wi6ajt99gedQ@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1111081412270.3519@kaball-desktop> <CAJ0pt154u9GY-6x6ZJA2UDyfgE135hZkr27XHnJ2ooaaNtTEmw@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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