xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Peter Kay <syllopsium@syllopsium.co.uk>, xen-devel@lists.xen.org
Subject: Re: Determining iommu groups in Xen?
Date: Thu, 28 Aug 2014 14:54:01 +0100	[thread overview]
Message-ID: <53FF3479.9050907@citrix.com> (raw)
In-Reply-To: <9d3d72b8-afe1-4bde-917a-be5b3674889e@email.android.com>

On 28/08/14 14:26, Peter Kay wrote:
> This should be a simple question, but I can't find the answer : how are iommu groups determined/found in Xen?
>
> I've used KVM before, and the use of the vfio framework makes it easy to find the iommu groups. Unless a 'will never be approved' patch is applied to the Linux kernel, it is impossible to pass through only one device to a KVM VM out of a group due to the lack of ACS (iommu protection between devices on the same bus segment).
>
> Xen does not seem to enforce this - why not, especially as it can cause security and stability issues?
>
> PK

>From memory, ACS is present to fix an interaction issue between PCI
Passthrough and peer-to-peer dma translations in the PCIe spec.  ACS
instructions a bridge/switch to forward the transaction to the upstream
port for translation by the IOMMU instead of resolving it privately as a
peer-to-peer transaction.

Xen uses the domain identifier to determine which iommu context to apply
to different dma requests.  Without ACS, it is not safe (or indeed
functional in general) to pass through different devices behind a PCIe
switch to different domains.  The problem is that if two different
domains program different devices with overlapping guest physical
addresses, the peer-to-peer option in PCIe causes the dma traffic to be
bounced between the two devices, rather than ending up being translated
into separate domains memory ranges.

Unfortunately, a lot of 1st era PCIe switches after ACS was specified
have errata, caused by an ambiguity in the spec, which means that
despite claiming ACS support, they don't function correctly.  In some
cases, there are workarounds, but in other cases there are not.

It is sad to say that passing through multiple devices behind a switch
to multiple domains doesn't work very well in a lot of cases.

Certainly within XenServer, we state that customers using PCIPassthrough
must trust the guest administrators, which 'fixes' the security aspect
of things from the point of view of malicious guests.

~Andrew

  reply	other threads:[~2014-08-28 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 13:26 Determining iommu groups in Xen? Peter Kay
2014-08-28 13:54 ` Andrew Cooper [this message]
2014-08-28 16:48   ` Peter Kay
2014-08-28 17:13     ` Andrew Cooper
2014-08-28 17:53       ` Peter Kay
2014-08-28 18:02         ` Andrew Cooper
2014-08-28 18:45           ` Peter Kay
2014-08-29  0:35             ` Peter Kay
2014-08-29  8:27               ` Andrew Cooper
2014-08-29 14:34                 ` Konrad Rzeszutek Wilk

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=53FF3479.9050907@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=syllopsium@syllopsium.co.uk \
    --cc=xen-devel@lists.xen.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).