[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] p2m: p2m_mmio_direct set RW permissions



On Thu, Jan 22, 2015 at 04:42:52PM +0100, Roger Pau Monné wrote:
> El 22/01/15 a les 16.18, Elena Ufimtseva ha escrit:
> > 
> > ----- JBeulich@xxxxxxxx wrote:
> > 
> >>>>> On 22.01.15 at 12:37, <roger.pau@xxxxxxxxxx> wrote:
> >>> El 22/01/15 a les 12.09, Jan Beulich ha escrit:
> >>>>>>> On 22.01.15 at 11:59, <andrew.cooper3@xxxxxxxxxx> wrote:
> >>>>> On 22/01/15 09:53, Jan Beulich wrote:
> >>>>>>>>> On 21.01.15 at 21:55, <elena.ufimtseva@xxxxxxxxxx> 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.
> >>>>
> >>>> No, RMRRs only reference RAM pages afaik.
> >>>
> >>> According to Linux IOMMU support document RMRRs reference regions
> >> marked
> >>> as "reserved" in the e820 memory map:
> >>>
> >>> https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt 
> >>
> >> Exactly. And MMIO PCI BARs in particular are never to be
> >> reflected in the E820 (not the least because they're relocatable).
> >>
> >>> I don't think we are setting proper IOMMU entries for this regions
> >> at
> >>> all with the current PVH Dom0 code. IMHO instead of just adding
> >> IOMMU
> >>> entries for every MMIO region we should just add IOMMU entries for
> >> the
> >>> RMRR regions.
> >>
> >> Yes, RMRR regions should certainly be put there as r/w entries.
> >>
> >> Jan
> > 
> > How it will help in cases like this when this regions are not reported as 
> > RMRRs in ACPI?
> 
> AFAIK even if they are properly reported as RMRRs they won't have the
> right IOMMU mappings, are you sure they are not reported as RMRRs?
> 
> Roger.
> 

Yes, they are not RMRRs but I am about to send more details on this.

Elena


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.