All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Pau Monne <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [PATCH for-4.17 6/6] vpci: refuse BAR writes only if the BAR is mapped
Date: Thu, 20 Oct 2022 11:46:49 +0200	[thread overview]
Message-ID: <20221020094649.28667-7-roger.pau@citrix.com> (raw)
In-Reply-To: <20221020094649.28667-1-roger.pau@citrix.com>

Writes to the BARs are ignored if memory decoding is enabled for the
device, and the same happen with ROM BARs if the write is an attempt
to change the position of the BAR without disabling it first.

The reason of ignoring such writes is a limitation in Xen, as it would
need to unmap the BAR, change the address, and remap the BAR at the
new position, which the current logic doesn't support.

Some devices however seem to have the memory decoding bit hardcoded to
enabled, and attempts to disable it don't get reflected on the
command register.

This causes issues for well behaved guests that disable memory
decoding and then try to size the BARs, as vPCI will think memory
decoding is still enabled and ignore the write.

Since vPCI doesn't explicitly care about whether the memory decoding
bit is disabled as long as the BAR is not mapped in the guest p2m use
the information in the vpci_bar to check whether the BAR is mapped,
and refuse writes only based on that information.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/drivers/vpci/header.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 4d7f8f4a30..4b39737b76 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -388,7 +388,7 @@ static void cf_check bar_write(
     else
         val &= PCI_BASE_ADDRESS_MEM_MASK;
 
-    if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY )
+    if ( bar->enabled )
     {
         /* If the value written is the current one avoid printing a warning. */
         if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
@@ -425,7 +425,7 @@ static void cf_check rom_write(
     uint16_t cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND);
     bool new_enabled = val & PCI_ROM_ADDRESS_ENABLE;
 
-    if ( (cmd & PCI_COMMAND_MEMORY) && header->rom_enabled && new_enabled )
+    if ( rom->enabled && new_enabled )
     {
         gprintk(XENLOG_WARNING,
                 "%pp: ignored ROM BAR write with memory decoding enabled\n",
-- 
2.37.3



  parent reply	other threads:[~2022-10-20  9:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20  9:46 [PATCH for-4.17 0/6] (v)pci: fixes related to memory decoding handling Roger Pau Monne
2022-10-20  9:46 ` [PATCH for-4.17 1/6] test/vpci: add dummy cfcheck define Roger Pau Monne
2022-10-20  9:57   ` Andrew Cooper
2022-10-20 13:20   ` Anthony PERARD
2022-10-20  9:46 ` [PATCH for-4.17 2/6] test/vpci: fix vPCI test harness to provide pci_get_pdev() Roger Pau Monne
2022-10-20 13:21   ` Anthony PERARD
2022-10-20  9:46 ` [PATCH for-4.17 3/6] vpci: don't assume that vpci per-device data exists unconditionally Roger Pau Monne
2022-10-24 11:04   ` Jan Beulich
2022-10-24 16:01     ` Roger Pau Monné
2022-10-24 16:06       ` Jan Beulich
2022-10-20  9:46 ` [PATCH for-4.17 4/6] vpci: introduce a local vpci_bar variable to modify_decoding() Roger Pau Monne
2022-10-24 11:05   ` Jan Beulich
2022-10-20  9:46 ` [PATCH for-4.17 5/6] pci: do not disable memory decoding for devices Roger Pau Monne
2022-10-24 11:19   ` Jan Beulich
2022-10-24 12:45     ` Roger Pau Monné
2022-10-24 13:59       ` Jan Beulich
2022-10-24 15:45         ` Roger Pau Monné
2022-10-24 15:56           ` Jan Beulich
2022-10-24 16:24             ` Roger Pau Monné
2022-10-20  9:46 ` Roger Pau Monne [this message]
2022-10-24 11:51   ` [PATCH for-4.17 6/6] vpci: refuse BAR writes only if the BAR is mapped Jan Beulich
2022-10-24 15:04     ` Roger Pau Monné
2022-10-24 16:03       ` Jan Beulich
2022-10-20 10:12 ` [PATCH for-4.17 0/6] (v)pci: fixes related to memory decoding handling Henry Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221020094649.28667-7-roger.pau@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.