diff mbox series

[v3,29/37] vfio/iommufd: Bypass EEH if iommufd backend

Message ID 20231026103104.1686921-30-zhenzhong.duan@intel.com
State New
Headers show
Series vfio: Adopt iommufd | expand

Commit Message

Duan, Zhenzhong Oct. 26, 2023, 10:30 a.m. UTC
IBM EEH is only supported by legacy backend currently, bypass it
for IOMMUFD backend.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
---
 hw/ppc/spapr_pci_vfio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Cédric Le Goater Oct. 30, 2023, 1:56 p.m. UTC | #1
On 10/26/23 12:30, Zhenzhong Duan wrote:
> IBM EEH is only supported by legacy backend currently, bypass it
> for IOMMUFD backend.
> 
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
> ---
>   hw/ppc/spapr_pci_vfio.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
> index d1d07bec46..a2518838a1 100644
> --- a/hw/ppc/spapr_pci_vfio.c
> +++ b/hw/ppc/spapr_pci_vfio.c
> @@ -93,10 +93,10 @@ static VFIOContainer *vfio_eeh_as_container(AddressSpace *as)
>   
>       bcontainer = QLIST_FIRST(&space->containers);
>   
> -    if (QLIST_NEXT(bcontainer, next)) {
> +    if (QLIST_NEXT(bcontainer, next) || bcontainer->ops != &vfio_legacy_ops) {

It's curious that a test on the VFIOIOMMUOps is needed so deep in
the software stack, and spapr should have its own VFIOIOMMUOps, which
de facto doesn't support iommufd.

Thanks,

C.


>           /*
>            * We don't yet have logic to synchronize EEH state across
> -         * multiple containers
> +         * multiple containers, iommufd isn't supported too.
>            */
>           bcontainer = NULL;
>           goto out;
Duan, Zhenzhong Oct. 31, 2023, 2:26 a.m. UTC | #2
>-----Original Message-----
>From: Cédric Le Goater <clg@redhat.com>
>Sent: Monday, October 30, 2023 9:57 PM
>Subject: Re: [PATCH v3 29/37] vfio/iommufd: Bypass EEH if iommufd backend
>
>On 10/26/23 12:30, Zhenzhong Duan wrote:
>> IBM EEH is only supported by legacy backend currently, bypass it
>> for IOMMUFD backend.
>>
>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>> ---
>>   hw/ppc/spapr_pci_vfio.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
>> index d1d07bec46..a2518838a1 100644
>> --- a/hw/ppc/spapr_pci_vfio.c
>> +++ b/hw/ppc/spapr_pci_vfio.c
>> @@ -93,10 +93,10 @@ static VFIOContainer
>*vfio_eeh_as_container(AddressSpace *as)
>>
>>       bcontainer = QLIST_FIRST(&space->containers);
>>
>> -    if (QLIST_NEXT(bcontainer, next)) {
>> +    if (QLIST_NEXT(bcontainer, next) || bcontainer->ops != &vfio_legacy_ops) {
>
>It's curious that a test on the VFIOIOMMUOps is needed so deep in
>the software stack, and spapr should have its own VFIOIOMMUOps, which
>de facto doesn't support iommufd.

Yes, in this series, spapr shares same ops vfio_legacy_ops, in next series I should
check with vfio_iommu_spapr_ops.

The general vfio-pci device supports iommu property, if we pass a vfio device
with iommufd backend, I guess we will crash Qemu if there is no check here.

Thanks
Zhenzhong
Cédric Le Goater Oct. 31, 2023, 9:01 a.m. UTC | #3
On 10/31/23 03:26, Duan, Zhenzhong wrote:
> 
> 
>> -----Original Message-----
>> From: Cédric Le Goater <clg@redhat.com>
>> Sent: Monday, October 30, 2023 9:57 PM
>> Subject: Re: [PATCH v3 29/37] vfio/iommufd: Bypass EEH if iommufd backend
>>
>> On 10/26/23 12:30, Zhenzhong Duan wrote:
>>> IBM EEH is only supported by legacy backend currently, bypass it
>>> for IOMMUFD backend.
>>>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>> ---
>>>    hw/ppc/spapr_pci_vfio.c | 4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
>>> index d1d07bec46..a2518838a1 100644
>>> --- a/hw/ppc/spapr_pci_vfio.c
>>> +++ b/hw/ppc/spapr_pci_vfio.c
>>> @@ -93,10 +93,10 @@ static VFIOContainer
>> *vfio_eeh_as_container(AddressSpace *as)
>>>
>>>        bcontainer = QLIST_FIRST(&space->containers);
>>>
>>> -    if (QLIST_NEXT(bcontainer, next)) {
>>> +    if (QLIST_NEXT(bcontainer, next) || bcontainer->ops != &vfio_legacy_ops) {
>>
>> It's curious that a test on the VFIOIOMMUOps is needed so deep in
>> the software stack, and spapr should have its own VFIOIOMMUOps, which
>> de facto doesn't support iommufd.
> 
> Yes, in this series, spapr shares same ops vfio_legacy_ops, in next series I should
> check with vfio_iommu_spapr_ops.

Well, since PPC doesn't support IOMMUFD it should be tested before or compile
out as suggested on patch 23 "Add iommufd configure option"

Thanks,

C.


> The general vfio-pci device supports iommu property, if we pass a vfio device
> with iommufd backend, I guess we will crash Qemu if there is no check here.
> 
> Thanks
> Zhenzhong
>
Duan, Zhenzhong Oct. 31, 2023, 9:06 a.m. UTC | #4
>-----Original Message-----
>From: Cédric Le Goater <clg@redhat.com>
>Sent: Tuesday, October 31, 2023 5:01 PM
>Subject: Re: [PATCH v3 29/37] vfio/iommufd: Bypass EEH if iommufd backend
>
>On 10/31/23 03:26, Duan, Zhenzhong wrote:
>>
>>
>>> -----Original Message-----
>>> From: Cédric Le Goater <clg@redhat.com>
>>> Sent: Monday, October 30, 2023 9:57 PM
>>> Subject: Re: [PATCH v3 29/37] vfio/iommufd: Bypass EEH if iommufd backend
>>>
>>> On 10/26/23 12:30, Zhenzhong Duan wrote:
>>>> IBM EEH is only supported by legacy backend currently, bypass it
>>>> for IOMMUFD backend.
>>>>
>>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>>> ---
>>>>    hw/ppc/spapr_pci_vfio.c | 4 ++--
>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
>>>> index d1d07bec46..a2518838a1 100644
>>>> --- a/hw/ppc/spapr_pci_vfio.c
>>>> +++ b/hw/ppc/spapr_pci_vfio.c
>>>> @@ -93,10 +93,10 @@ static VFIOContainer
>>> *vfio_eeh_as_container(AddressSpace *as)
>>>>
>>>>        bcontainer = QLIST_FIRST(&space->containers);
>>>>
>>>> -    if (QLIST_NEXT(bcontainer, next)) {
>>>> +    if (QLIST_NEXT(bcontainer, next) || bcontainer->ops != &vfio_legacy_ops)
>{
>>>
>>> It's curious that a test on the VFIOIOMMUOps is needed so deep in
>>> the software stack, and spapr should have its own VFIOIOMMUOps, which
>>> de facto doesn't support iommufd.
>>
>> Yes, in this series, spapr shares same ops vfio_legacy_ops, in next series I
>should
>> check with vfio_iommu_spapr_ops.
>
>Well, since PPC doesn't support IOMMUFD it should be tested before or compile
>out as suggested on patch 23 "Add iommufd configure option"

Got it, I'll disabled it for PPC as you suggested.

Thanks
Zhenzhong

>
>Thanks,
>
>C.
>
>
>> The general vfio-pci device supports iommu property, if we pass a vfio device
>> with iommufd backend, I guess we will crash Qemu if there is no check here.
>>
>> Thanks
>> Zhenzhong
>>
diff mbox series

Patch

diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
index d1d07bec46..a2518838a1 100644
--- a/hw/ppc/spapr_pci_vfio.c
+++ b/hw/ppc/spapr_pci_vfio.c
@@ -93,10 +93,10 @@  static VFIOContainer *vfio_eeh_as_container(AddressSpace *as)
 
     bcontainer = QLIST_FIRST(&space->containers);
 
-    if (QLIST_NEXT(bcontainer, next)) {
+    if (QLIST_NEXT(bcontainer, next) || bcontainer->ops != &vfio_legacy_ops) {
         /*
          * We don't yet have logic to synchronize EEH state across
-         * multiple containers
+         * multiple containers, iommufd isn't supported too.
          */
         bcontainer = NULL;
         goto out;