Re: [Xen-devel] [PATCH RFC 5/5] pvh: dom0 boot option to specify iommu rw ranges

[Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>]

On Fri, Feb 13, 2015 at 10:09:39PM +0000, Andrew Cooper wrote:
> On 13/02/15 18:52, Elena Ufimtseva wrote:
> > It appears from the experiments that some devices on few systems
> > may attempt to access memory ranges that are not RMRRs regions (and
> > are not reported by ACPI) and are reserved in the host e820 map.
> > These memory addresses appear to be the targets for DMA reads by
> > devices. Presumably, these devices may be the USB debug ports.
> > When devices issues DMA read, EPT violation in some cases is being
> > reported. Some particular machines do not report EPT violation and
> > become unresponsive (example Dell T5600).
> >
> > This patch introduces xen boot option dom0_iommu_rwmem that allows
> > to specify these special ranges and perform mapping with required
> > access rights. For this purpose p2m type p2m_sys_rw was introduced.
> > For now it has RW permissions, though from experiments read permission
> > is enough.
> >
> > dom0_iommu_rwmem has following format:
> > =<start:end>,<start:end>,...
> > where start and end are mfns (or pfn, as 1:1 mapping performed).
> > Ranges number is limited to 10 and can be changed.
> >
> > TODO:
> >  - make sure the user defined regions do not conflict with disallowed
> >  io regions as ioapic etc;
> >  - comply with rmrr design;
> >  - naming convention;
> >  - only applicable for vtd for now, other arch is in question;
> >
> > Signed-off-by: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>
> 
> The problem in question appears to be that the needs of USB debugging
> (i.e. reading from a magic BIOS location) are not reflected correctly in
> the systems ACPI tables (probably because noone ever tried to use USB
> debugging on that platform).

Presumably USB debug devices. Actually, I have not done anything to
actually use it, but the debug port is there with its own mmio regions
reported correctly.

> 
> This proposed solution doesn't account for situations like dom0 wishing
> to pass the offending device through to a domU.

Correct, this is in the plan for next patches.
> 
> If I understand the problem correctly, I believe that the correct
> solution would be to add a dmar_rmrr[ command line parameter along the
> same lines as ivrs_hpet[ and ivrs_ioapic[ which allows the user to
> inject corrections to the ACPI tables via the command line.

Yes, if we agree to classify those magic locations as being not reported
by ACPI machinery.

> 
> In this case, something like dmar_rmrr[sbdf]=<size>@<start>.  Xen can
> then treat this in exactly the same way as if it had found the RMRR in
> the ACPI tables.
> 
> Or am I missing something?

This possibly will work and I have discussed similar approach with
Konrad and his reply was similar. I wil see where discussion goes and
will work on next version of patches.
> 
> ~Andrew
> 

Thank you Andrew for quick review of the patches.

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