search for: resv_t_reserv

...d 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 wo...

...d 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 wo...

...ng 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 > requir...

...the host resv regions in case of VFIO EP. >> Typically the host PCIe host bridge windows cannot be used for IOVA. >> Also the host MSI reserved IOVA window cannot be used. Do you agree. > > Yes, all regions reported in sysfs reserved_regions in the host would be > reported as RESV_T_RESERVED by virtio-iommu. So to summarize if the probe request is sent to an emulated device, we should return the target specific MSI window. We can't and don't return the non IOMMU specific guest reserved windows. For a VFIO device, we would return all reserved regions of the group the device b...

...the host resv regions in case of VFIO EP. >> Typically the host PCIe host bridge windows cannot be used for IOVA. >> Also the host MSI reserved IOVA window cannot be used. Do you agree. > > Yes, all regions reported in sysfs reserved_regions in the host would be > reported as RESV_T_RESERVED by virtio-iommu. So to summarize if the probe request is sent to an emulated device, we should return the target specific MSI window. We can't and don't return the non IOMMU specific guest reserved windows. For a VFIO device, we would return all reserved regions of the group the device b...

...ather information about the host resv regions in case of VFIO EP. > Typically the host PCIe host bridge windows cannot be used for IOVA. > Also the host MSI reserved IOVA window cannot be used. Do you agree. Yes, all regions reported in sysfs reserved_regions in the host would be reported as RESV_T_RESERVED by virtio-iommu. > I really think the spec should clarify what exact resv regions the > device should return in case of VFIO device and non VFIO device. Agreed. I will add something about RESV_T_RESERVED with the PCI bridge example in Implementation Notes. Do you think the MSI examples at...

...ons in case of VFIO EP. >>> Typically the host PCIe host bridge windows cannot be used for IOVA. >>> Also the host MSI reserved IOVA window cannot be used. Do you agree. >> >> Yes, all regions reported in sysfs reserved_regions in the host would be >> reported as RESV_T_RESERVED by virtio-iommu. > So to summarize if the probe request is sent to an emulated device, we > should return the target specific MSI window. We can't and don't return > the non IOMMU specific guest reserved windows. > > For a VFIO device, we would return all reserved regions...

Hi jean, On 04/08/2017 20:19, Jean-Philippe Brucker wrote: > This is the continuation of my proposal for virtio-iommu, the para- > virtualized IOMMU. Here is a summary of the changes since last time [1]: > > * The virtio-iommu document now resembles an actual specification. It is > split into a formal description of the virtio device, and implementation > notes. Please find

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different