From: Jintack Lim <jintack@cs.columbia.edu>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Peter Xu <peterx@redhat.com>, Eric Auger <eric.auger@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
QEMU Devel Mailing List <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] intel-iommu and vhost: Do we need 'device-iotlb' and 'ats'?
Date: Fri, 23 Feb 2018 09:58:52 -0500 [thread overview]
Message-ID: <CAHyh4xg2GPwdUK=jnP6SN9AdHzyVSJnu9ZXManF08_nnQna6wA@mail.gmail.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D191015735@SHSMSX101.ccr.corp.intel.com>
Hi Kevin,
On Fri, Feb 23, 2018 at 2:34 AM, Tian, Kevin <kevin.tian@intel.com> wrote:
>> From: Peter Xu
>> Sent: Friday, February 23, 2018 3:09 PM
>>
>> >
>> > Right. I think my question was not clear. My question was that why don’t
>> > IOMMU invalidate device-iotlb along with its mappings in one go. Then
>> IOMMU
>> > device driver doesn’t need to flush device-iotlb explicitly. Maybe the
>> > reason is that ATS and IOMMU are not always coupled.. but I guess it’s
>> time
>> > for me to get some more background :)
>>
>> Ah, I see your point.
>>
>> I don't know the answer. My wild guess is that IOMMU is just trying
>> to be simple and only provide most basic functionalities, leaving
>> complex stuff to CPU. For example, if IOMMU takes over the ownership
>> to deliever device-iotlb invalidations when receiving iotlb
>> invalidations, it possibly needs to traverse the device tree sometimes
>> (e.g., for domain invalidations) to know what device is under what
>> domain, which is really compliated. While it'll be simpler for CPU to
>> do this since it's very possible that the OS keeps a list of devices
>> for a domain already.
>>
>> IMHO that follows the *nix philosophy too - Do One Thing And Do It
>> Well. Though again, it's wild guess and I may be wrong. :)
>>
>> CCing Alex, in case he has quick answers.
>>
>
> IOMMU and devices are de-coupled. You need a protocol so IOMMU
> knows which device enables translation caches and thus requires
> explicit invalidation, which is how ATS comes to play. ATS is not
> mandatory for vhost, but doing so provides more flexibility e.g.
> to enable I/O page fault if further emulating PCI PRS cap.
Thanks for the explanation!
Thanks,
Jintack
>
> Thanks
> Kevin
next prev parent reply other threads:[~2018-02-23 14:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-21 4:03 [Qemu-devel] intel-iommu and vhost: Do we need 'device-iotlb' and 'ats'? Jintack Lim
2018-02-23 3:55 ` Peter Xu
2018-02-23 5:32 ` Jintack Lim
2018-02-23 6:10 ` Peter Xu
2018-02-23 6:34 ` Jintack Lim
2018-02-23 7:09 ` Peter Xu
2018-02-23 7:34 ` Tian, Kevin
2018-02-23 14:58 ` Jintack Lim [this message]
2018-02-23 14:39 ` Jintack Lim
2018-02-26 10:14 ` Auger Eric
2018-02-26 20:44 ` Jintack Lim
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='CAHyh4xg2GPwdUK=jnP6SN9AdHzyVSJnu9ZXManF08_nnQna6wA@mail.gmail.com' \
--to=jintack@cs.columbia.edu \
--cc=alex.williamson@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jasowang@redhat.com \
--cc=kevin.tian@intel.com \
--cc=peterx@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).