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

Re: [PATCH v3] xen/pci: detect when BARs are not suitably positioned


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 2 Feb 2022 10:42:22 +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=PkXxk37QoNgrDyPWLzP47ETl9eFQV0Qt63FMS3/VkKY=; b=RptBkwi3ThnrtdpSYrVO2w0aInbzec94ZyfZGBQR9acnXGrGUQp20MrfRCiSVqGpmlSGvE27th+huVj9/o8eXdZxriiMEQMeXOhHkh0urUr9tDAvlZ63LbLGERuU/536Md2qR/QkUveyn3EmU0I5/XLw3kWKn0ABbnm83OAuj3FIKbCwnelP/xJgsRV2Sec+AoZEFqdSIqd1Dk9ONnjTKUzEJLtWtX1xBr3kMtclVqFh12gaMm94Ktlw+MzX13RKvnyap9/b1zx7JzBYRgqUZpQge6smJzxXjpuWMdWGMiYpVJX07rx+rKfl+efkxGP03Hf4bDWW/LLo5IZWXYjmAg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hEQ/76nkD2YfsOnJ5aM45YbMQrABGyl9P6UokBdnoqU0nVALJGdMgCKaRZn7Hzlyv0FhvGXt3jF7ZU39UA2EhkZVJi1GCqk5nooD7Znl4MbrzE/4B0yLDcohf3EaQYcBi2ZZLnow6P9e/V6WeohHFM/knxdheXeT0dUbwG3DQM16zvgrCxDleHtvQTKOcyGtYz+CRwIrjoTQIR2dxsjYiEYkamhOM5imJyGMIBtFtXKvcGikTDIx7i7a5OBXDyO5NaFNiVKr6GTajoZ0h9R+So024iftmi4OneeKPwkfjPVDTGqrNu9j2wFef5cwyvE/KQmqpPsGHIAhfS2rfyGx7A==
  • 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>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 02 Feb 2022 09:42:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01.02.2022 13:45, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -783,6 +783,23 @@ bool is_iomem_page(mfn_t mfn)
>      return (page_get_owner(page) == dom_io);
>  }
>  
> +bool is_memory_hole(unsigned long start, unsigned long end)
> +{
> +    unsigned int i;
> +
> +    for ( i = 0; i < e820.nr_map; i++ )
> +    {
> +        const struct e820entry *entry = &e820.map[i];
> +
> +        /* Do not allow overlaps with any memory range. */
> +        if ( start < PFN_DOWN(entry->addr + entry->size) &&
> +             PFN_DOWN(entry->addr) <= end )
> +            return false;
> +    }
> +
> +    return true;
> +}

Doesn't the left side of the && need to use PFN_UP()?

I also think it would help if a brief comment ahead of the
function said that the range is inclusive. Otherwise the use
of < and >= gives the impression of something being wrong.
Then again it may be better to switch to <= anyway, as I
think you want to avoid possible zero-size regions (at which
point subtracting 1 for using <= is going to be valid).

Finally I wonder whether the function parameters wouldn't
better be named e.g. spfn and epfn, but maybe their units can
be inferred from their types being unsigned long (which,
however, would build on the assumption that we use appropriate
types everywhere).

> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -554,6 +554,8 @@ int __must_check steal_page(struct domain *d, struct 
> page_info *page,
>  int page_is_ram_type(unsigned long mfn, unsigned long mem_type);
>  /* Returns the page type(s). */
>  unsigned int page_get_ram_type(mfn_t mfn);
> +/* Check if a range falls into a hole in the memory map. */
> +bool is_memory_hole(paddr_t start, uint64_t size);

While resolving to the same type, these now also want to be
"unsigned long".

Jan




 


Rackspace

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