[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH-for-4.2 v3 3/5] hw/vfio/common: Assert in case o
From: |
Auger Eric |
Subject: |
Re: [Qemu-devel] [PATCH-for-4.2 v3 3/5] hw/vfio/common: Assert in case of nested mode |
Date: |
Thu, 22 Aug 2019 17:14:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
Hi Peter,
On 8/5/19 4:41 PM, Peter Maydell wrote:
> On Thu, 11 Jul 2019 at 07:19, Eric Auger <address@hidden> wrote:
>>
>> As of today, VFIO only works along with vIOMMU supporting
>> caching mode. The SMMUv3 does not support this mode and
>> requires HW nested paging to work properly with VFIO.
>>
>> So any attempt to run a VFIO device protected by such IOMMU
>> would prevent the assigned device from working and at the
>> moment the guest does not even boot as the default
>> memory_region_iommu_replay() implementation attempts to
>> translate the whole address space and completely stalls
>> the execution.
>>
>> So let's assert if we recognize nested mode case.
>>
>> Signed-off-by: Eric Auger <address@hidden>
>> ---
>> hw/vfio/common.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> index a859298fda..d622191fe6 100644
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -604,9 +604,17 @@ static void vfio_listener_region_add(MemoryListener
>> *listener,
>> if (memory_region_is_iommu(section->mr)) {
>> VFIOGuestIOMMU *giommu;
>> IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(section->mr);
>> + bool nested;
>> int iommu_idx;
>>
>> trace_vfio_listener_region_add_iommu(iova, end);
>> +
>> + if (!memory_region_iommu_get_attr(iommu_mr, IOMMU_ATTR_VFIO_NESTED,
>> + (void *)&nested) && nested) {
>> + error_report("VFIO/vIOMMU integration based on HW nested paging
>> "
>> + "is not yet supported");
>> + abort();
>> + }
>> /*
>> * FIXME: For VFIO iommu types which have KVM acceleration to
>> * avoid bouncing all map/unmaps through qemu this way, this
>
> Other failure paths in this function mostly seem to do an
> error_report() and return (apart from the one call to hw_error()
> at the bottom of the function). Is an abort() OK here?
Yes I should rather jump to the fail label instead.
Thanks!
Eric
>
> thanks
> -- PMM
>