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 19:02:47 +0100	[thread overview]
Message-ID: <53FF6EC7.8010805@citrix.com> (raw)
In-Reply-To: <f3cef500-01e4-4dd6-99db-6e1075a6b32e@email.android.com>

On 28/08/14 18:53, Peter Kay wrote:
>
> On 28 August 2014 18:13:07 BST, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 28/08/14 17:48, Peter Kay wrote:
>>> Fair enough; possibly not ideal but it's an administrator function
>> with calculated risk. A warning might be nice, though.
>>
>> I am not aware of a single server platform which doesn't have a single
>> erraturm which breaks the end-to-end security or functionality of PCI
>> Passthrough.  I would love to be proved wrong in this regard.
> I will try and find the PCI quirk posts for KVM.
>
>> I am confused as to what exactly you mean by iommu groups in this
>> context.  My initial guess of the iommu context identifiers for HAP/EPT
>> tables was clearly wrong.
> An iommu group, as far as I'm aware, is the group of devices that are not protected from each other. In KVM, you must pass through the entire group to a VM at once, unless a 'don't go crying to me if it stomps over your memory space or worse' patch is applied to the kennel claiming that everything is fine.

I have googled the term in the meantime, and it is what I initially thought.

All PCI devices passed though to the same domain share the same single
"iommu group" per Kernel/KVM terminology.  There is not currently any
support for multiple iommu contexts within a single VM.

~Andrew

>
>
>> Almost certainly to do with the (lack of correct) RMRR support.  There
>> is a patch series on-list attempting to remedy this problem.
> Thank you, I'll search for this. It does pass through reliably in KVM, which is good, because their virtual USB sucks. I'm reasonably certain that my S3210SHLC motherboard is quite solid, provided you accept some of the interesting design decisions. (Well, apart from leaving the X38 audio chipset inaccessible, but present enough to confuse the Linux kernel to hang on boot occasionally)
>
> PK

  reply	other threads:[~2014-08-28 18:02 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
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 [this message]
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=53FF6EC7.8010805@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).