All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Aviv B.D." <bd.aviv@gmail.com>
Cc: marcel@redhat.com, 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: Fri, 18 Mar 2016 11:06:43 +0800	[thread overview]
Message-ID: <20160318030643.GI23495@pxdev.xzpeter.org> (raw)
In-Reply-To: <CAM3WwMjACYVF3n_inUVWjzJHAbPvzUjTrvm1q7QNQf+gxxqHMQ@mail.gmail.com>

On Thu, Mar 17, 2016 at 01:17:30PM +0200, Aviv B.D. wrote:
[...]
> vtd_get_did_dev returns -1 if the device is not mapped to any domain
> (generally, the CE is not present).
> probably a better interface is to return whether the device has a domain or
> not and returns the domain_id via the pointer argument.

Possibly, as long as guest kernel might be using (uint16_t)-1 as
domain ID. ;)

> 
> 
> >
> > > >+                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?
> >
> With this code I do a unmap operation if the address was cached in the
> IOTLB, if not I'm assuming that the current invalidation invalidate an
> (previously) non present address and I should do a map operation (during
> the map operation I'm calling s->iommu_ops.translate that caches the
> address).

I am not 100% sure of this, but... is this related to IOTLB at all?
What I see is that, IOTLB is only a cache layer of IOMMU, and it is
possible that we mapped some areas which are not in the IOTLB at
all.

Or, let's make an assumption here: what if I turn IOTLB off (or say,
set hash size to zero)? IOMMU should still work, though slower,
right?  However, due to above checking, we'll never do ummap() in
this case (while IMHO we should).

Thanks.

-- peterx

  reply	other threads:[~2016-03-18  3:06 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
2016-03-17 11:17     ` Aviv B.D.
2016-03-18  3:06       ` Peter Xu [this message]
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=20160318030643.GI23495@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.