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

[Jiageng Yu <yujiageng734@xxxxxxxxx>]

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