QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	Bharat Bhushan <bbhushan2@marvell.com>
Cc: yang.zhong@intel.com, peter.maydell@linaro.org,
	kevin.tian@intel.com, tnowicki@marvell.com, mst@redhat.com,
	drjones@redhat.com, peterx@redhat.com, qemu-devel@nongnu.org,
	bharatb.linux@gmail.com, qemu-arm@nongnu.org,
	jean-philippe@linaro.org, linuc.decode@gmail.com,
	David Gibson <david@gibson.dropbear.id.au>,
	eric.auger.pro@gmail.com
Subject: Re: [PATCH v9 1/9] hw/vfio/common: Remove error print on mmio region translation by viommu
Date: Thu, 26 Mar 2020 18:35:48 +0100
Message-ID: <8ec6af3c-6bd7-a3dc-c531-16db6b2089c5@redhat.com> (raw)
In-Reply-To: <20200323170835.5021f845@w520.home>

Hi Alex,

On 3/24/20 12:08 AM, Alex Williamson wrote:
> [Cc +dwg who originated this warning]
> 
> On Mon, 23 Mar 2020 14:16:09 +0530
> Bharat Bhushan <bbhushan2@marvell.com> wrote:
> 
>> On ARM, the MSI doorbell is translated by the virtual IOMMU.
>> As such address_space_translate() returns the MSI controller
>> MMIO region and we get an "iommu map to non memory area"
>> message. Let's remove this latter.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com>
>> ---
>>  hw/vfio/common.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> index 5ca11488d6..c586edf47a 100644
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -426,8 +426,6 @@ static bool vfio_get_vaddr(IOMMUTLBEntry *iotlb, void **vaddr,
>>                                   &xlat, &len, writable,
>>                                   MEMTXATTRS_UNSPECIFIED);
>>      if (!memory_region_is_ram(mr)) {
>> -        error_report("iommu map to non memory area %"HWADDR_PRIx"",
>> -                     xlat);
>>          return false;
>>      }
>>  
> 
> I'm a bit confused here, I think we need more justification beyond "we
> hit this warning and we don't want to because it's ok in this one
> special case, therefore remove it".  I assume the special case is that
> the device MSI address is managed via the SET_IRQS ioctl and therefore
> we won't actually get DMAs to this range.
Yes exactly. The guest creates a mapping between one giova and this gpa
(corresponding to the MSI controller doorbell) because MSIs are mapped
on ARM. But practically the physical device is programmed with an host
chosen iova that maps onto the physical MSI controller's doorbell. so
the device never performs DMA accesses to this range.

  But I imagine the case that
> was in mind when adding this warning was general peer-to-peer between
> and assigned and emulated device.
yes makes sense.

  Maybe there's an argument to be made
> that such a p2p mapping might also be used in a non-vIOMMU case.  We
> skip creating those mappings and drivers continue to work, maybe
> because nobody attempts to do p2p DMA with the types of devices we
> emulate, maybe because p2p DMA is not absolutely reliable on bare metal
> and drivers test it before using it.
MSI doorbells are mapped using the IOMMU_MMIO flag (dma-iommu.c
iommu_dma_get_msi_page).
One idea could be to pass that flag through the IOMMU Notifier mechanism
into the iotlb->perm. Eventually when we get this in vfio_get_vaddr() we
would not print the warning. Could that make sense?

Thanks

Eric



  Anyway, I need a better argument
> why this is ok.  Thanks,
> 
> Alex
> 



  reply index

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23  8:46 [PATCH v9 0/9] virtio-iommu: VFIO integration Bharat Bhushan
2020-03-23  8:46 ` [PATCH v9 1/9] hw/vfio/common: Remove error print on mmio region translation by viommu Bharat Bhushan
2020-03-23 23:08   ` Alex Williamson
2020-03-26 17:35     ` Auger Eric [this message]
2020-03-26 17:53       ` Alex Williamson
2020-03-27  5:50         ` [EXT] " Bharat Bhushan
2020-04-02  9:01         ` Bharat Bhushan
2020-04-24 14:17           ` Auger Eric
2020-05-05  9:25             ` Bharat Bhushan
2020-05-05  9:30               ` Auger Eric
2020-05-05  9:46                 ` Bharat Bhushan
2020-05-05 10:18                   ` Bharat Bhushan
2020-05-05 12:05                     ` Auger Eric
2020-05-07 14:40                     ` Auger Eric
2020-03-23  8:46 ` [PATCH v9 2/9] memory: Add interface to set iommu page size mask Bharat Bhushan
2020-03-26 16:06   ` Auger Eric
2020-03-27  5:33     ` [EXT] " Bharat Bhushan
2020-03-27  8:27       ` Auger Eric
2020-03-23  8:46 ` [PATCH v9 3/9] vfio: set iommu page size as per host supported page size Bharat Bhushan
2020-03-23  8:46 ` [PATCH v9 4/9] virtio-iommu: set supported page size mask Bharat Bhushan
2020-03-26 15:51   ` Auger Eric
2020-03-27  5:13     ` [EXT] " Bharat Bhushan
2020-03-27  8:28       ` Auger Eric
2020-03-23  8:46 ` [PATCH v9 5/9] virtio-iommu: Add iommu notifier for map/unmap Bharat Bhushan
2020-03-23  8:46 ` [PATCH v9 6/9] virtio-iommu: Call iommu notifier for attach/detach Bharat Bhushan
2020-03-23  8:46 ` [PATCH v9 7/9] virtio-iommu: add iommu replay Bharat Bhushan
2020-03-23  8:46 ` [PATCH v9 8/9] virtio-iommu: Implement probe request Bharat Bhushan
2020-03-26 15:48   ` Auger Eric
2020-03-27  5:40     ` [EXT] " Bharat Bhushan
2020-03-27  8:34       ` Auger Eric
2020-04-23 16:09   ` Jean-Philippe Brucker
2020-04-24 13:51     ` Auger Eric
2020-05-05  9:06       ` Bharat Bhushan
2020-05-07 14:42         ` Auger Eric
2020-03-23  8:46 ` [PATCH v9 9/9] virtio-iommu: add iommu notifier memory-region Bharat Bhushan
2020-03-23  9:52 ` [PATCH v9 0/9] virtio-iommu: VFIO integration no-reply
2020-03-23  9:59 ` no-reply

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=8ec6af3c-6bd7-a3dc-c531-16db6b2089c5@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=bbhushan2@marvell.com \
    --cc=bharatb.linux@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=drjones@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=jean-philippe@linaro.org \
    --cc=kevin.tian@intel.com \
    --cc=linuc.decode@gmail.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=tnowicki@marvell.com \
    --cc=yang.zhong@intel.com \
    /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

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git