From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Determining iommu groups in Xen? Date: Thu, 28 Aug 2014 19:02:47 +0100 Message-ID: <53FF6EC7.8010805@citrix.com> References: <9d3d72b8-afe1-4bde-917a-be5b3674889e@email.android.com> <53FF3479.9050907@citrix.com> <53FF6323.5060100@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Peter Kay , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 28/08/14 18:53, Peter Kay wrote: > > On 28 August 2014 18:13:07 BST, Andrew Cooper 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