From: "Roger Pau Monné" <roger.pau@citrix.com>
To: "Chen, Jiqian" <Jiqian.Chen@amd.com>
Cc: Jan Beulich <jbeulich@suse.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Huang, Ray" <Ray.Huang@amd.com>
Subject: Re: [PATCH v7 1/8] vpci/header: Emulate extended capability list for dom0
Date: Mon, 21 Jul 2025 16:16:40 +0200 [thread overview]
Message-ID: <aH5LyM0og-vEDmTV@macbook.local> (raw)
In-Reply-To: <BL1PR12MB584906633E31701F71330325E749A@BL1PR12MB5849.namprd12.prod.outlook.com>
On Wed, Jul 09, 2025 at 05:34:28AM +0000, Chen, Jiqian wrote:
> On 2025/7/9 13:32, Jan Beulich wrote:
> > On 09.07.2025 07:29, Chen, Jiqian wrote:
> >> On 2025/7/8 22:10, Jan Beulich wrote:
> >>> On 04.07.2025 09:07, Jiqian Chen wrote:
> >>>> --- a/xen/drivers/vpci/header.c
> >>>> +++ b/xen/drivers/vpci/header.c
> >>>> @@ -836,6 +836,39 @@ static int vpci_init_capability_list(struct pci_dev *pdev)
> >>>> PCI_STATUS_RSVDZ_MASK);
> >>>> }
> >>>>
> >>>> +static int vpci_init_ext_capability_list(const struct pci_dev *pdev)
> >>>> +{
> >>>> + unsigned int pos = PCI_CFG_SPACE_SIZE;
> >>>> +
> >>>> + if ( !is_hardware_domain(pdev->domain) )
> >>>> + /* Extended capabilities read as zero, write ignore for DomU */
> >>>> + return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> >>>> + pos, 4, (void *)0);
> >>>> +
> >>>> + do
> >>>> + {
> >>>> + uint32_t header = pci_conf_read32(pdev->sbdf, pos);
> >>>> + int rc;
> >>>> +
> >>>> + rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
> >>>> + pos, 4, (void *)(uintptr_t)header);
> >>>
> >>> If it wasn't for this use of vpci_hw_write32(), I'd be happy to provide my
> >>> R-b. But this continues to look bogus to me: What use is it to allow writes
> >>> when Dom0 then can't read back any possible effect of such a write (in the
> >>> unexpected event that some of the bits were indeed writable)?
> >> Oh, I got your concern.
> >> What do you think about updating the header value after writing to hardware in write function?
>
> > That would imo be a layering violation. Once again that's something that you
> > primarily would need Roger's input on.
> OK, wait for Roger's input.
Hm, I see the asymmetry of allowing writes but not direct writes, my
thought was to give the hw domain as less interference as possibly,
hence my recommendation to use vpci_hw_write32().
I practice I think it's very unlikely that devices re-use reserved
bits in the capability register, so I'm fine with using NULL (thus
discarding the write). We can always add more complex handling here
if we ever came across a device that requires it.
Thanks, Roger.
next prev parent reply other threads:[~2025-07-21 14:16 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 7:07 [PATCH v7 0/8] Support hiding capability when its initialization fails Jiqian Chen
2025-07-04 7:07 ` [PATCH v7 1/8] vpci/header: Emulate extended capability list for dom0 Jiqian Chen
2025-07-08 14:10 ` Jan Beulich
2025-07-09 5:29 ` Chen, Jiqian
2025-07-09 5:32 ` Jan Beulich
2025-07-09 5:34 ` Chen, Jiqian
2025-07-21 14:16 ` Roger Pau Monné [this message]
2025-07-23 6:45 ` Chen, Jiqian
2025-07-04 7:07 ` [PATCH v7 2/8] vpci: Refactor REGISTER_VPCI_INIT Jiqian Chen
2025-07-08 14:52 ` Jan Beulich
2025-07-21 14:37 ` Roger Pau Monné
2025-07-23 7:20 ` Chen, Jiqian
2025-07-23 8:19 ` Roger Pau Monné
2025-07-04 7:07 ` [PATCH v7 3/8] vpci: Hide legacy capability when it fails to initialize Jiqian Chen
2025-07-21 15:48 ` Roger Pau Monné
2025-07-23 7:33 ` Chen, Jiqian
2025-07-23 8:15 ` Roger Pau Monné
2025-07-04 7:07 ` [PATCH v7 4/8] vpci: Hide extended " Jiqian Chen
2025-07-21 16:04 ` Roger Pau Monné
2025-07-04 7:08 ` [PATCH v7 5/8] vpci: Refactor vpci_remove_register to remove matched registers Jiqian Chen
2025-07-04 7:08 ` [PATCH v7 6/8] vpci/rebar: Free Rebar resources when init_rebar() fails Jiqian Chen
2025-07-21 16:08 ` Roger Pau Monné
2025-07-04 7:08 ` [PATCH v7 7/8] vpci/msi: Free MSI resources when init_msi() fails Jiqian Chen
2025-07-08 15:13 ` Jan Beulich
2025-07-09 6:10 ` Chen, Jiqian
2025-07-09 6:49 ` Jan Beulich
2025-07-21 16:21 ` Roger Pau Monné
2025-07-23 7:54 ` Chen, Jiqian
2025-07-23 9:39 ` Jan Beulich
2025-07-04 7:08 ` [PATCH v7 8/8] vpci/msix: Free MSIX resources when init_msix() fails Jiqian Chen
2025-07-21 16:24 ` Roger Pau Monné
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=aH5LyM0og-vEDmTV@macbook.local \
--to=roger.pau@citrix.com \
--cc=Jiqian.Chen@amd.com \
--cc=Ray.Huang@amd.com \
--cc=jbeulich@suse.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.