From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Stewart Hildebrand" <stewart.hildebrand@amd.com>,
<xen-devel@lists.xenproject.org>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] [RFC] vpci: allow BAR write while mapped
Date: Fri, 14 Mar 2025 10:39:04 +0000 [thread overview]
Message-ID: <D8FXALVEWMGZ.2C16ABCKLKQRY@cloud.com> (raw)
In-Reply-To: <7b4f47c2-ce03-44e9-907a-acd56e56a9ff@amd.com>
On Thu Mar 13, 2025 at 5:43 PM GMT, Stewart Hildebrand wrote:
> The idea was that the unmap-then-map operation would appear atomic from
> the guest's point of view. I've only queued up the unmap operation at
> this point in the new logic. Due to the mentioned limitation in the BAR
> mapping deferral machinery, I wanted to make sure *this BAR* was
> unmapped before queuing up the map operation (see below). Waiting for
> *all* pending operations to finish here is likely not appropriate.
Looking more closely after reading Roger's answer, I misunderstood what was
being queued where. There's space for a single deferred operation that's
retried if pending on each attempt to resume the vCPU, whereas I initially
thought it was the mutations to the p2m (which would've competed with other
mutations from other vCPUs). This makes more sense, sorry for the noise.
> I think this just reinforces the need to rework the BAR mapping
> machinery.
Right. The most delicate part is dealing with races with another vCPU when the
unmap-then-map operation does not complete in a single taking of the vpci lock
I'd say. And that much is unavoidable, I think, because either unmapping or
mapping might take a while.
>
> > Do you know if Linux intentionally skips disabling decode? Or is it a bug?
>
> I think it's intentional. See https://gitlab.com/xen-project/xen/-/issues/197
Interesting. I seemed to recall some devices being able to decode their own BAR
accesses. But I must've been wrong.
>
> >> + }
> >> + }
> >> + else
> >> + return;
> >> }
> >>
> >>
> >> @@ -610,6 +647,10 @@ static void cf_check bar_write(
> >> }
> >>
> >> pci_conf_write32(pdev->sbdf, reg, val);
> >> +
> >> + if ( reenable )
> >> + /* Write-while-mapped: map the new BAR in p2m. OK to defer. */
> >> + modify_bars(pdev, cmd, false);
>
> This call to modify_bars() will raise a softirq for the map operation.
Ah, fair enough. I clearly didn't look closely enough.
Cheers,
Alejandro
next prev parent reply other threads:[~2025-03-14 10:39 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 [this message]
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é
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=D8FXALVEWMGZ.2C16ABCKLKQRY@cloud.com \
--to=alejandro.vallejo@cloud.com \
--cc=roger.pau@citrix.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.