From: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
To: "hch@lst.de" <hch@lst.de>
Cc: "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"jroedel@suse.de" <jroedel@suse.de>,
"Raj, Ashok" <ashok.raj@intel.com>,
Will Deacon <will.deacon@arm.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
Robin Murphy <robin.murphy@arm.com>,
"Lu, Baolu" <baolu.lu@intel.com>
Subject: Re: Device specific pass through in host systems - discuss user interface
Date: Sat, 08 Jun 2019 11:38:58 -0700 [thread overview]
Message-ID: <0467c18559982ca9fd2c9ed4f3cf826fd3487dab.camel@intel.com> (raw)
In-Reply-To: <20190608072751.GA18928@lst.de>
On Sat, 2019-06-08 at 09:27 +0200, hch@lst.de wrote:
> Just curious, what exactly is the use case? Explaining how someone
> would wan to use this should drive the way we design an interface for it.
Makes sense.
Some example use cases:
1. Assume an SR-IOV device and if the admin decides to use some VF's natively
(i.e. they are available only to host) and he wants them to be high performing
and also believes that his OS is secure enough (so decides to by pass IOMMU).
Presently, we don't support this use case because "iommu=pt" kernel command
line argument is an all or none feature i.e. either all BDF's are translated
through IOMMU or none. So, we would like to propose a per-BDF on/off feature.
We would also want it to be run-time (i.e. sysfs based interface) rather than
just boot-time interface (kernel command line argument).
Also, want to be clear that it's not just SR-IOV devices that we are looking
at but could be any unrelated PCIe devices i.e. a SATA device, USB, NIC or
GFx. Wherein the admin wants to selectively put NIC and GFx through IOMMU and
does not want transactions by SATA and USB to be translated by IOMMU.
Regards,
Sai
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-06-08 18:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 2:24 Device specific pass through in host systems - discuss user interface Prakhya, Sai Praneeth
2019-06-07 12:41 ` Robin Murphy
2019-06-08 1:44 ` Sai Praneeth Prakhya
2019-06-08 7:27 ` hch
2019-06-08 18:38 ` Sai Praneeth Prakhya [this message]
2019-06-09 3:20 ` Lu, Baolu
2019-06-10 5:41 ` Prakhya, Sai Praneeth
2019-06-10 13:56 ` Raj, Ashok
2019-06-11 4:38 ` Prakhya, Sai Praneeth
2019-06-11 4:56 ` Raj, Ashok
2019-06-11 17:27 ` Prakhya, Sai Praneeth
2019-07-01 8:59 ` jroedel
2019-07-03 2:01 ` Prakhya, Sai Praneeth
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=0467c18559982ca9fd2c9ed4f3cf826fd3487dab.camel@intel.com \
--to=sai.praneeth.prakhya@intel.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@intel.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jroedel@suse.de \
--cc=kevin.tian@intel.com \
--cc=ravi.v.shankar@intel.com \
--cc=robin.murphy@arm.com \
--cc=will.deacon@arm.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
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