From: Jason Wang <jasowang@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
mst@redhat.com, qemu-devel@nongnu.org, cornelia.huck@de.ibm.com,
pbonzini@redhat.com, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH 6/8] intel_iommu: support device iotlb descriptor
Date: Wed, 30 Mar 2016 13:08:45 +0800 [thread overview]
Message-ID: <56FB5F5D.90405@redhat.com> (raw)
In-Reply-To: <20160328033753.GK28183@pxdev.xzpeter.org>
On 03/28/2016 11:37 AM, Peter Xu wrote:
> On Fri, Mar 25, 2016 at 10:13:27AM +0800, Jason Wang wrote:
>> This patch enables device IOTLB support for intel iommu. The major
>> work is to implement QI device IOTLB descriptor processing and notify
>> the device through iommu notifier.
>>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
>> Cc: Richard Henderson <rth@twiddle.net>
>> Cc: Eduardo Habkost <ehabkost@redhat.com>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> hw/i386/intel_iommu.c | 81 ++++++++++++++++++++++++++++++++++++++----
>> hw/i386/intel_iommu_internal.h | 13 +++++--
>> 2 files changed, 86 insertions(+), 8 deletions(-)
>>
> [...]
>
>> +static bool vtd_process_device_iotlb_desc(IntelIOMMUState *s,
>> + VTDInvDesc *inv_desc)
>> +{
>> + VTDAddressSpace *vtd_dev_as;
>> + IOMMUTLBEntry entry;
>> + struct VTDBus *vtd_bus;
>> + hwaddr addr;
>> + uint64_t sz;
>> + uint16_t sid;
>> + uint8_t devfn;
>> + bool size;
>> + uint8_t bus_num;
>> +
>> + addr = VTD_INV_DESC_DEVICE_IOTLB_ADDR(inv_desc->hi);
>> + sid = VTD_INV_DESC_DEVICE_IOTLB_SID(inv_desc->lo);
>> + devfn = sid & 0xff;
>> + bus_num = sid >> 8;
>> + size = VTD_INV_DESC_DEVICE_IOTLB_SIZE(inv_desc->hi);
>> +
>> + if ((inv_desc->lo & VTD_INV_DESC_DEVICE_IOTLB_RSVD_LO) ||
>> + (inv_desc->hi & VTD_INV_DESC_DEVICE_IOTLB_RSVD_HI)) {
>> + VTD_DPRINTF(GENERAL, "error: non-zero reserved field in Device "
>> + "IOTLB Invalidate Descriptor hi 0x%"PRIx64 " lo 0x%"PRIx64,
>> + inv_desc->hi, inv_desc->lo);
>> + return false;
>> + }
>> +
>> + vtd_bus = vtd_find_as_from_bus_num(s, bus_num);
>> + if (!vtd_bus) {
>> + goto done;
>> + }
>> +
>> + vtd_dev_as = vtd_bus->dev_as[devfn];
>> + if (!vtd_dev_as) {
>> + goto done;
>> + }
>> +
>> + if (size) {
>> + sz = ffsll(~(addr >> VTD_PAGE_SHIFT));
>> + addr = addr & ~((1 << (sz + VTD_PAGE_SHIFT)) - 1);
>> + sz = VTD_PAGE_SIZE << sz;
> For these three lines, could it be shorter like:
>
> sz = 1 << ffsll(~addr);
> addr &= ~(sz - 1);
>
> It seems that we can avoid using VTD_PAGE_*.
Some lower bits of addr is zero (since it was reserved), so this may not
work. Looks like it could be optimized to
sz = 1 << ffsll(~(addr | (VTD_PAGE_MASK - 1)));
addr &= ~(sz - 1);
>
>> + } else {
>> + sz = VTD_PAGE_SIZE;
>> + }
>> +
>> + entry.target_as = &vtd_dev_as->as;
>> + entry.addr_mask = sz - 1;
>> + entry.iova = addr;
>> + memory_region_notify_iommu(entry.target_as->root, entry);
> Here, we seems to be posting this invalidation to all registered
> notifiers.
Yes, but only for a device specified address space.
> Since this is a device-tlb invalidation, and we should
> know which device (BDF) that we should invalidate, is there any way
> that we can directly route this info to that specific device?
Looks like the codes has already done this, the target_as was found by
bus num and devfn.
>
> E.g., if we enable VFIO with current patch, this notify will
> possibly be passed to VFIO devices as well, even it's actually for
> vhost devices. Not sure whether there would be problem.
Not sure, but if the underlaying device has ATS capability, we probably
need to propagate the invalidation to the device itself too.
>
> Another thing totally not related to this patch: I see that the
> second parameter for memory_region_notify_iommu() is IOMMUTLBEntry,
> rather than its pointer. While inside of the funccall, it only
> passes in the pointer directly:
>
> void memory_region_notify_iommu(MemoryRegion *mr,
> IOMMUTLBEntry entry)
> {
> assert(memory_region_is_iommu(mr));
> notifier_list_notify(&mr->iommu_notify, &entry);
> }
>
> Shall we change "entry" into a pointer as well? I found no reason
> why we need to keep this IOMMUTLBEntry in stack twice...
>
> Thanks.
>
> -- peterx
>
Right, it looks ok to change to use a pointer.
next prev parent reply other threads:[~2016-03-30 5:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-25 2:13 [Qemu-devel] [RFC PATCH 0/8] virtio/vhost DMAR support Jason Wang
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 1/8] virtio: convert to use DMA api Jason Wang
2016-04-19 13:37 ` Michael S. Tsirkin
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 2/8] intel_iommu: name vtd address space with devfn Jason Wang
2016-03-28 2:02 ` Peter Xu
2016-03-30 1:12 ` Jason Wang
2016-03-30 11:12 ` Michael S. Tsirkin
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 3/8] intel_iommu: allocate new key when creating new address space Jason Wang
2016-03-28 2:07 ` Peter Xu
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 4/8] exec: introduce address_space_get_iotlb_entry() Jason Wang
2016-03-28 2:18 ` Peter Xu
2016-03-30 1:13 ` Jason Wang
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 5/8] virtio-pci: address space translation service (ATS) support Jason Wang
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 6/8] intel_iommu: support device iotlb descriptor Jason Wang
2016-03-28 3:37 ` Peter Xu
2016-03-30 5:08 ` Jason Wang [this message]
2016-03-30 5:21 ` Peter Xu
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 7/8] memory: handle alias for iommu notifier Jason Wang
2016-03-25 2:13 ` [Qemu-devel] [RFC PATCH 8/8] vhost_net: device IOTLB support Jason Wang
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=56FB5F5D.90405@redhat.com \
--to=jasowang@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).