[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Linux Stubdom Problem
2011/11/9 Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>: > 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); Great! It works. The keyboard driver is OK now. I am working on network device. In linux stubdom, I have udev, ifconfig and brctl tools. After udevd started, stubdom executes "ifconfig eth0 IPadderss netmask netgate up" to setup the network. When qemu in stubdom creates a tapxx interface for hvm guest, the script should be executed to build a net bridge. /sbin/brctl addbr eth0 /sbin/brctl addif eth0 tapXX Therefore, the hvm guest has the network device. Is this plan reasonable? Or have better one? Thanks. Jiageng Yu. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |