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

[Jiageng Yu <yujiageng734@xxxxxxxxx>]

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.


<5>Linux version 2.6.32.41 (root@xxxxxxxxxxxxxxxxxxxxx) (gcc version
4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) ) #1 Wed Nov 9 15:26:21 GMT
2011
<6>KERNEL supported cpus:
<6>  Intel GenuineIntel
<6>  AMD AuthenticAMD
<6>  NSC Geode by NSC
<6>  Cyrix CyrixInstead
<6>  Centaur CentaurHauls
<6>  Transmeta GenuineTMx86
<6>  Transmeta TransmetaCPU
<6>  UMC UMC UMC UMC
<6>released 0 pages of unused memory
<6>BIOS-provided physical RAM map:
<6> Xen: 0000000000000000 - 00000000000a0000 <c>(usable)<c>
<6> Xen: 00000000000a0000 - 0000000000100000 <c>(reserved)<c>
<6> Xen: 0000000000100000 - 0000000004000000 <c>(usable)<c>
(XEN) mm.c:859:d36 Non-privileged (36) attempt to map I/O space 000000f0
(XEN) mm.c:5046:d36 ptwr_emulate: could not get_page_from_l1e()
(XEN) d36:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from c038c000:
(XEN)  L3[0x003] = 000000009791d001 000003c8
(XEN)  L2[0x001] = 0000000097d34067 000012f1
(XEN)  L1[0x18c] = 0000000093df9061 0000038c
(XEN) domain_crash_sync called from entry.S (ff1ddf7c)
(XEN) Domain 36 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.2-unstable  x86_32p  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) EIP:    e019:[<c01048bc>]
(XEN) EFLAGS: 00000246   EM: 1   CONTEXT: pv guest
(XEN) eax: 00000000   ebx: c038c000   ecx: 00000000   edx: c0320000
(XEN) esi: 000f0463   edi: 00000000   ebp: c038c000   esp: c0321e8c
(XEN) cr0: 8005003b   cr4: 000426f4   cr3: 00a96200   cr2: c038c000
(XEN) ds: e021   es: e021   fs: 0000   gs: 0000   ss: e021   cs: e019
(XEN) Guest stack trace from esp=c0321e8c:
(XEN)    00000003 c01048bc 0001e019 00010046 f5600000 000f0000 00000000 c03563c8
(XEN)    000f0000 00000000 000f0000 00000000 000f0000 00000000 c035677e 00000563
(XEN)    80000000 c0368f78 c0368f7e c0349728 c0214090 00000010 00000000 000001ff
(XEN)    00000000 c036b550 c038ed40 c0321fd4 c035683e 00000563 80000000 c0362757
(XEN)    00000000 c0368f7e 00000000 c02de171 00000000 00000000 c036b550 c038ed40
(XEN)    c0321fd4 00000000 c036b550 c038ed40 c0321fd4 c034cf01 00000004 00000000
(XEN)    ffffffff 0000000a ffffffff ffffffff c0321fc4 00000035 00000000 c0321fd0
(XEN)    ffffffff ffffffff c0393360 c0393160 00000200 c02e3791 00000004 00000000
(XEN)    ffffffff 0000000a ffffffff c0321fcc c0214090 00000090 c02de1cc c0321fcc
(XEN)    c029f093 c0321fd0 02040800 00534000 c032aa7c 00000000 c03494d5 c02de1cc
(XEN)    c02a3020 c02e3791 c036ace0 02040800 c034b11c 00000000 1f898175 8c080201
(XEN)    02040800 0001067a 00000000 c12eb000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 9791d001 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000


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