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: Tue, 8 Nov 2011 17:05:39 +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: Tue, 08 Nov 2011 09:10:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAJ0pt15daSuXGi_8T3NS53E2Xv0bYV90b94100Wi6ajt99gedQ@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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
<Prev in Thread] Current Thread [Next in Thread>