Linux IOMMU Development
 help / color / mirror / Atom feed
From: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
To: Robin Murphy <robin.murphy@arm.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
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>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
	"hch@lst.de" <hch@lst.de>, "Lu, Baolu" <baolu.lu@intel.com>
Subject: Re: Device specific pass through in host systems - discuss user interface
Date: Fri, 07 Jun 2019 18:44:43 -0700	[thread overview]
Message-ID: <12f8c572074b7963705ba066fdde0f9fdf0bfc62.camel@intel.com> (raw)
In-Reply-To: <3fa16135-b2bb-03b5-833a-bce8cc68f35f@arm.com>


> It's interesting to see this from a fresh angle which isn't clouded by 
> other SoC GPU details - thanks for the proposal! A couple more thoughts 
> jump out immediately...
> 

Thanks a lot! for jumping in and providing your valuable insights :)
Sorry! for taking time to reply on this. Did some quick testing on
unbinding/binding stuff.

> > Since, this feature could be generic across architectures, we thought it
> > would be better if the user interface is discussed in the community first.
> > We are envisioning this to be used both during boot time and runtime and
> > hence having a kernel command line argument along with a sysfs entry are
> > needed. So, please pour in your suggestions on how the user interface
> > should look like to make it architecture agnostic.
> > 
> > 
> > 1.      Have a kernel command line argument that takes a list of BDF's as
> > an input and puts them in pass through mode
> > 
> > a.      Accepting BDF as an input has a downside - BDF is dynamic and
> > could change if BIOS/OS enumerates a new device in next reboot
> > 
> > b.      Accepting <vendor_id:device_id> pair as an input has a downside -
> > What to do when there are multiple such devices and user would like to put
> > only some of them in PT mode
> > 
> 
> c. Not all devices are PCI in the first place.

Agreed, maybe we could limit this feature only to PCIe devices :(

> 
> > 2.      Have a sysfs file which takes 1 or 0 as an input to enable/disable
> > pass through mode. Some places that seem to be reasonable are
> > 
> > a.      /sys/class/iommu/dmar0/devices/
> > 
> > b.      /sys/kernel/iommu_groups/<id>/devices
> 
> Note that this this works out a bit tricky to actually use, since 
> changing the meaning of DMA addresses under the device's feet would be 
> disastrous.

Yes, that makes sense.

> It can only safely take effect by unbinding and rebinding 
> the driver and/or resetting the device (as a side note, this starts to 
> overlap with the IOMMU-drivers-as-modules concept, and whatever solution 
> to this we end up with may be helpful in making that work too). In most 
> cases that's probably viable, but not every driver supports unbinding, 
> and either way what if the device in question is the one hosting the 
> root filesystem... :/

We would like to propose something like this

1. User will first unbind the device driver by
echo "BDF" > /sys/bus/pci/drivers/<device_driver>/unbind

2. Set the Pass Through bit (this is to say the intent of the user that upon
the next rebind, please make this device as pass through)
echo 1 > /sys/class/iommu/dmar0/devices/<BDF>/pt

3. Re-bind the driver again
echo "BDF" > /sys/bus/pci/drivers/<device_driver>/bind

So, if the driver doesn't support unbind then the user cannot put the device
in pass through mode, in which case he has to use kernel command line
argument.

I did unbind on my device that has root file system and after that I was
unable to run any command (like cat or echo), which made sense. So, it's upto
the user to decide which devices can go through unbind and hence can be put in
pass through mode. Since this feature requires sudo privileges, I think, we
can assume admin does the right thing.

Please let me know what you think about this and also please do suggest if you
have any other better ways to deal with this.

Regards,
Sai

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2019-06-08  1:48 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 [this message]
2019-06-08  7:27     ` hch
2019-06-08 18:38       ` Sai Praneeth Prakhya
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=12f8c572074b7963705ba066fdde0f9fdf0bfc62.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