Re: [Xen-devel] [PATCH] VT-d: fix RMRR handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.02.14 at 18:38, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 10/02/14 13:42, Jan Beulich wrote:
>> Removing mapped RMRR tracking structures in dma_pte_clear_one() is
>> wrong for two reasons: First, these regions may cover more than a
>> single page. And second, multiple devices (and hence multiple devices
>> assigned to any particular guest) may share a single RMRR (whether
>> assigning such devices to distinct guests is a safe thing to do is
>> another question).
>>
>> Therefore move the removal of the tracking structures into the
>> counterpart function to the one doing the insertion -
>> intel_iommu_remove_device(), and add a reference count to the tracking
>> structure.
>>
>> Further, for the handling of the mappings of the respective memory
>> regions to be correct, RMRRs must not overlap. Add a respective check
>> to acpi_parse_one_rmrr().
>>
>> And finally, with all of this being VT-d specific, move the cleanup
>> of the list as well as the structure type definition where it belongs -
>> in VT-d specific rather than IOMMU generic code.
>>
>> Note that this doesn't address yet another issue associated with RMRR
>> handling: The purpose of the RMRRs as well as the way the respective
>> IOMMU page table mappings get inserted both suggest that these regions
>> would need to be marked E820_RESERVED in all (HVM?) guests' memory
>> maps, yet nothing like this is being done in hvmloader. (For PV guests
>> this would also seem to be necessary, but may conflict with PV guests
>> possibly assuming there to be just a single E820 entry representing all
>> of its RAM.)
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Having read up on RMRRs again, I suspect it is more complicated.  RMRRs
> are for legacy devices which need to DMA to the BIOS to function
> correctly.  In the case of dom0, they should necessarily be identity
> mapped in the IOMMU tables (which does appear to be the case currently).
> 
> For domains with passthrough of a device using an RMRR, then the region
> should be marked as reserved (and possibly removed from the physmap for
> HVM guests?), and the IOMMU mappings again identity mapped, so the
> device can talk to the BIOS.  Having the device talk to an
> equally-positioned RMRR in the guest address space seems pointless. 

I at least meant to say exactly that. Except that I implied that _all_
RMRR specified regions should be marked reserved (and "holes"
punched _and_ enforced to remain holes in the physmap), since
otherwise you can't hotplug such a device. (Of course we could
consider the alternative of not allowing hotplug of devices listed
underneath some RMRR, or not allowing assignment of such
devices at all.)

> One way or another, the security when passing through devices covered by
> RMRR would end up being reduced.

If multiple devices share a region, and they're being assigned to
different guests (with Dom0 counted as guest) - yes. But if such
a group was assigned collectively, I don't think security would be
reduced.

Jan


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