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

Re: [PATCH 2/2] x86/vpci: refuse to map BARs at position 0


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Thu, 22 May 2025 11:32:38 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=3aTIUxbrNKrFuWYt64pC+6rVE4rT4AH36+tbPlLPOv4=; b=TcuCx06uwdM93MHqUzZ5UCJQCqjjiKKDrx78o59iqJhtoQhZWVf47qD428M61OYckAxNqWrPEWT6RnqvEGulDiXTIqsjz7Rw6YXkPcc05QsjNSu5oArKCDiB1hRyk49ZIchfNjTAAM/iefd8slJ9Hg4cBHH88zW3L94Moa52+BXQADgTLxjeiry67GJn2QiUK9tJcveLL6CmKWXZe/x7IbdO+Z/0P5+poF6alA0yrQaPRelz0Wlt/1aBsRc1sp3iAScWIBFRIIzaBPCdR+3dSM7Lc+1qJvTg79vlOGlX3GeInv4DEEFUwjkSORFg2ynxWPvPKAREx6YcEt9+/kKGag==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nl8pkgak3yG0AQAmyXLZ88pqOazsTiaMX0Ga4bvdAqZa/4EZRR4czOaf1bZ+7PJY6qvn6pVtDDl2Uuu5y+nX2/AOA6yl7xIOVNrZBW1W9Vek/C9sJkqDbv+4ODVQjFSoUm5x+Z5xR/yi+TiY58RbooOqjrUCc0XyzPMajpBZPadAe4MnKfyV4GZp2Ow4hySzhDacJBUnRFLS7jS4Q+JW4owrA1zy1IvzQFfvE2ds/nVBlaFu2Qu1mlvLI86AdOCWabSYM+isFQ/ElNmRdXW4xtTqO1HR4BGADdF7VNKKtHEjbqDBJdeceFugmPqGg4cn0pPcQ+eB1S7ufSgT6meGUQ==
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Thu, 22 May 2025 15:32:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 5/22/25 10:03, Roger Pau Monne wrote:
> A BAR at position 0 is not initialized (not positioned).  While Xen could
> attempt to map it into the p2m, marking it as mapped will prevent dom0 to
> change the position of the BAR, as the vPCI code has a shortcomming of not
> allowing to write to BAR registers while the BAR is mapped on the p2m.
> 
> Workaround this limitation by returning false from pci_check_bar() if the
> BAR address is 0, thus causing the bar->enabled field to also be set to
> false and allowing bar_write() to change the BAR position.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
>  xen/arch/x86/pci.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/xen/arch/x86/pci.c b/xen/arch/x86/pci.c
> index 26bb7f6a3c3a..39fd5a16a4aa 100644
> --- a/xen/arch/x86/pci.c
> +++ b/xen/arch/x86/pci.c
> @@ -101,6 +101,15 @@ int pci_conf_write_intercept(unsigned int seg, unsigned 
> int bdf,
>  
>  bool pci_check_bar(const struct pci_dev *pdev, mfn_t start, mfn_t end)
>  {
> +    /*
> +     * Refuse to map BARs at position 0, those are not initialized.  This 
> might
> +     * be required by Linux, that can reposition BARs with memory decoding
> +     * enabled.  By returning false here bar->enabled will be set to false, 
> and
> +     * bar_write() will work as expected.
> +     */

Technically speaking, the particular corner case is plausible.

However, if I understand it correctly, when Linux finds an uninitialized
BAR, it checks if the BAR (resource) has been allocated, and won't
enable memory decoding if unallocated. See Linux
drivers/pci/setup-res.c:pci_enable_resources().

So I would consider dropping the "This might be required by Linux"
part from the comment.

> +    if ( mfn_eq(start, _mfn(0)) )
> +        return false;
> +
>      /*
>       * Check if BAR is not overlapping with any memory region defined
>       * in the memory map.




 


Rackspace

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