| Message ID | 20240112061317.418658-2-Jiqian.Chen@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Support device passthrough when dom0 is PVH on Xen | expand |
On 1/12/24 01:13, Jiqian Chen wrote: > When a device has been reset on dom0 side, the vpci on Xen > side won't get notification, so the cached state in vpci is > all out of date compare with the real device state. > To solve that problem, add a new hypercall to clear all vpci > device state. When the state of device is reset on dom0 side, > dom0 can call this hypercall to notify vpci. > > Co-developed-by: Huang Rui <ray.huang@amd.com> > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com> If you send another version, the RFC tag may be dropped. One thing to keep an eye out for below (not requesting any changes). > --- > diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c > index 72ef277c4f8e..c6df2c6a9561 100644 > --- a/xen/drivers/vpci/vpci.c > +++ b/xen/drivers/vpci/vpci.c > @@ -107,6 +107,16 @@ int vpci_add_handlers(struct pci_dev *pdev) > > return rc; > } > + > +int vpci_reset_device_state(struct pci_dev *pdev) > +{ > + ASSERT(pcidevs_locked()); > + ASSERT(rw_is_write_locked(&pdev->domain->pci_lock)); > + > + vpci_remove_device(pdev); > + return vpci_add_handlers(pdev); Note that these two functions may be renamed soon by the patch at [1]. Whichever patch goes in later will need to be rebased to account for the rename. [1] https://lists.xenproject.org/archives/html/xen-devel/2024-02/msg00134.html > +} > + > #endif /* __XEN__ */ > > static int vpci_register_cmp(const struct vpci_register *r1,
Hi Stewart, On 2024/2/10 02:02, Stewart Hildebrand wrote: > On 1/12/24 01:13, Jiqian Chen wrote: >> When a device has been reset on dom0 side, the vpci on Xen >> side won't get notification, so the cached state in vpci is >> all out of date compare with the real device state. >> To solve that problem, add a new hypercall to clear all vpci >> device state. When the state of device is reset on dom0 side, >> dom0 can call this hypercall to notify vpci. >> >> Co-developed-by: Huang Rui <ray.huang@amd.com> >> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > > Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Thanks, I will add in next version. > > If you send another version, the RFC tag may be dropped. Does only this one patch, or all patches of this series, need to drop RFC tag? > > One thing to keep an eye out for below (not requesting any changes). Thanks for reminding me, I will always keep rebasing my code from latest staging branch before sending new version. > >> --- >> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c >> index 72ef277c4f8e..c6df2c6a9561 100644 >> --- a/xen/drivers/vpci/vpci.c >> +++ b/xen/drivers/vpci/vpci.c >> @@ -107,6 +107,16 @@ int vpci_add_handlers(struct pci_dev *pdev) >> >> return rc; >> } >> + >> +int vpci_reset_device_state(struct pci_dev *pdev) >> +{ >> + ASSERT(pcidevs_locked()); >> + ASSERT(rw_is_write_locked(&pdev->domain->pci_lock)); >> + >> + vpci_remove_device(pdev); >> + return vpci_add_handlers(pdev); > > Note that these two functions may be renamed soon by the patch at [1]. > Whichever patch goes in later will need to be rebased to account for the > rename. > > [1] https://lists.xenproject.org/archives/html/xen-devel/2024-02/msg00134.html > >> +} >> + >> #endif /* __XEN__ */ >> >> static int vpci_register_cmp(const struct vpci_register *r1, >
On 2/22/24 01:22, Chen, Jiqian wrote: > Hi Stewart, > > On 2024/2/10 02:02, Stewart Hildebrand wrote: >> On 1/12/24 01:13, Jiqian Chen wrote: >>> When a device has been reset on dom0 side, the vpci on Xen >>> side won't get notification, so the cached state in vpci is >>> all out of date compare with the real device state. >>> To solve that problem, add a new hypercall to clear all vpci >>> device state. When the state of device is reset on dom0 side, >>> dom0 can call this hypercall to notify vpci. >>> >>> Co-developed-by: Huang Rui <ray.huang@amd.com> >>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> >> >> Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com> > Thanks, I will add in next version. > >> >> If you send another version, the RFC tag may be dropped. > Does only this one patch, or all patches of this series, need to drop RFC tag? In my opinion at least patches 1, 2, and 3. If you decide to retain the RFC tag on e.g. patches 4 and/or 5, you may want to include after the commit description a scissors line --- followed by a brief explanation for the RFC tag. For example: --- RFC: discussions ongoing on the Linux side where/how to expose the gsi >> >> One thing to keep an eye out for below (not requesting any changes). > Thanks for reminding me, I will always keep rebasing my code from latest staging branch before sending new version. > >> >>> --- >>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c >>> index 72ef277c4f8e..c6df2c6a9561 100644 >>> --- a/xen/drivers/vpci/vpci.c >>> +++ b/xen/drivers/vpci/vpci.c >>> @@ -107,6 +107,16 @@ int vpci_add_handlers(struct pci_dev *pdev) >>> >>> return rc; >>> } >>> + >>> +int vpci_reset_device_state(struct pci_dev *pdev) >>> +{ >>> + ASSERT(pcidevs_locked()); >>> + ASSERT(rw_is_write_locked(&pdev->domain->pci_lock)); >>> + >>> + vpci_remove_device(pdev); >>> + return vpci_add_handlers(pdev); >> >> Note that these two functions may be renamed soon by the patch at [1]. >> Whichever patch goes in later will need to be rebased to account for the >> rename. >> >> [1] https://lists.xenproject.org/archives/html/xen-devel/2024-02/msg00134.html >> >>> +} >>> + >>> #endif /* __XEN__ */ >>> >>> static int vpci_register_cmp(const struct vpci_register *r1, >> >
On Fri, 9 Feb 2024, Stewart Hildebrand wrote: > On 1/12/24 01:13, Jiqian Chen wrote: > > When a device has been reset on dom0 side, the vpci on Xen > > side won't get notification, so the cached state in vpci is > > all out of date compare with the real device state. > > To solve that problem, add a new hypercall to clear all vpci > > device state. When the state of device is reset on dom0 side, > > dom0 can call this hypercall to notify vpci. > > > > Co-developed-by: Huang Rui <ray.huang@amd.com> > > Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> > > Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c index eeb73e1aa5d0..6ad5b4d5f11f 100644 --- a/xen/arch/x86/hvm/hypercall.c +++ b/xen/arch/x86/hvm/hypercall.c @@ -84,6 +84,7 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case PHYSDEVOP_pci_mmcfg_reserved: case PHYSDEVOP_pci_device_add: case PHYSDEVOP_pci_device_remove: + case PHYSDEVOP_pci_device_state_reset: case PHYSDEVOP_dbgp_op: if ( !is_hardware_domain(currd) ) return -ENOSYS; diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c index 42db3e6d133c..73dc8f058b0e 100644 --- a/xen/drivers/pci/physdev.c +++ b/xen/drivers/pci/physdev.c @@ -2,6 +2,7 @@ #include <xen/guest_access.h> #include <xen/hypercall.h> #include <xen/init.h> +#include <xen/vpci.h> #ifndef COMPAT typedef long ret_t; @@ -67,6 +68,41 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) break; } + case PHYSDEVOP_pci_device_state_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, arg, 1) != 0 ) + break; + 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); + ret = vpci_reset_device_state(pdev); + write_unlock(&pdev->domain->pci_lock); + pcidevs_unlock(); + if ( ret ) + printk(XENLOG_ERR "%pp: failed to reset PCI device state\n", &sbdf); + break; + } + default: ret = -ENOSYS; break; diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c index 72ef277c4f8e..c6df2c6a9561 100644 --- a/xen/drivers/vpci/vpci.c +++ b/xen/drivers/vpci/vpci.c @@ -107,6 +107,16 @@ int vpci_add_handlers(struct pci_dev *pdev) return rc; } + +int vpci_reset_device_state(struct pci_dev *pdev) +{ + ASSERT(pcidevs_locked()); + ASSERT(rw_is_write_locked(&pdev->domain->pci_lock)); + + vpci_remove_device(pdev); + return vpci_add_handlers(pdev); +} + #endif /* __XEN__ */ static int vpci_register_cmp(const struct vpci_register *r1, diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h index f0c0d4727c0b..f5bab1f29779 100644 --- a/xen/include/public/physdev.h +++ b/xen/include/public/physdev.h @@ -296,6 +296,13 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_add_t); */ #define PHYSDEVOP_prepare_msix 30 #define PHYSDEVOP_release_msix 31 +/* + * Notify the hypervisor that a PCI device has been reset, so that any + * internally cached state is regenerated. Should be called after any + * device reset performed by the hardware domain. + */ +#define PHYSDEVOP_pci_device_state_reset 32 + struct physdev_pci_device { /* IN */ uint16_t seg; diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h index d20c301a3db3..6ec83ce9ae13 100644 --- a/xen/include/xen/vpci.h +++ b/xen/include/xen/vpci.h @@ -30,6 +30,7 @@ int __must_check vpci_add_handlers(struct pci_dev *pdev); /* Remove all handlers and free vpci related structures. */ void vpci_remove_device(struct pci_dev *pdev); +int __must_check vpci_reset_device_state(struct pci_dev *pdev); /* Add/remove a register handler. */ int __must_check vpci_add_register_mask(struct vpci *vpci, @@ -262,6 +263,11 @@ static inline int vpci_add_handlers(struct pci_dev *pdev) static inline void vpci_remove_device(struct pci_dev *pdev) { } +static inline int __must_check vpci_reset_device_state(struct pci_dev *pdev) +{ + return 0; +} + static inline void vpci_dump_msi(void) { } static inline uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg,
When a device has been reset on dom0 side, the vpci on Xen side won't get notification, so the cached state in vpci is all out of date compare with the real device state. To solve that problem, add a new hypercall to clear all vpci device state. When the state of device is reset on dom0 side, dom0 can call this hypercall to notify vpci. Co-developed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> --- xen/arch/x86/hvm/hypercall.c | 1 + xen/drivers/pci/physdev.c | 36 ++++++++++++++++++++++++++++++++++++ xen/drivers/vpci/vpci.c | 10 ++++++++++ xen/include/public/physdev.h | 7 +++++++ xen/include/xen/vpci.h | 6 ++++++ 5 files changed, 60 insertions(+)