From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
Subject: Re: [PATCH v8 04/13] vpci: add hooks for PCI device assign/de-assign
Date: Wed, 26 Jul 2023 01:38:30 +0000 [thread overview]
Message-ID: <875y67cuzu.fsf@epam.com> (raw)
In-Reply-To: <ZLkqWXJtYlsJ4M61@MacBook-Air-de-Roger.local>
Hi Roger,
Roger Pau Monné <roger.pau@citrix.com> writes:
> On Thu, Jul 20, 2023 at 12:32:31AM +0000, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> When a PCI device gets assigned/de-assigned some work on vPCI side needs
>> to be done for that device. Introduce a pair of hooks so vPCI can handle
>> that.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>> Since v8:
>> - removed vpci_deassign_device
>> Since v6:
>> - do not pass struct domain to vpci_{assign|deassign}_device as
>> pdev->domain can be used
>> - do not leave the device assigned (pdev->domain == new domain) in case
>> vpci_assign_device fails: try to de-assign and if this also fails, then
>> crash the domain
>> Since v5:
>> - do not split code into run_vpci_init
>> - do not check for is_system_domain in vpci_{de}assign_device
>> - do not use vpci_remove_device_handlers_locked and re-allocate
>> pdev->vpci completely
>> - make vpci_deassign_device void
>> Since v4:
>> - de-assign vPCI from the previous domain on device assignment
>> - do not remove handlers in vpci_assign_device as those must not
>> exist at that point
>> Since v3:
>> - remove toolstack roll-back description from the commit message
>> as error are to be handled with proper cleanup in Xen itself
>> - remove __must_check
>> - remove redundant rc check while assigning devices
>> - fix redundant CONFIG_HAS_VPCI check for CONFIG_HAS_VPCI_GUEST_SUPPORT
>> - use REGISTER_VPCI_INIT machinery to run required steps on device
>> init/assign: add run_vpci_init helper
>> Since v2:
>> - define CONFIG_HAS_VPCI_GUEST_SUPPORT so dead code is not compiled
>> for x86
>> Since v1:
>> - constify struct pci_dev where possible
>> - do not open code is_system_domain()
>> - extended the commit message
>> ---
>> xen/drivers/Kconfig | 4 ++++
>> xen/drivers/passthrough/pci.c | 21 +++++++++++++++++++++
>> xen/drivers/vpci/vpci.c | 18 ++++++++++++++++++
>> xen/include/xen/vpci.h | 15 +++++++++++++++
>> 4 files changed, 58 insertions(+)
>>
>> diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
>> index db94393f47..780490cf8e 100644
>> --- a/xen/drivers/Kconfig
>> +++ b/xen/drivers/Kconfig
>> @@ -15,4 +15,8 @@ source "drivers/video/Kconfig"
>> config HAS_VPCI
>> bool
>>
>> +config HAS_VPCI_GUEST_SUPPORT
>> + bool
>> + depends on HAS_VPCI
>> +
>> endmenu
>> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
>> index 6f8692cd9c..265d359704 100644
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -885,6 +885,10 @@ static int deassign_device(struct domain *d, uint16_t seg, uint8_t bus,
>> if ( ret )
>> goto out;
>>
>> + write_lock(&pdev->domain->pci_lock);
>> + vpci_deassign_device(pdev);
>> + write_unlock(&pdev->domain->pci_lock);
>> +
>> if ( pdev->domain == hardware_domain )
>> pdev->quarantine = false;
>>
>> @@ -1484,6 +1488,10 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag)
>> if ( pdev->broken && d != hardware_domain && d != dom_io )
>> goto done;
>>
>> + write_lock(&pdev->domain->pci_lock);
>> + vpci_deassign_device(pdev);
>> + write_unlock(&pdev->domain->pci_lock);
>> +
>> rc = pdev_msix_assign(d, pdev);
>> if ( rc )
>> goto done;
>> @@ -1509,6 +1517,19 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag)
>> rc = iommu_call(hd->platform_ops, assign_device, d, devfn,
>> pci_to_dev(pdev), flag);
>> }
>> + if ( rc )
>> + goto done;
>> +
>> + devfn = pdev->devfn;
>> + write_lock(&pdev->domain->pci_lock);
>> + rc = vpci_assign_device(pdev);
>> + write_unlock(&pdev->domain->pci_lock);
>> + if ( rc && deassign_device(d, seg, bus, devfn) )
>> + {
>> + printk(XENLOG_ERR "%pd: %pp was left partially assigned\n",
>> + d, &PCI_SBDF(seg, bus, devfn));
>
> &pdev->sbdf? Then you can get of the devfn usage above.
Yes, thanks.
>> + domain_crash(d);
>
> This seems like a bit different from the other error paths in the
> function, isn't it fine to return an error and let the caller handle
> the deassign?
I believe, intention was to not leave device in an unknown state: we
failed both assign_device() and deassign_device() call, so what to do
now? But yes, I think you are right and it is better to let caller to
decide what to do next.
>
> Also, if we really need to call deassign_device() we must do so for
> all possible phantom devices, see the above loop around
> iommu_call(..., assing_device, ...);
But deassign_device() has the loop for all phantom devices that already
does all the work. Unless I miss something, of course.
>> + }
>>
>> done:
>> if ( rc )
>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>> index a6d2cf8660..a97710a806 100644
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -107,6 +107,24 @@ int vpci_add_handlers(struct pci_dev *pdev)
>>
>> return rc;
>> }
>> +
>> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>> +/* Notify vPCI that device is assigned to guest. */
>> +int vpci_assign_device(struct pci_dev *pdev)
>> +{
>> + int rc;
>> +
>> + if ( !has_vpci(pdev->domain) )
>> + return 0;
>> +
>> + rc = vpci_add_handlers(pdev);
>> + if ( rc )
>> + vpci_deassign_device(pdev);
>
> Why do you need this handler, vpci_add_handlers() when failing will
> already call vpci_remove_device(), which is what
> vpci_deassign_device() does.
>
>> +
>> + return rc;
>> +}
>> +#endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>> +
>> #endif /* __XEN__ */
>>
>> static int vpci_register_cmp(const struct vpci_register *r1,
>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>> index 0b8a2a3c74..44296623e1 100644
>> --- a/xen/include/xen/vpci.h
>> +++ b/xen/include/xen/vpci.h
>> @@ -264,6 +264,21 @@ static inline bool __must_check vpci_process_pending(struct vcpu *v)
>> }
>> #endif
>>
>> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>> +/* Notify vPCI that device is assigned/de-assigned to/from guest. */
>> +int vpci_assign_device(struct pci_dev *pdev);
>> +#define vpci_deassign_device vpci_remove_device
>> +#else
>> +static inline int vpci_assign_device(struct pci_dev *pdev)
>> +{
>> + return 0;
>> +};
>> +
>> +static inline void vpci_deassign_device(struct pci_dev *pdev)
>> +{
>> +};
>> +#endif
>
> I don't think there's much point in introducing new functions, see
> above. I'm fine if the current ones want to be renamed to
> vpci_{,de}assign_device(), but adding defines like the above just
> makes the code harder to follow.
Good idea, thanks, I'll just rename the original functions.
--
WBR, Volodymyr
next prev parent reply other threads:[~2023-07-26 1:38 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 0:32 [PATCH v8 00/13] PCI devices passthrough on Arm, part 3 Volodymyr Babchuk
2023-07-20 0:32 ` [PATCH v8 02/13] vpci: use per-domain PCI lock to protect vpci structure Volodymyr Babchuk
2023-07-20 11:20 ` Roger Pau Monné
2023-07-20 13:27 ` Jan Beulich
2023-07-20 13:50 ` Roger Pau Monné
2023-07-24 0:07 ` Volodymyr Babchuk
2023-07-24 7:59 ` Roger Pau Monné
2023-07-20 15:53 ` Jan Beulich
2023-07-26 1:17 ` Volodymyr Babchuk
2023-07-26 6:39 ` Jan Beulich
2023-07-26 9:35 ` Roger Pau Monné
2023-07-27 0:56 ` Volodymyr Babchuk
2023-07-27 7:41 ` Jan Beulich
2023-07-27 10:31 ` Volodymyr Babchuk
2023-07-27 11:37 ` Jan Beulich
2023-07-27 15:13 ` Volodymyr Babchuk
2023-07-27 12:42 ` Roger Pau Monné
2023-07-27 12:56 ` Jan Beulich
2023-07-27 14:43 ` Roger Pau Monné
2023-07-28 0:21 ` Volodymyr Babchuk
2023-07-28 13:55 ` Roger Pau Monné
2023-07-20 16:03 ` Jan Beulich
2023-07-20 16:14 ` Roger Pau Monné
2023-07-21 6:02 ` Jan Beulich
2023-07-21 7:43 ` Roger Pau Monné
2023-07-21 8:48 ` Jan Beulich
2023-07-20 16:09 ` Jan Beulich
2023-07-20 0:32 ` [PATCH v8 01/13] pci: introduce per-domain PCI rwlock Volodymyr Babchuk
2023-07-20 9:45 ` Roger Pau Monné
2023-07-20 22:57 ` Volodymyr Babchuk
2023-07-20 15:40 ` Jan Beulich
2023-07-20 23:37 ` Volodymyr Babchuk
2023-07-20 0:32 ` [PATCH v8 03/13] vpci: restrict unhandled read/write operations for guests Volodymyr Babchuk
2023-07-20 11:32 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 04/13] vpci: add hooks for PCI device assign/de-assign Volodymyr Babchuk
2023-07-20 12:36 ` Roger Pau Monné
2023-07-26 1:38 ` Volodymyr Babchuk [this message]
2023-07-26 8:42 ` Roger Pau Monné
2023-07-24 9:41 ` Jan Beulich
2023-07-20 0:32 ` [PATCH v8 05/13] vpci/header: implement guest BAR register handlers Volodymyr Babchuk
2023-07-20 16:01 ` Roger Pau Monné
2023-07-21 10:36 ` Rahul Singh
2023-07-21 10:50 ` Jan Beulich
2023-07-21 11:52 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 06/13] rangeset: add RANGESETF_no_print flag Volodymyr Babchuk
2023-07-20 0:32 ` [PATCH v8 07/13] vpci/header: handle p2m range sets per BAR Volodymyr Babchuk
2023-07-21 11:49 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 09/13] vpci/header: emulate PCI_COMMAND register for guests Volodymyr Babchuk
2023-07-21 13:32 ` Roger Pau Monné
2023-07-21 13:40 ` Roger Pau Monné
2023-07-24 11:06 ` Jan Beulich
2023-07-24 11:03 ` Jan Beulich
2023-07-20 0:32 ` [PATCH v8 10/13] vpci/header: reset the command register when adding devices Volodymyr Babchuk
2023-07-21 13:37 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 08/13] vpci/header: program p2m with guest BAR view Volodymyr Babchuk
2023-07-21 13:05 ` Roger Pau Monné
2023-07-24 10:30 ` Jan Beulich
2023-07-24 10:43 ` Jan Beulich
2023-07-24 13:16 ` Roger Pau Monné
2023-07-24 13:31 ` Jan Beulich
2023-07-24 13:42 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 11/13] vpci: add initial support for virtual PCI bus topology Volodymyr Babchuk
2023-07-20 6:50 ` Jan Beulich
2023-07-21 0:43 ` Volodymyr Babchuk
2023-07-21 13:53 ` Roger Pau Monné
2023-07-21 14:00 ` Roger Pau Monné
2023-07-26 21:35 ` Stewart Hildebrand
2023-07-20 0:32 ` [PATCH v8 12/13] xen/arm: translate virtual PCI bus topology for guests Volodymyr Babchuk
2023-07-20 6:54 ` Jan Beulich
2023-07-21 14:09 ` Roger Pau Monné
2023-07-24 8:02 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 13/13] xen/arm: account IO handlers for emulated PCI MSI-X Volodymyr Babchuk
2023-07-20 0:41 ` [PATCH v8 00/13] PCI devices passthrough on Arm, part 3 Volodymyr Babchuk
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=875y67cuzu.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=Oleksandr_Andrushchenko@epam.com \
--cc=roger.pau@citrix.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.