Re: Issue with ARM: Network doesn't work in the guest

Re: Issue with ARM: Network doesn't work in the guest

[mail fetch]

2013/10/29, mail fetch <fetchmail.0104@gmail.com>:
> 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@citrix.com
> 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?

best regards
Mail

Re: Issue with ARM: Network doesn't work in the guest

[Stefano Stabellini]

On Wed, 30 Oct 2013, mail fetch wrote:
> 2013/10/29, mail fetch <fetchmail.0104@gmail.com>:
> > 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@citrix.com
> > 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

xen/arch/arm/platforms/exynos5.c:exynos5_quirks.

Re: Issue with ARM: Network doesn't work in the guest

[Julien Grall]

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@gmail.com>:
>>> 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@citrix.com
>>> 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?

-- 
Julien Grall

Re: Issue with ARM: Network doesn't work in the guest

[Stefano Stabellini]

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@gmail.com>:
> > > > 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@citrix.com
> > > > 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).

Re: Issue with ARM: Network doesn't work in the guest

[Julien Grall]

On 11/11/2013 01:13 PM, Stefano Stabellini wrote:
> 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@gmail.com>:
>>>>> 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@citrix.com
>>>>> 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.

Thanks. I will rework the patch and send it soon.

-- 
Julien Grall