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

Re: [PATCH] x86/pvh: fix population of the low 1MB for dom0


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 24 Jan 2022 17:01:04 +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=1u2I3HRtgCbh3u/3XHE1f7ovqEZ/NuvEWRT3RFTqds4=; b=CGXDn4Si3hIgkZYglpWZuii2whijPCcepjOpBYsG/IZXMtRPZ8rQbthA6nJPVR1GxhGxuvase/RvRyaI0tlUqNoexuex6qfeVMe2hQd1QSmXQgq6YSaWMfqz8uST49KOXBwPVijqDq795bdRTkLrfcxUYcYPYvT5xRCKq/dsMhtSwS7hKwKGV0PB1uKNChsfnXcHxtGMez3XCm9TRb50duccyDWNgfdIjZRtob7YUSIeEHQN2XKQAAjHcuhXQvegbPDRAbKeuBZ3TC1CCWk4m0LgaEhyibC8cKrY603YYEGnCq5wbArACxAItsFkT4eTJX89pbZHMEl75ZVCsms+0Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PFl28bDiEYKmyWKO4M8y4JcPXwL3wRrNeseaPPovge+gf20Ajxu/xG/TfkLB92bX9ym/FJmxiSHmH/g3iNfkYW3CTSbzUhAOsjTlamEMOFs73BGsnk8Wca+bCtRw70pTLlSbUI2OJhPYxli+Tc5TkZOH00390cVDAAL0dyt9eOgffIZvYB53hUWGpW+7g2DfFQE6KnSl33RSTFTvw8GGMhd0KmnPOjzOkzJsHau0BPJz6I1f5rZZBY9OPfI9anGL78718dOup2+5UZIH1n2u9Ovyhjn88JCJI7gi+SJLnp1dGx0Mcr1qPPxJK1Ak2rxGZENhBti+BgUeXONF8UHWyQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 24 Jan 2022 16:01:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.01.2022 16:23, Roger Pau Monne wrote:
> RMRRs are setup ahead of populating the p2m and hence the ASSERT when
> populating the low 1MB needs to be relaxed when it finds an existing
> entry: it's either RAM or a RMRR resulting from the IOMMU setup.
> 
> Rework the logic a bit and introduce a local mfn variable in order to
> assert that if the gfn is populated and not RAM it is an identity map.
> 
> Fixes: 6b4f6a31ac ('x86/PVH: de-duplicate mappings for first Mb of Dom0 
> memory')
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
albeit ...

> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -466,11 +466,17 @@ static int __init pvh_populate_p2m(struct domain *d)
>      for ( i = rc = 0; i < MB1_PAGES; ++i )
>      {
>          p2m_type_t p2mt;
> +        mfn_t mfn;
>  
> -        if ( mfn_eq(get_gfn_query(d, i, &p2mt), INVALID_MFN) )
> +        mfn = get_gfn_query(d, i, &p2mt);

... preferably with this becoming the initializer of the variable then
and ...

> +        if ( mfn_eq(mfn, INVALID_MFN) )
>              rc = set_mmio_p2m_entry(d, _gfn(i), _mfn(i), PAGE_ORDER_4K);
> -        else
> -            ASSERT(p2mt == p2m_ram_rw);
> +        else if ( p2mt != p2m_ram_rw && !mfn_eq(mfn, _mfn(i)) )
> +                /*
> +                 * If the p2m entry is already set it must belong to a RMRR 
> and
> +                 * already be identity mapped, or be a RAM region.
> +                 */
> +                ASSERT_UNREACHABLE();

... (not just preferably) indentation reduced by a level here. (I wonder
why you didn't simply extend the existing ASSERT() - ASSERT_UNREACHABLE()
is nice in certain cases, but the expression it logs is entirely unhelpful
for disambiguating the reason without looking at the source.)

Jan




 


Rackspace

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