[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable test] 11574: tolerable FAIL


  • To: "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx>
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Tue, 24 Jan 2012 08:16:02 -0800
  • Cc: Adin Scannell <adin@xxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Tim Deegan <tim@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 24 Jan 2012 16:16:13 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=bktJAXlp8BCMxvQZy3AcqsLjp7RSEauyYXczQVofZE7E qFwKbvZhsCpSTlMcCop5X1avFSd1xUVpwVcRdJdq06oqKkxmCfEK31sjXaJFsK7v Hr27k8eUV5hnJWxtm8/ZQN65xmRLBo4wiqmrKsCg+0FWYYLFfNk86MGgwnE4gak=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
>> This is a host-specific, but deterministic, failure.  My bisector has
>> been working on it (the basis pass was in November so there has been a
>> lot of ground to cover and I had to make some new arrangements to be
>> able to run an ad-hoc bisection of this problem) and the results so
>> far are fingering changesets between 24367:537ceb11d51e (bad) and
>> 24362:d35bedf334f2 (good).
>
> The bisector is now minded to blame this changeset:
>
>   changeset:   24367:537ceb11d51e
>   user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
>   date:        Tue Dec 06 20:31:49 2011 +0000
>   files:       xen/arch/x86/hvm/hvm.c
>   description:
>   Improve handling of nested page faults
>
>   Add checks for access type. Be less reliant on implicit semantics.
>
>   Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
>   Acked-by: Tim Deegan <tim@xxxxxxx>
>   Committed-by: Tim Deegan <tim@xxxxxxx>
>
> It's doing a couple more before-and-after repros to be sure, but this
> looks like a plausible candidate.  Full diff below.

Thanks Ian,
just to be sure, none of the following conditions apply on your test:
- hvm uses memory sharing
- hvm runs a backend pv driver
- hvm uses populate-on-demand.

If all the above apply, I can quickly put together a micro-patch to assert
that the deal-breaker is
> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
> +    if ( (p2mt == p2m_mmio_dm) ||
> +         (access_w && (p2mt == p2m_ram_ro)) )
>

Would you be able to test that?
Thanks again
Andres
> I'm not an expert on this area.  Perhaps someone could speculate what
> Windows is doing that is triggering one of these new checks ?
>
> Ian.
>
> # HG changeset patch
> # User Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
> # Date 1323203509 0
> # Node ID 537ceb11d51ef60cd4abffd2f54de0ae0ca50008
> # Parent  534b2a15e6695dfd8866c0ff626b002cbf57991a
> Improve handling of nested page faults
>
> Add checks for access type. Be less reliant on implicit semantics.
>
> Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
> Acked-by: Tim Deegan <tim@xxxxxxx>
> Committed-by: Tim Deegan <tim@xxxxxxx>
>
> diff -r 534b2a15e669 -r 537ceb11d51e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c  Tue Dec 06 20:10:32 2011 +0000
> +++ b/xen/arch/x86/hvm/hvm.c  Tue Dec 06 20:31:49 2011 +0000
> @@ -1288,7 +1288,8 @@ int hvm_hap_nested_page_fault(unsigned l
>       * If this GFN is emulated MMIO or marked as read-only, pass the
> fault
>       * to the mmio handler.
>       */
> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
> +    if ( (p2mt == p2m_mmio_dm) ||
> +         (access_w && (p2mt == p2m_ram_ro)) )
>      {
>          if ( !handle_mmio() )
>              hvm_inject_exception(TRAP_gp_fault, 0, 0);
> @@ -1302,7 +1303,7 @@ int hvm_hap_nested_page_fault(unsigned l
>          p2m_mem_paging_populate(v->domain, gfn);
>
>      /* Mem sharing: unshare the page and try again */
> -    if ( p2mt == p2m_ram_shared )
> +    if ( access_w && (p2mt == p2m_ram_shared) )
>      {
>          ASSERT(!p2m_is_nestedp2m(p2m));
>          mem_sharing_unshare_page(p2m->domain, gfn, 0);
> @@ -1319,14 +1320,17 @@ int hvm_hap_nested_page_fault(unsigned l
>           * a large page, we do not change other pages type within that
> large
>           * page.
>           */
> -        paging_mark_dirty(v->domain, mfn_x(mfn));
> -        p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
> +        if ( access_w )
> +        {
> +            paging_mark_dirty(v->domain, mfn_x(mfn));
> +            p2m_change_type(v->domain, gfn, p2m_ram_logdirty,
> p2m_ram_rw);
> +        }
>          rc = 1;
>          goto out_put_gfn;
>      }
>
>      /* Shouldn't happen: Maybe the guest was writing to a r/o grant
> mapping? */
> -    if ( p2mt == p2m_grant_map_ro )
> +    if ( access_w && (p2mt == p2m_grant_map_ro) )
>      {
>          gdprintk(XENLOG_WARNING,
>                   "trying to write to read-only grant mapping\n");
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.