From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
Stewart Hildebrand <stewart.hildebrand@amd.com>
Subject: Re: [PATCH] [RFC] vpci: allow BAR write while mapped
Date: Fri, 14 Mar 2025 09:21:32 +0100 [thread overview]
Message-ID: <Z9PnDOn4t0vzApaQ@macbook.local> (raw)
In-Reply-To: <9e619631-a7f7-4f69-aff8-13202d61b79a@suse.com>
On Fri, Mar 14, 2025 at 09:04:55AM +0100, Jan Beulich wrote:
> On 13.03.2025 18:48, Roger Pau Monné wrote:
> > On Wed, Mar 12, 2025 at 03:50:17PM -0400, Stewart Hildebrand wrote:
> >> @@ -585,10 +601,31 @@ static void cf_check bar_write(
> >> {
> >> /* If the value written is the current one avoid printing a warning. */
> >> if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) )
> >> + {
> >> gprintk(XENLOG_WARNING,
> >> - "%pp: ignored BAR %zu write while mapped\n",
> >> + "%pp: allowing BAR %zu write while mapped\n",
> >> &pdev->sbdf, bar - pdev->vpci->header.bars + hi);
> >
> > If Xen now handles BARs writes with memory decoding enabled the
> > message can be removed. It's only purpose was to signal this missing
> > handling.
> >
> >> - return;
> >> + ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
> >> + ASSERT(spin_is_locked(&pdev->vpci->lock));
> >> + reenable = true;
> >> + cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND);
> >> + /*
> >> + * Write-while-mapped: unmap the old BAR in p2m. We want this to
> >> + * finish right away since the deferral machinery only supports
> >> + * unmap OR map, not unmap-then-remap. Ultimately, it probably would
> >> + * be better to defer the write-while-mapped case just like regular
> >> + * BAR writes (but still only allow it for 32-bit BAR writes).
> >> + */
> >> + /* Disable memory decoding */
> >> + modify_bars(pdev, cmd & ~PCI_COMMAND_MEMORY, false);
> >
> > I think if the guest explicitly avoids toggling memory decoding Xen
> > should also to the same, and not touch the bit.
>
> For Dom0 I'm inclined to agree, but for DomU-s it may be unsafe to do so.
> (You may have meant it like this, but you said "guest".)
Sorry, I'm not sure I'm following. For domUs the BAR register write
is not propagated to the hardware, it's just the p2m mappings that
change, and hence it's even safer to not toggle the memory decoding
bit for that case? (as there's no write to the device BAR registers
for domUs).
Maybe there's some aspect I'm missing.
Thanks, Roger.
next prev parent reply other threads:[~2025-03-14 8:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 19:50 [PATCH] [RFC] vpci: allow BAR write while mapped Stewart Hildebrand
2025-03-13 15:14 ` Alejandro Vallejo
2025-03-13 17:43 ` Stewart Hildebrand
2025-03-14 10:39 ` Alejandro Vallejo
2025-03-17 12:32 ` Roger Pau Monné
2025-03-17 13:49 ` Alejandro Vallejo
2025-03-13 17:58 ` Roger Pau Monné
2025-03-13 17:48 ` Roger Pau Monné
2025-03-13 18:28 ` Stewart Hildebrand
2025-03-14 8:04 ` Jan Beulich
2025-03-14 8:21 ` Roger Pau Monné [this message]
2025-03-14 8:26 ` Jan Beulich
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=Z9PnDOn4t0vzApaQ@macbook.local \
--to=roger.pau@citrix.com \
--cc=jbeulich@suse.com \
--cc=stewart.hildebrand@amd.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.