> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker@xxxxxxx] > Sent: Wednesday, September 6, 2017 7:49 PM > > > > 2.6.8.2.1 > > Multiple overlapping RESV_MEM properties are merged together. Device > > requirement? if same types I assume? > > Combination rules apply to device and driver. When the driver puts > multiple endpoints in the same domain, combination rules apply. They will > become important once the guest attempts to do things like combining > endpoints with different PASID capabilities in the same domain. I'm > considering these endpoints to be behind different physical IOMMUs. > > For reserved regions, we specify what the driver should do and what the > device should enforce with regard to mapping IOVAs of overlapping regions. > For example, if a device has some virtual address RESV_T_MSI and an other > device has the same virtual address RESV_T_IDENTITY, what should the > driver do? > > I think it should apply the RESV_T_IDENTITY. RESV_T_MSI is just a special > case of RESV_T_RESERVED, it's a hint for the IRQ subsystem and doesn't > have a meaning within a domain. From DMA mappings point of view, it is > effectively the same as RESV_T_RESERVED. When merging > RESV_T_RESERVED and > RESV_T_IDENTITY, we should make it RESV_T_IDENTITY. Because it is > required > for one endpoint to work (the one with IDENTITY) and is not accessed by > the other (the driver must not allocate this IOVA range for DMA). > > More generally, I'd like to add the following combination table to the > spec, that shows the resulting reserved region type after merging regions > from two endpoints. N: no reserved region, R: RESV_T_RESERVED, M: > RESV_T_MSI, I: RESV_T_IDENTITY. It is symmetric so I didn't fill the > bottom half. > > | N | R | M | I > ------------------ > N | N | R | M | ? > ------------------ > R | | R | R | I > ------------------ > M | | | M | I > ------------------ > I | | | | I > > The 'I' column is problematic. If one endpoint has an IDENTITY region and > the other doesn't have anything at that virtual address, then making that > region an identity mapping will result in the second endpoint being able > to access firmware memory. If using nested translation, stage-2 can help > us here. But in general we should allow the device to reject an attach > that would result in a N+I combination if the host considers it too dodgy. > I think the other combinations are safe enough. > will overlap happen in real? Can we simplify the spec to have device not reporting overlapping regions? Thanks Kevin
