| Message ID | 20240105070920.350113-2-Jiqian.Chen@amd.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Support device passthrough when dom0 is PVH on Xen | expand |
On 1/5/24 02:09, Jiqian Chen wrote: > diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c > index 42db3e6d133c..552ccbf747cb 100644 > --- a/xen/drivers/pci/physdev.c > +++ b/xen/drivers/pci/physdev.c > @@ -67,6 +68,39 @@ 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..3c64cb10ccbb 100644 > --- a/xen/drivers/vpci/vpci.c > +++ b/xen/drivers/vpci/vpci.c > @@ -107,6 +107,15 @@ 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,
On 2024/1/9 23:24, Stewart Hildebrand wrote: > On 1/5/24 02:09, Jiqian Chen wrote: >> diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c >> index 42db3e6d133c..552ccbf747cb 100644 >> --- a/xen/drivers/pci/physdev.c >> +++ b/xen/drivers/pci/physdev.c >> @@ -67,6 +68,39 @@ 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); vpci_reset_device_state only reset the vpci state of pdev without deleting pdev from domain, and here has held pcidevs_lock, it has no need to lock 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..3c64cb10ccbb 100644 >> --- a/xen/drivers/vpci/vpci.c >> +++ b/xen/drivers/vpci/vpci.c >> @@ -107,6 +107,15 @@ 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,
On 1/10/24 01:24, Chen, Jiqian wrote: > On 2024/1/9 23:24, Stewart Hildebrand wrote: >> On 1/5/24 02:09, Jiqian Chen wrote: >>> diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c >>> index 42db3e6d133c..552ccbf747cb 100644 >>> --- a/xen/drivers/pci/physdev.c >>> +++ b/xen/drivers/pci/physdev.c >>> @@ -67,6 +68,39 @@ 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); > vpci_reset_device_state only reset the vpci state of pdev without deleting pdev from domain, and here has held pcidevs_lock, it has no need to lock pci_lock? Strictly speaking, it is not enforced yet. However, an upcoming change [1] will expand the scope of d->pci_lock to include protecting the pdev->vpci structure to an extent, so it will be required once that change is committed. In my opinion there is no harm in adding the additional lock now. If you prefer to wait I would not object, but in this case I would at least ask for a TODO comment to help remind us to address it later. [1] https://lists.xenproject.org/archives/html/xen-devel/2024-01/msg00446.html > >> >>> + 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..3c64cb10ccbb 100644 >>> --- a/xen/drivers/vpci/vpci.c >>> +++ b/xen/drivers/vpci/vpci.c >>> @@ -107,6 +107,15 @@ 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, >
On 2024/1/10 22:09, Stewart Hildebrand wrote: > On 1/10/24 01:24, Chen, Jiqian wrote: >> On 2024/1/9 23:24, Stewart Hildebrand wrote: >>> On 1/5/24 02:09, Jiqian Chen wrote: >>>> diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c >>>> index 42db3e6d133c..552ccbf747cb 100644 >>>> --- a/xen/drivers/pci/physdev.c >>>> +++ b/xen/drivers/pci/physdev.c >>>> @@ -67,6 +68,39 @@ 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); >> vpci_reset_device_state only reset the vpci state of pdev without deleting pdev from domain, and here has held pcidevs_lock, it has no need to lock pci_lock? > > Strictly speaking, it is not enforced yet. However, an upcoming change [1] will expand the scope of d->pci_lock to include protecting the pdev->vpci structure to an extent, so it will be required once that change is committed. In my opinion there is no harm in adding the additional lock now. If you prefer to wait I would not object, but in this case I would at least ask for a TODO comment to help remind us to address it later. > > [1] https://lists.xenproject.org/archives/html/xen-devel/2024-01/msg00446.html > Ok, I see. I will add pci_lock in next version, thank you for reminding me. >> >>> >>>> + 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..3c64cb10ccbb 100644 >>>> --- a/xen/drivers/vpci/vpci.c >>>> +++ b/xen/drivers/vpci/vpci.c >>>> @@ -107,6 +107,15 @@ 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/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..552ccbf747cb 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,39 @@ 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; + } + + ret = vpci_reset_device_state(pdev); + 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..3c64cb10ccbb 100644 --- a/xen/drivers/vpci/vpci.c +++ b/xen/drivers/vpci/vpci.c @@ -107,6 +107,15 @@ int vpci_add_handlers(struct pci_dev *pdev) return rc; } + +int vpci_reset_device_state(struct pci_dev *pdev) +{ + ASSERT(pcidevs_locked()); + + 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 | 34 ++++++++++++++++++++++++++++++++++ xen/drivers/vpci/vpci.c | 9 +++++++++ xen/include/public/physdev.h | 7 +++++++ xen/include/xen/vpci.h | 6 ++++++ 5 files changed, 57 insertions(+)