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
next prev parent 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).