From: Peter Xu <peterx@redhat.com>
To: marcel@redhat.com, bd.aviv@gmail.com
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
Alex Williamson <alex.williamson@redhat.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH][RFC] IOMMU: Add Support to VFIO devices with vIOMMU present
Date: Tue, 15 Mar 2016 16:52:36 +0800 [thread overview]
Message-ID: <20160315085236.GA23495@pxdev.xzpeter.org> (raw)
In-Reply-To: <56E70871.3050305@gmail.com>
On Mon, Mar 14, 2016 at 08:52:33PM +0200, Marcel Apfelbaum wrote:
> On 03/12/2016 06:13 PM, Aviv B.D. wrote:
> Adding (possibly) interested developers to the thread.
Thanks CC.
Hi, Aviv, several questions inline.
[...]
> >@@ -1020,14 +1037,53 @@ static void vtd_iotlb_page_invalidate(IntelIOMMUState *s, uint16_t domain_id,
> > hwaddr addr, uint8_t am)
> > {
> > VTDIOTLBPageInvInfo info;
> >+ VFIOGuestIOMMU * giommu;
> >+ bool flag = false;
> > assert(am <= VTD_MAMV);
> > info.domain_id = domain_id;
> > info.addr = addr;
> > info.mask = ~((1 << am) - 1);
> >+
> >+ QLIST_FOREACH(giommu, &(s->giommu_list), iommu_next){
> >+ VTDAddressSpace *vtd_as = container_of(giommu->iommu, VTDAddressSpace, iommu);
> >+ uint16_t vfio_source_id = vtd_make_source_id(pci_bus_num(vtd_as->bus), vtd_as->devfn);
> >+ uint16_t vfio_domain_id = vtd_get_did_dev(s, pci_bus_num(vtd_as->bus), vtd_as->devfn);
> >+ if (vfio_domain_id != (uint16_t)-1 &&
Could you (or anyone) help explain what does vfio_domain_id != -1
mean?
> >+ domain_id == vfio_domain_id){
> >+ VTDIOTLBEntry *iotlb_entry = vtd_lookup_iotlb(s, vfio_source_id, addr);
> >+ if (iotlb_entry != NULL){
Here, shall we notify VFIO even if the address is not cached in
IOTLB? Anyway, we need to do the unmap() of the address, am I
correct?
> >+ IOMMUTLBEntry entry;
> >+ VTD_DPRINTF(GENERAL, "Remove addr 0x%"PRIx64 " mask %d", addr, am);
> >+ entry.iova = addr & VTD_PAGE_MASK_4K;
> >+ entry.translated_addr = vtd_get_slpte_addr(iotlb_entry->slpte) & VTD_PAGE_MASK_4K;
> >+ entry.addr_mask = ~VTD_PAGE_MASK_4K;
> >+ entry.perm = IOMMU_NONE;
> >+ memory_region_notify_iommu(giommu->iommu, entry);
> >+ flag = true;
> >+
> >+ }
> >+ }
> >+
> >+ }
> >+
> > g_hash_table_foreach_remove(s->iotlb, vtd_hash_remove_by_page, &info);
> >-}
> >+ QLIST_FOREACH(giommu, &(s->giommu_list), iommu_next){
> >+ VTDAddressSpace *vtd_as = container_of(giommu->iommu, VTDAddressSpace, iommu);
> >+ uint16_t vfio_domain_id = vtd_get_did_dev(s, pci_bus_num(vtd_as->bus), vtd_as->devfn);
> >+ if (vfio_domain_id != (uint16_t)-1 &&
> >+ domain_id == vfio_domain_id && !flag){
> >+ /* do vfio map */
> >+ VTD_DPRINTF(GENERAL, "add addr 0x%"PRIx64 " mask %d", addr, am);
> >+ /* call to vtd_iommu_translate */
> >+ IOMMUTLBEntry entry = s->iommu_ops.translate(giommu->iommu, addr, 0);
> >+ entry.perm = IOMMU_RW;
> >+ memory_region_notify_iommu(giommu->iommu, entry);
> >+ //g_vfio_iommu->n.notify(&g_vfio_iommu->n, &entry);
> >+ }
> >+ }
> >+}
I see that we did handled all the page invalidations. Would it
possible that guest kernel send domain/global invalidations? Should
we handle them too?
[...]
> > static void vfio_listener_region_add(MemoryListener *listener,
> > MemoryRegionSection *section)
> > {
> >@@ -344,6 +347,7 @@ static void vfio_listener_region_add(MemoryListener *listener,
> > iova = TARGET_PAGE_ALIGN(section->offset_within_address_space);
> > llend = int128_make64(section->offset_within_address_space);
> > llend = int128_add(llend, section->size);
> >+ llend = int128_add(llend, int128_exts64(-1));
Here, -1 should fix the assertion core dump. However, shall we also
handle all the rest places that used "llend" (possibly with variable
"end") too? For example, at the end of current function, when we map
dma regions:
ret = vfio_dma_map(container, iova, end - iova, vaddr, section->readonly);
To:
ret = vfio_dma_map(container, iova, end + 1 - iova, vaddr, section->readonly);
Thanks.
Peter
next prev parent reply other threads:[~2016-03-15 8:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-12 16:13 [Qemu-devel] [PATCH][RFC] IOMMU: Add Support to VFIO devices with vIOMMU present Aviv B.D.
2016-03-14 18:52 ` Marcel Apfelbaum
2016-03-14 18:58 ` Jan Kiszka
2016-03-15 7:00 ` Michael S. Tsirkin
2016-03-15 8:52 ` Peter Xu [this message]
2016-03-17 11:17 ` Aviv B.D.
2016-03-18 3:06 ` Peter Xu
2016-03-19 9:40 ` Aviv B.D.
2016-03-21 2:30 ` Peter Xu
2016-03-22 8:13 ` Aviv B.D.
2016-03-15 10:53 ` Michael S. Tsirkin
2016-03-17 11:58 ` Aviv B.D.
2016-03-23 14:34 ` Michael S. Tsirkin
2016-03-23 14:33 ` Michael S. Tsirkin
2016-03-26 14:47 ` Aviv B.D.
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=20160315085236.GA23495@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=bd.aviv@gmail.com \
--cc=jan.kiszka@siemens.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--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).