Re: [Xen-devel] Issue with ARM: Network doesn't work in the guest

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 7 Nov 2013, Julien Grall wrote:
> On 11/06/2013 10:12 AM, Stefano Stabellini wrote:
> > On Wed, 30 Oct 2013, mail fetch wrote:
> > > 2013/10/29, mail fetch <fetchmail.0104@xxxxxxxxx>:
> > > > Hi all,
> > > > 
> > > > I just saw a know bug from wiki that network doesn't work in guest in
> > > > arndale board :
> > > > 
> > > > Network doesn't work in the guest
> > > > 
> > > > Contact: julien.grall@xxxxxxxxxx
> > > > Status: In progress
> > > > Description: Network doesn't work in the guest when an ehternet cable is
> > > > plugged
> > > > References: http://pastebin.com/gEP3HdCg
> > > > 
> > > > What's the latest status?
> > > > 
> > > > best regards
> > > > Mail
> > > > 
> > > 
> > > Any comments?
> > 
> > Sorry for the late reply. Usually we respond pretty quickly but you
> > caught us between Xen Developer Summit and Linaro Connect: most Xen
> > hackers were traveling. In fact Julien Grall is still AFK and he
> > is the one that knows the answer.
> > 
> > I think that the 1:1 workaround in dom0 (that is having pseudo-physical
> > addresses == physical addresses for dom0) should fix it. Give a look at
> 
> Actually it's not enough. The problem is because when the balloon driver will
> release a page, Xen will populate with a new allocated page. So it will break
> the 1:1 Workaround.
> The commit eee34edcd1daecb70560dfe23009af2e65f7d26d on my tree in xenbits
> (git://xenbits.xen.org/people/julieng/xen-unstable.git) aims to fix this
> issue.
> I will try to remember to update the wiki page monday when I will come back to
> the office.
> 
> Stefano: A couple of weeks ago, you told me you plan to rework this commit for
> the swiotlb, is it still relevant?

After looking at this a bit more, I think that your workaround is
reasonable and less fragile than my original idea based on modifying the
Linux balloon driver. I think that it just needs to be cleaned a bit,
see appended comments.


> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 50b740f..be35c00 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -28,6 +28,7 @@
>  #include <public/memory.h>
>  #include <xsm/xsm.h>
>  #include <xen/trace.h>
> +#include <asm/platform.h>
>  
>  struct memop_args {
>      /* INPUT */
> @@ -122,7 +123,29 @@ static void populate_physmap(struct memop_args *a)
>          }
>          else
>          {
> -            page = alloc_domheap_pages(d, a->extent_order, a->memflags);
> +            if ( d == dom0 && 
> platform_has_quirk(PLATFORM_QUIRK_DOM0_MAPPING_11) )
> +            {
> +                mfn = gpfn;
> +                if (!mfn_valid(mfn))
> +                {
> +                    gdprintk(XENLOG_INFO, "Could not allocate order=%d 
> extent:"
> +                             " id=%d memflags=%x (%ld of %d)\n",
> +                             a->extent_order, d->domain_id, a->memflags,
> +                             i, a->nr_extents);
> +                    goto out;
> +                }
> +                page = mfn_to_page(mfn);
> +                if ( !get_page(page, d) || page_get_owner(page) != d )
> +                {
> +                    gdprintk(XENLOG_INFO, "Could not allocate order=%d 
> extent:"
> +                             " id=%d memflags=%x (%ld of %d)\n",
> +                             a->extent_order, d->domain_id, a->memflags,
> +                             i, a->nr_extents);
> +                    goto out;
> +                }
> +            }
> +            else
> +                page = alloc_domheap_pages(d, a->extent_order, a->memflags);
>              if ( unlikely(page == NULL) ) 
>              {
>                  if ( !opt_tmem || (a->extent_order != 0) )

This chuck needs to be ifdef CONFIG_ARM. Alternatively we could introduce
PLATFORM_QUIRK_DOM0_MAPPING_11 on x86 too, of course it would disabled by
default.


> @@ -216,6 +239,9 @@ int guest_remove_page(struct domain *d, unsigned long 
> gmfn)
>          return 0;
>      }
>  
> +    if ( d == dom0 && platform_has_quirk(PLATFORM_QUIRK_DOM0_MAPPING_11) )
> +        goto end_remove;
> +
>      if ( test_and_clear_bit(_PGT_pinned, &page->u.inuse.type_info) )
>          put_page_and_type(page);
>              
> @@ -224,6 +250,7 @@ int guest_remove_page(struct domain *d, unsigned long 
> gmfn)
>  
>      guest_physmap_remove_page(d, gmfn, mfn, 0);
>  
> +end_remove:
>      put_page(page);
>      put_gfn(d, gmfn);
>  

I think that it's best to avoid calling guest_remove_page from
decrease_reservation if
platform_has_quirk(PLATFORM_QUIRK_DOM0_MAPPING_11), similarly to the
existing p2m_pod_decrease_reservation check.
check).

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel