[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 1/1] xen/pci: Install vpci handlers on x86 and fix exit path
Hi Roger, > On 20 Oct 2021, at 09:08, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote: > > On Wed, Oct 20, 2021 at 07:57:15AM +0000, Bertrand Marquis wrote: >> Hi Roger, >> >>> On 20 Oct 2021, at 08:49, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote: >>> >>> On Tue, Oct 19, 2021 at 05:08:28PM +0100, Bertrand Marquis wrote: >>>> Xen might not be able to discover at boot time all devices or some devices >>>> might appear after specific actions from dom0. >>>> In this case dom0 can use the PHYSDEVOP_pci_device_add to signal some >>>> PCI devices to Xen. >>>> As those devices where not known from Xen before, the vpci handlers must >>>> be properly installed during pci_device_add for x86 PVH Dom0, in the >>>> same way as what is done currently on arm (where Xen does not detect PCI >>>> devices but relies on Dom0 to declare them all the time). >>>> >>>> So this patch is removing the ifdef protecting the call to >>>> vpci_add_handlers and the comment which was arm specific. >>>> >>>> vpci_add_handlers is called on during pci_device_add which can be called >>>> at runtime through hypercall physdev_op. >>>> Remove __hwdom_init as the call is not limited anymore to hardware >>>> domain init and fix linker script to only keep vpci_array in rodata >>>> section. >>>> >>>> Add missing vpci handlers cleanup during pci_device_remove and in case >>>> of error with iommu during pci_device_add. >>>> >>>> Add empty static inline for vpci_remove_device when CONFIG_VPCI is not >>>> defined. >>>> >>>> Fixes: d59168dc05 ("xen/arm: Enable the existing x86 virtual PCI support >>>> for ARM") >>>> Suggested-by: Jan Beulich <jbeulich@xxxxxxxx> >>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx> >>>> --- >>>> Changes in v2 >>>> - add comment suggested by Jan on top of vpci_add_handlers call >>>> - merge the 3 patches of the serie in one patch and renamed it >>>> - fix x86 and arm linker script to only keep vpci_array in rodata and >>>> only when CONFIG_VPCI is set. >>>> --- >>>> xen/arch/arm/xen.lds.S | 9 +-------- >>>> xen/arch/x86/xen.lds.S | 9 +-------- >>>> xen/drivers/passthrough/pci.c | 8 ++++---- >>>> xen/drivers/vpci/vpci.c | 2 +- >>>> xen/include/xen/vpci.h | 2 ++ >>>> 5 files changed, 9 insertions(+), 21 deletions(-) >>>> >>>> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S >>>> index b773f91f1c..08016948ab 100644 >>>> --- a/xen/arch/arm/xen.lds.S >>>> +++ b/xen/arch/arm/xen.lds.S >>>> @@ -60,7 +60,7 @@ SECTIONS >>>> *(.proc.info) >>>> __proc_info_end = .; >>>> >>>> -#if defined(CONFIG_HAS_VPCI) && defined(CONFIG_LATE_HWDOM) >>>> +#ifdef CONFIG_HAS_VPCI >>>> . = ALIGN(POINTER_ALIGN); >>>> __start_vpci_array = .; >>>> *(SORT(.data.vpci.*)) >>>> @@ -189,13 +189,6 @@ SECTIONS >>>> *(.init_array) >>>> *(SORT(.init_array.*)) >>>> __ctors_end = .; >>>> - >>>> -#if defined(CONFIG_HAS_VPCI) && !defined(CONFIG_LATE_HWDOM) >>>> - . = ALIGN(POINTER_ALIGN); >>>> - __start_vpci_array = .; >>>> - *(SORT(.data.vpci.*)) >>>> - __end_vpci_array = .; >>>> -#endif >>>> } :text >>>> __init_end_efi = .; >>>> . = ALIGN(STACK_SIZE); >>>> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S >>>> index 11b1da2154..87e344d4dd 100644 >>>> --- a/xen/arch/x86/xen.lds.S >>>> +++ b/xen/arch/x86/xen.lds.S >>>> @@ -134,7 +134,7 @@ SECTIONS >>>> *(.ex_table.pre) >>>> __stop___pre_ex_table = .; >>>> >>>> -#if defined(CONFIG_HAS_VPCI) && defined(CONFIG_LATE_HWDOM) >>>> +#ifdef CONFIG_HAS_VPCI >>>> . = ALIGN(POINTER_ALIGN); >>>> __start_vpci_array = .; >>>> *(SORT(.data.vpci.*)) >>>> @@ -247,13 +247,6 @@ SECTIONS >>>> *(.init_array) >>>> *(SORT(.init_array.*)) >>>> __ctors_end = .; >>>> - >>>> -#if defined(CONFIG_HAS_VPCI) && !defined(CONFIG_LATE_HWDOM) >>>> - . = ALIGN(POINTER_ALIGN); >>>> - __start_vpci_array = .; >>>> - *(SORT(.data.vpci.*)) >>>> - __end_vpci_array = .; >>>> -#endif >>>> } PHDR(text) >>>> >>>> . = ALIGN(SECTION_ALIGN); >>>> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c >>>> index 35e0190796..8928a1c07d 100644 >>>> --- a/xen/drivers/passthrough/pci.c >>>> +++ b/xen/drivers/passthrough/pci.c >>>> @@ -756,10 +756,9 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, >>>> if ( !pdev->domain ) >>>> { >>>> pdev->domain = hardware_domain; >>>> -#ifdef CONFIG_ARM >>>> /* >>>> - * On ARM PCI devices discovery will be done by Dom0. Add vpci >>>> handler >>>> - * when Dom0 inform XEN to add the PCI devices in XEN. >>>> + * For devices not discovered by Xen during boot, add vPCI >>>> handlers >>>> + * when Dom0 first informs Xen about such devices. >>>> */ >>>> ret = vpci_add_handlers(pdev); >>>> if ( ret ) >>>> @@ -768,10 +767,10 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, >>>> pdev->domain = NULL; >>>> goto out; >>>> } >>>> -#endif >>>> ret = iommu_add_device(pdev); >>>> if ( ret ) >>>> { >>>> + vpci_remove_device(pdev); >>>> pdev->domain = NULL; >>>> goto out; >>>> } >>>> @@ -819,6 +818,7 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn) >>>> list_for_each_entry ( pdev, &pseg->alldevs_list, alldevs_list ) >>>> if ( pdev->bus == bus && pdev->devfn == devfn ) >>>> { >>>> + vpci_remove_device(pdev); >>> >>> vpci_remove_device is missing a check for has_vpci(pdev->domain), as >>> it will unconditionally access pdev->vpci otherwise, and that would be >>> wrong for domains not using vpci. >>> >>> It might also be good to add an ASSERT(!pdev->vpci) to >>> vpci_add_handlers in order to make sure there are no duplicated calls >>> to vpci_add_handlers, but that can be done in a separate patch. >> >> I can do both in v3 (together with the change of in the patch name). >> >> Unless you want the ASSERT in a different patch, in this case I do not think >> I can make a new patch for that. >> >> Can you confirm if I should or not add the ASSERT directly in the patch ? > > I'm fine with having the assert added here: in wasn't necessary > previously as there was a single caller of vpci_add_handlers. Now that > there are multiple ones we should make sure no duplicated calls can > happen. Ok I will add it then and send v3 this morning. > > On a different note (and not something that should be solved here, > just wanted to raise attention to it) there's an existing TODO about > vpci_remove_device because it doesn't clean the 2nd stage mappings for > BARs. At some point we need to solve this, or else the removal of the > device is not complete. I will try to keep that in mind. Maybe adding a TODO in the code would be a good idea. Thanks Bertrand > > Thanks, Roger.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |