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

Ping: [PATCH v2] x86/PoD: move increment of entry count


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 27 Jan 2022 16:04:40 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MQ1jObtNsVt0Gb/q4hYMDZAGb5jCrEKaEVTZn5oVjeo=; b=G8GTfpoiHFDdxpD8XduH8FRWXP5/v/VsijT/H7L20aTic6F0XEWn+M1onTCJ5s1XScKLP1hjk3ueXFN57AwKoy5hHqCS1+/+u4qTTqokIsy/PSa/JhHxZGpvXUP87jrtbjSDOzyosKmWnqickNUoTS4E94G582Pbe/rX+polZ8E2NcA84d7/szrbNYelQiSQAHUJDqHPElBJVVpTLs+QxWOknJWsmQ22ehi/pXZUs+C7OOfj21obRyTeakXeywt7yXghS5x+8jW3YVRV2c789+725aLTbASSvRFjvG7gkPdaBEoXgIMO/iPriglgF1YN+VSBNxchp1uX8B5lISNNVQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c44QG9IeMcWPC1C67MadY8EzN8pbuAwogt34yY9/5YF/3GQrZEPfcz3VVD5gxgtXXW1vsYR5M80zAMMb2pihqruHeytiXkb32uyTOkbwlywXZJ+S9rEC5gNJjgroh6cbX/XvP1JYbcqrVOR04dlOeqBHEmMJUKxwp+WyzSA1aCf6Z9+XPRZ5pn1h3v5vEbGzTK0uKC1QXVkX/uEeHlH6zq3ch4w5cLoax7LyUbZUM88mPuXRdlz8y18ohoRGXAciAuASbhYHiRJ9zA58i5Fcb580eo5CIpV7QhHe+R181Idkuo23kZ7FzejkWysaA2oKZhMo6YWP1IU0sZQV1fqEmQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 27 Jan 2022 15:04:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.01.2022 11:57, Jan Beulich wrote:
> When not holding the PoD lock across the entire region covering P2M
> update and stats update, the entry count should indicate too large a
> value in preference to a too small one, to avoid functions bailing early
> when they find the count is zero. Hence increments should happen ahead
> of P2M updates, while decrements should happen only after. Deal with the
> one place where this hasn't been the case yet.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Add comments.

Ping?

Jan

> ---
> While it might be possible to hold the PoD lock over the entire
> operation, I didn't want to chance introducing a lock order violation on
> a perhaps rarely taken code path.
> 
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -1342,19 +1342,22 @@ mark_populate_on_demand(struct domain *d
>          }
>      }
>  
> +    /*
> +     * Without holding the PoD lock across the entire operation, bump the
> +     * entry count up front assuming success of p2m_set_entry(), undoing the
> +     * bump as necessary upon failure.  Bumping only upon success would risk
> +     * code elsewhere observing entry count being zero despite there actually
> +     * still being PoD entries.
> +     */
> +    pod_lock(p2m);
> +    p2m->pod.entry_count += (1UL << order) - pod_count;
> +    pod_unlock(p2m);
> +
>      /* Now, actually do the two-way mapping */
>      rc = p2m_set_entry(p2m, gfn, INVALID_MFN, order,
>                         p2m_populate_on_demand, p2m->default_access);
>      if ( rc == 0 )
> -    {
> -        pod_lock(p2m);
> -        p2m->pod.entry_count += 1UL << order;
> -        p2m->pod.entry_count -= pod_count;
> -        BUG_ON(p2m->pod.entry_count < 0);
> -        pod_unlock(p2m);
> -
>          ioreq_request_mapcache_invalidate(d);
> -    }
>      else if ( order )
>      {
>          /*
> @@ -1366,6 +1369,14 @@ mark_populate_on_demand(struct domain *d
>                 d, gfn_l, order, rc);
>          domain_crash(d);
>      }
> +    else if ( !pod_count )
> +    {
> +        /* Undo earlier increment; see comment above. */
> +        pod_lock(p2m);
> +        BUG_ON(!p2m->pod.entry_count);
> +        --p2m->pod.entry_count;
> +        pod_unlock(p2m);
> +    }
>  
>  out:
>      gfn_unlock(p2m, gfn, order);
> 
> 




 


Rackspace

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