qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org,
	alex.williamson@redhat.com, qemu-arm@nongnu.org,
	pbonzini@redhat.com, eric.auger.pro@gmail.com
Subject: Re: [Qemu-devel] [PATCH v2 3/6] hw/vfio/common: Do not replay IOMMU mappings in nested case
Date: Wed, 3 Jul 2019 11:04:38 +0200	[thread overview]
Message-ID: <ac7cb635-b420-e04d-1a80-6fcfe81d12a8@redhat.com> (raw)
In-Reply-To: <20190703054116.GD10408@xz-x1>

Hi Peter,

On 7/3/19 7:41 AM, Peter Xu wrote:
> On Mon, Jul 01, 2019 at 11:30:31AM +0200, Eric Auger wrote:
>> In nested mode, the stage 1 translation tables are owned by
>> the guest and there is no caching on host side. So there is
>> no need to replay the mappings.
>>
>> As of today, the SMMUv3 nested mode is not yet implemented
>> and there is no functional VFIO integration without. But
>> keeping the replay call would execute the default implementation
>> of memory_region_iommu_replay and attempt to translate the whole
>> address range, completely stalling qemu. Keeping the MAP/UNMAP
>> notifier registration allows to hit a warning message in the
>> SMMUv3 device that tells the user which VFIO device will not
>> function properly:
>>
>> "qemu-system-aarch64: -device vfio-pci,host=0000:89:00.0: warning:
>> SMMUv3 does not support notification on MAP: device vfio-pci will not
>> function properly"
>>
>> Besides, removing the replay call now allows the guest to boot.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>  hw/vfio/common.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> index a859298fda..9ea58df67a 100644
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -604,6 +604,7 @@ 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 = false;
>>          int iommu_idx;
>>  
>>          trace_vfio_listener_region_add_iommu(iova, end);
>> @@ -631,8 +632,12 @@ static void vfio_listener_region_add(MemoryListener *listener,
>>          QLIST_INSERT_HEAD(&container->giommu_list, giommu, giommu_next);
>>  
>>          memory_region_register_iommu_notifier(section->mr, &giommu->n);
>> -        memory_region_iommu_replay(giommu->iommu, &giommu->n);
>>  
>> +        memory_region_iommu_get_attr(iommu_mr, IOMMU_ATTR_VFIO_NESTED,
>> +                                     (void *)&nested);
>> +        if (!nested) {
>> +            memory_region_iommu_replay(iommu_mr, &giommu->n);
>> +        }
> 
> For nested, do we need these IOMMU notifiers after all?
> 
> I'm asking because the no-IOMMU case of vfio_listener_region_add()
> seems to suite very well for nested page tables to me.  For example,
> vfio does not need to listen to MAP events any more because we'll
> simply share the guest IOMMU page table to be the 1st level page table
> of the host SMMU IIUC.
We don't need the MAP notifier but we need the UNMAP notifier: when the
guest invalidates an ASID/IOVA we need to propagate this to the physical
IOMMU.

As mentioned in the cover letter, at the moment, I still register both
MAP/UNMAP notifiers as the MAP notifier registration produces an
explicit warning message in the SMMUv3 device. If I remove the
registration we will loose this message. I hope this code is just an
intermediate state towards the actual nested stage support.

  And if we have 2nd page table changes (like
> memory hotplug) then IMHO vfio_listener_region_add() will do this for
> us as well just like when there's no SMMU.

In the current integration, see [RFC v4 20/27] hw/vfio/common: Setup
nested stage mappings (https://patchwork.kernel.org/patch/10962721/) I
use a prereg_listener for stage 2 mappings.
> 
> Another thing is that IOMMU_ATTR_VFIO_NESTED will be the same for all
> the memory regions, so it also seems a bit awkward to make it per
> memory region.  If you see the other real user of this flag (which is
> IOMMU_ATTR_SPAPR_TCE_FD) it's per memory region.

That's correct all SMMUv3 regions will return this value. But what other
API can be used to query IOMMU level attributes?

On the other hand,

Alexey's commit f1334de60b2 ("memory/iommu: Add get_attr()") says:
    This adds get_attr() to IOMMUMemoryRegionClass, like
    iommu_ops::domain_get_attr in the Linux kernel.

and DOMAIN_ATTR_NESTING is part of enum iommu_attr at kernel level.

Thanks

Eric



> 
> Regards,
> 


  reply	other threads:[~2019-07-03  9:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-01  9:30 [Qemu-devel] [PATCH v2 0/6] ARM SMMUv3: Fix spurious notification errors and stall with vfio-pci Eric Auger
2019-07-01  9:30 ` [Qemu-devel] [PATCH v2 1/6] memory: Remove unused memory_region_iommu_replay_all() Eric Auger
2019-07-01  9:58   ` Philippe Mathieu-Daudé
2019-07-03  5:41   ` Peter Xu
2019-07-01  9:30 ` [Qemu-devel] [PATCH v2 2/6] memory: Add IOMMU_ATTR_VFIO_NESTED IOMMU memory region attribute Eric Auger
2019-07-03  5:42   ` Peter Xu
2019-07-03  9:10     ` Auger Eric
2019-07-01  9:30 ` [Qemu-devel] [PATCH v2 3/6] hw/vfio/common: Do not replay IOMMU mappings in nested case Eric Auger
2019-07-03  5:41   ` Peter Xu
2019-07-03  9:04     ` Auger Eric [this message]
2019-07-03 10:21       ` Peter Xu
2019-07-03 10:45         ` Auger Eric
2019-07-04  2:36           ` Peter Xu
2019-07-01  9:30 ` [Qemu-devel] [PATCH v2 4/6] hw/arm/smmuv3: Advertise VFIO_NESTED Eric Auger
2019-07-01  9:30 ` [Qemu-devel] [PATCH v2 5/6] hw/arm/smmuv3: Log a guest error when decoding an invalid STE Eric Auger
2019-07-01  9:58   ` Philippe Mathieu-Daudé
2019-07-01  9:30 ` [Qemu-devel] [PATCH v2 6/6] hw/arm/smmuv3: Remove spurious error messages on IOVA invalidations Eric Auger

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=ac7cb635-b420-e04d-1a80-6fcfe81d12a8@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).