> From: Jean-Philippe Brucker > Sent: Wednesday, February 7, 2018 2:11 AM > > Please find version 0.6 of the virtio-iommu specification at the following > locations. > > Document: http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.pdf > http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.html > > Sources: git://linux-arm.org/virtio-iommu.git viommu/v0.6 > > I didn't receive any comment for v0.5 [1], so this update is fairly light: > * Changed range definition in map and unmap requests > * Use virtio-iommu device ID > * Update IORT node ID and simplify layout > > The following document shows the difference between v0.5 and v0.6: > http://jpbrucker.net/virtio-iommu/spec/diffs/virtio-iommu-pdf-diff-v0.5- > v0.6.pdf > > Next version will hopefully add vSVA (PASID+PRI) and/or architectural > optimizations, but I can't provide a timeline yet. I'll probably send a > small draft first. > > I will send the Linux driver soon. In the meantime you can fetch it on my > development branches, based on next-20180206. > > git://linux-arm.org/linux-jpb.git virtio-iommu/devel > git://linux-arm.org/kvmtool-jpb.git virtio-iommu/devel > > Any comments welcome! > > Thanks, > Jean > > [1] https://www.spinics.net/lists/kvm/msg157402.html some comments here: -- BYPASS feature bit is not covered in "2.3.1/2.3.2/2.3.3"". Is it intended? --2.6.2 Device Requirements: Device operations-- "If the VIRTIO_IOMMU_F_INPUT_RANGE feature is offered, the device MUST truncate the range described by virt_start and virt_end in requests to ft in the range described by input_range." "If the VIRTIO_IOMMU_F_DOMAIN_BITS is offered, the device MUST ignore bits above domain_bits in field domain of requests." shouldn't device return error upon above situation instead of continuing operation with modified value? --2.6.4 DETACH request-- " Detach an endpoint from its domain. When this request completes, the endpoint cannot access any mapping from that domain anymore " Does it make sense to mention BYPASS situation upon this request? --2.6.8.2 Property RESV_MEM -- "VIRTIO_IOMMU_RESV_MEM_T_RESERVED (0) Accesses to virtual addresses in this region are not translated by the device. They may either be aborted by the device (or the underlying IOMMU), bypass it, or never even reach it" in 3.3 hardware device assignment you described an example that a reserved range is stolen by host to map the MSI doorbell... such map behavior is not described above. Then comes a question for VIRTIO_IOMMU_RESV_MEM_T_MSI. I know there were quite some discussion around this flag before, but my mental picture now still is a bit difficult to understand its usage based on examples in implementation notes: - for x86, you describe it as indicating MSI bypass for oxfeexxxxx. However guest doesn't need to know this fact. Only requirement is to treat it as reserved range (as on bare metal) then T_RESERVED is sufficient for this purpose - for ARM, either let guest or let host to choose a virtual address for mapping to MSI doorbell. the former doesn't require a reserved range. for the latter also T_RESERVED is enough as the example in hardware device assignment section. Then what's the real point of differentiating MSI bypass from normal reserved range? Is there other example where guest may use such info to do special thing? -- 3.2 Message Signaled Interrupts -- " Section 3.2.2 describes the added complexity (from the host point of view) of translating the IRQ chip doorbell " however later 3.2.2 only says one sentence about host complexity - " However, this mode of operations may add significant complexity in the host implementation". If you plan to elaborate that part in the future, please add a note. :-) Thanks Kevin _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
