RE: [virtio-dev] [RFC] virtio-iommu version 0.6

["Tian, Kevin" <kevin.tian@intel.com>]

> 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