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

[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.

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