All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: xen-devel@lists.xenproject.org, Huang Rui <ray.huang@amd.com>
Subject: Re: [PATCH v2 2/8] vpci/header: Emulate legacy capability list for host
Date: Tue, 15 Apr 2025 11:25:20 +0200	[thread overview]
Message-ID: <Z_4mAAm-gCmZTJub@macbook.lan> (raw)
In-Reply-To: <20250409064528.405573-3-Jiqian.Chen@amd.com>

On Wed, Apr 09, 2025 at 02:45:22PM +0800, Jiqian Chen wrote:
> Current logic of init_header() only emulates legacy capability list
> for guest, expand it to emulate for host too. So that it will be
> easy to hide a capability whose initialization fails and no need
> to distinguish host or guest.

It might be best if the initial code movement of the logic in
init_header() into it's own separate function was done as a
non-functional change, and a later patch added support for dom0.

It's easier to then spot the differences that you are adding to
support dom0.

> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
> cc: "Roger Pau Monné" <roger.pau@citrix.com>
> ---
> v1->v2 changes:
> new patch
> 
> Best regards,
> Jiqian Chen.
> ---
>  xen/drivers/vpci/header.c | 139 ++++++++++++++++++++------------------
>  1 file changed, 74 insertions(+), 65 deletions(-)
> 
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index ef6c965c081c..0910eb940e23 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -745,6 +745,76 @@ static int bar_add_rangeset(const struct pci_dev *pdev, struct vpci_bar *bar,
>      return !bar->mem ? -ENOMEM : 0;
>  }
>  
> +/* These capabilities can be exposed to the guest, that vPCI can handle. */
> +static const unsigned int guest_supported_caps[] = {
> +    PCI_CAP_ID_MSI,
> +    PCI_CAP_ID_MSIX,
> +};

Is there a reason this needs to be defined outside of the function
scope?  So far it's only used by vpci_init_capability_list().

> +
> +static int vpci_init_capability_list(struct pci_dev *pdev)
> +{
> +    int rc;
> +    bool mask_cap_list = false;
> +    bool is_hwdom = is_hardware_domain(pdev->domain);
> +    const unsigned int *caps = is_hwdom ? NULL : guest_supported_caps;
> +    const unsigned int n = is_hwdom ? 0 : ARRAY_SIZE(guest_supported_caps);
> +
> +    if ( pci_conf_read16(pdev->sbdf, PCI_STATUS) & PCI_STATUS_CAP_LIST )
> +    {
> +        unsigned int next, ttl = 48;
> +
> +        next = pci_find_next_cap_ttl(pdev->sbdf, PCI_CAPABILITY_LIST,
> +                                     caps, n, &ttl);
> +
> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, NULL,
> +                               PCI_CAPABILITY_LIST, 1,
> +                               (void *)(uintptr_t)next);
> +        if ( rc )
> +            return rc;
> +
> +        next &= ~3;
> +
> +        if ( !next && !is_hwdom )
> +            /*
> +             * If we don't have any supported capabilities to expose to the
> +             * guest, mask the PCI_STATUS_CAP_LIST bit in the status register.
> +             */
> +            mask_cap_list = true;
> +
> +        while ( next && ttl )
> +        {
> +            unsigned int pos = next;
> +
> +            next = pci_find_next_cap_ttl(pdev->sbdf, pos + PCI_CAP_LIST_NEXT,
> +                                         caps, n, &ttl);
> +
> +            rc = vpci_add_register(pdev->vpci, vpci_hw_read8, NULL,
> +                                   pos + PCI_CAP_LIST_ID, 1, NULL);

There's no need to add this handler for the hardware domain, that's
already the default behavior in that case.

Thanks, Roger.


  parent reply	other threads:[~2025-04-15  9:25 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09  6:45 [PATCH v2 0/8] Support hiding capability when its initialization fails Jiqian Chen
2025-04-09  6:45 ` [PATCH v2 1/8] driver/pci: Get next capability without passing caps Jiqian Chen
2025-04-10 12:34   ` Jan Beulich
2025-04-11  2:51     ` Chen, Jiqian
2025-04-11  8:00       ` Jan Beulich
2025-04-11  8:08         ` Chen, Jiqian
2025-04-09  6:45 ` [PATCH v2 2/8] vpci/header: Emulate legacy capability list for host Jiqian Chen
2025-04-10 12:40   ` Jan Beulich
2025-04-11  2:54     ` Chen, Jiqian
2025-04-11  8:01       ` Jan Beulich
2025-04-15  9:25   ` Roger Pau Monné [this message]
2025-04-15 10:07     ` Chen, Jiqian
2025-04-15 10:08       ` Jan Beulich
2025-04-15 10:23         ` Chen, Jiqian
2025-04-15 10:50       ` Roger Pau Monné
2025-04-15 10:10   ` Roger Pau Monné
2025-04-16  2:51     ` Chen, Jiqian
2025-04-16  7:32       ` Roger Pau Monné
2025-04-09  6:45 ` [PATCH v2 3/8] vpci/header: Emulate extended " Jiqian Chen
2025-04-15  9:42   ` Roger Pau Monné
2025-04-15 10:11     ` Chen, Jiqian
2025-04-15  9:49   ` Jan Beulich
2025-04-15 10:18     ` Chen, Jiqian
2025-04-15 10:20       ` Jan Beulich
2025-04-09  6:45 ` [PATCH v2 4/8] vpci: Hide capability when it fails to initialize Jiqian Chen
2025-04-15 10:47   ` Roger Pau Monné
2025-04-16  6:07     ` Chen, Jiqian
2025-04-09  6:45 ` [PATCH v2 5/8] vpci: Refactor vpci_remove_register to remove matched registers Jiqian Chen
2025-04-15 11:06   ` Roger Pau Monné
2025-04-09  6:45 ` [PATCH v2 6/8] vpci/rebar: Remove registers when init_rebar() fails Jiqian Chen
2025-04-15 12:59   ` Roger Pau Monné
2025-04-09  6:45 ` [PATCH v2 7/8] vpci/msi: Free MSI resources when init_msi() fails Jiqian Chen
2025-04-15 13:29   ` Roger Pau Monné
2025-04-16  6:16     ` Chen, Jiqian
2025-04-16  7:47       ` Roger Pau Monné
2025-04-09  6:45 ` [PATCH v2 8/8] vpci/msix: Add function to clean MSIX resources Jiqian Chen
2025-04-15 13:45   ` Roger Pau Monné
2025-04-16  6:20     ` Chen, Jiqian
2025-04-16  7:54       ` Roger Pau Monné
2025-04-17  7:34   ` Jan Beulich
2025-04-17  7:38     ` Chen, Jiqian

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=Z_4mAAm-gCmZTJub@macbook.lan \
    --to=roger.pau@citrix.com \
    --cc=Jiqian.Chen@amd.com \
    --cc=ray.huang@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.