From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH RFC] p2m: p2m_mmio_direct set RW permissions Date: Thu, 22 Jan 2015 10:59:38 +0000 Message-ID: <54C0D81A.2020705@citrix.com> References: <20150121205537.GA7081@elena.ufimtseva> <54C0D6B80200007800057FD1@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54C0D6B80200007800057FD1@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Elena Ufimtseva Cc: kevin.tian@intel.com, tim@xen.org, xen-devel@lists.xen.org, yang.z.zhang@intel.com, boris.ostrovsky@oracle.com, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 22/01/15 09:53, Jan Beulich wrote: >>>> On 21.01.15 at 21:55, wrote: >> p2m_mmio_direct should result in setting IOMMUF_readable and IOMMUF_writable >> flags. >> When pvh domain maps mmio regions, the EPT entries are not getting mapped. >> This leads to IOMMU Page faults for some devices, as for example USB Host >> controllers with embedded Debug devices. See pvh-set-need_iommu-early RFC >> patch discussion fgor detail. > Even more so that the two patches aren't even a series, that part > of the description belongs here, not in the other patch. > >> I will appreciate your comments and ideas in regards to this change. >> >> Looking at Roger patches (xen/pvh: check permissions when adding MMIO >> regions) >> the mmio memory type is proposed to be changed from p2m_mmio_direct to >> p2m_access_rw. >> This type still does not have proper IOMMU flags mapping. > A fundamental question is what business devices have to DMA their > own (or other devices') MMIO space. I could remotely see a need > for this for e.g. frame buffers, but I have difficulty understanding > this for USB devices. Please at the very least provide details on the > MMIO regions that those devices have, and which of them you > observed IOMMU faults on. It would appear that, in this case, it is a USB controller lacking an appropriate RMRR description in the ACPI tables. I feel it would be better to have a command line option to add extra RMRRs, similar to ivrs_{hpet,ioapic} for AMD firmware issues. Of course, this would also rely on the RMRR series currently still in design. ~Andrew