From: Jan Beulich <jbeulich@suse.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"George Dunlap" <george.dunlap@citrix.com>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Anthony PERARD" <anthony@xenproject.org>,
"Juergen Gross" <jgross@suse.com>,
"Daniel P . Smith" <dpsmith@apertussolutions.com>,
"Stewart Hildebrand" <Stewart.Hildebrand@amd.com>,
"Huang Rui" <Ray.Huang@amd.com>,
xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH v10 1/5] xen/vpci: Clear all vpci status of device
Date: Mon, 17 Jun 2024 16:17:06 +0200 [thread overview]
Message-ID: <4e2accc2-e81d-450a-af2d-38884455de9c@suse.com> (raw)
In-Reply-To: <20240617090035.839640-2-Jiqian.Chen@amd.com>
On 17.06.2024 11:00, Jiqian Chen wrote:
> --- a/xen/drivers/pci/physdev.c
> +++ b/xen/drivers/pci/physdev.c
> @@ -2,11 +2,17 @@
> #include <xen/guest_access.h>
> #include <xen/hypercall.h>
> #include <xen/init.h>
> +#include <xen/vpci.h>
>
> #ifndef COMPAT
> typedef long ret_t;
> #endif
>
> +static const struct pci_device_state_reset_method
> + pci_device_state_reset_methods[] = {
> + [ DEVICE_RESET_FLR ].reset_fn = vpci_reset_device_state,
> +};
What about the other three DEVICE_RESET_*? In particular ...
> @@ -67,6 +73,43 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> break;
> }
>
> + case PHYSDEVOP_pci_device_state_reset: {
> + struct pci_device_state_reset dev_reset;
> + struct physdev_pci_device *dev;
> + struct pci_dev *pdev;
> + pci_sbdf_t sbdf;
> +
> + if ( !is_pci_passthrough_enabled() )
> + return -EOPNOTSUPP;
> +
> + ret = -EFAULT;
> + if ( copy_from_guest(&dev_reset, arg, 1) != 0 )
> + break;
> + dev = &dev_reset.dev;
> + sbdf = PCI_SBDF(dev->seg, dev->bus, dev->devfn);
> +
> + ret = xsm_resource_setup_pci(XSM_PRIV, sbdf.sbdf);
> + if ( ret )
> + break;
> +
> + pcidevs_lock();
> + pdev = pci_get_pdev(NULL, sbdf);
> + if ( !pdev )
> + {
> + pcidevs_unlock();
> + ret = -ENODEV;
> + break;
> + }
> +
> + write_lock(&pdev->domain->pci_lock);
> + pcidevs_unlock();
> + ret = pci_device_state_reset_methods[dev_reset.reset_type].reset_fn(pdev);
... you're setting this up for calling NULL. In fact there's also no bounds
check for the array index.
Also, nit (further up): Opening figure braces for a new scope go onto their
own line. Then again I notice that apparenly _all_ other instances in this
file are doing it the wrong way, too.
Finally, is the "dev" local variable really needed? It effectively hides that
PCI_SBDF() is invoked on the hypercall arguments.
> + write_unlock(&pdev->domain->pci_lock);
> + if ( ret )
> + printk(XENLOG_ERR "%pp: failed to reset vPCI device state\n", &sbdf);
Maybe downgrade to dprintk()? The caller ought to handle the error anyway.
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -172,6 +172,15 @@ int vpci_assign_device(struct pci_dev *pdev)
>
> return rc;
> }
> +
> +int vpci_reset_device_state(struct pci_dev *pdev)
As a target of an indirect call this needs to be annotated cf_check (both
here and in the declaration, unlike __must_check, which is sufficient to
have on just the declaration).
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -156,6 +156,22 @@ struct pci_dev {
> struct vpci *vpci;
> };
>
> +struct pci_device_state_reset_method {
> + int (*reset_fn)(struct pci_dev *pdev);
> +};
> +
> +enum pci_device_state_reset_type {
> + DEVICE_RESET_FLR,
> + DEVICE_RESET_COLD,
> + DEVICE_RESET_WARM,
> + DEVICE_RESET_HOT,
> +};
> +
> +struct pci_device_state_reset {
> + struct physdev_pci_device dev;
> + enum pci_device_state_reset_type reset_type;
> +};
This is the struct to use as hypercall argument. How can it live outside of
any public header? Also, when moving it there, beware that you should not
use enum-s there. Only handles and fixed-width types are permitted.
> --- a/xen/include/xen/vpci.h
> +++ b/xen/include/xen/vpci.h
> @@ -38,6 +38,7 @@ int __must_check vpci_assign_device(struct pci_dev *pdev);
>
> /* Remove all handlers and free vpci related structures. */
> void vpci_deassign_device(struct pci_dev *pdev);
> +int __must_check vpci_reset_device_state(struct pci_dev *pdev);
What's the purpose of this __must_check, when the sole caller is calling
this through a function pointer, which isn't similarly annotated?
Jan
next prev parent reply other threads:[~2024-06-17 14:17 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 9:00 [XEN PATCH v10 0/5] Support device passthrough when dom0 is PVH on Xen Jiqian Chen
2024-06-17 9:00 ` [XEN PATCH v10 1/5] xen/vpci: Clear all vpci status of device Jiqian Chen
2024-06-17 14:17 ` Jan Beulich [this message]
2024-06-18 6:25 ` Chen, Jiqian
2024-06-18 8:33 ` Jan Beulich
2024-06-19 3:39 ` Chen, Jiqian
2024-06-19 7:02 ` Jan Beulich
2024-06-17 9:00 ` [XEN PATCH v10 2/5] x86/pvh: Allow (un)map_pirq when dom0 is PVH Jiqian Chen
2024-06-17 14:45 ` Jan Beulich
2024-06-18 6:49 ` Chen, Jiqian
2024-06-18 8:38 ` Jan Beulich
2024-06-19 5:35 ` Chen, Jiqian
2024-06-17 9:00 ` [XEN PATCH v10 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0 Jiqian Chen
2024-06-17 14:52 ` Jan Beulich
2024-06-18 6:57 ` Chen, Jiqian
2024-06-18 8:55 ` Jan Beulich
2024-06-19 7:53 ` Chen, Jiqian
2024-06-19 8:06 ` Jan Beulich
2024-06-19 8:51 ` Chen, Jiqian
2024-06-19 9:49 ` Jan Beulich
2024-06-19 10:10 ` Chen, Jiqian
2024-06-17 9:00 ` [XEN PATCH v10 4/5] tools: Add new function to get gsi from dev Jiqian Chen
2024-06-17 15:10 ` Jan Beulich
2024-06-18 8:10 ` Chen, Jiqian
2024-06-18 9:13 ` Jan Beulich
2024-06-20 7:03 ` Chen, Jiqian
2024-06-20 7:43 ` Jan Beulich
2024-06-20 10:23 ` Chen, Jiqian
2024-06-20 10:37 ` Jan Beulich
2024-06-21 8:15 ` Chen, Jiqian
2024-06-24 8:13 ` Jan Beulich
2024-06-25 7:38 ` Chen, Jiqian
2024-06-20 14:38 ` Anthony PERARD
2024-06-21 8:34 ` Chen, Jiqian
2024-06-24 12:08 ` Anthony PERARD
2024-06-17 9:00 ` [XEN PATCH v10 5/5] domctl: Add XEN_DOMCTL_gsi_permission to grant gsi Jiqian Chen
2024-06-17 9:15 ` Chen, Jiqian
2024-06-17 15:32 ` Jan Beulich
2024-06-18 8:23 ` Chen, Jiqian
2024-06-18 9:23 ` Jan Beulich
2024-06-20 9:40 ` Chen, Jiqian
2024-06-20 10:42 ` Jan Beulich
2024-06-21 8:20 ` Chen, Jiqian
2024-06-24 8:17 ` Jan Beulich
2024-06-25 7:44 ` Chen, Jiqian
2024-06-25 7:48 ` Jan Beulich
2024-06-24 12:33 ` Anthony PERARD
2024-06-25 7:46 ` 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=4e2accc2-e81d-450a-af2d-38884455de9c@suse.com \
--to=jbeulich@suse.com \
--cc=Jiqian.Chen@amd.com \
--cc=Ray.Huang@amd.com \
--cc=Stewart.Hildebrand@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony@xenproject.org \
--cc=dpsmith@apertussolutions.com \
--cc=george.dunlap@citrix.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--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.