[RFC 2/3] virtio-iommu: device probing and operations

Tian, Kevin
2017-04-18T10:26:41Z

> From: Jean-Philippe Brucker
> Sent: Saturday, April 8, 2017 3:18 AM
>
[...]
>   II. Feature bits
>   ===============>
> VIRTIO_IOMMU_F_INPUT_RANGE (0)
>  Available range of virtual addresses is described in input_range

Usually only the maximum supported address bits are important.
Curious do you see such situation where low end of the address
space is not usable (since you have both start/end defined later)?

[...]
>   1. Attach device
>   ----------------
>
> struct virtio_iommu_req_attach {
> 	le32	address_space;
> 	le32	device;
> 	le32	flags/reserved;
> };
>
> Attach a device to an address space. 'address_space' is an
identifier
> unique to the guest. If the address space doesn't exist in the IOMMU

Based on your description this address space ID is per operation right?
MAP/UNMAP and page-table sharing should have different ID spaces...

> device, it is created. 'device' is an identifier unique to the
IOMMU. The
> host communicates unique device ID to the guest during boot. The method
> used to communicate this ID is outside the scope of this specification,
> but the following rules must apply:
>
> * The device ID is unique from the IOMMU point of view. Multiple devices
>   whose DMA transactions are not translated by the same IOMMU may have
> the
>   same device ID. Devices whose DMA transactions may be translated by the
>   same IOMMU must have different device IDs.
>
> * Sometimes the host cannot completely isolate two devices from each
>   others. For example on a legacy PCI bus, devices can snoop DMA
>   transactions from their neighbours. In this case, the host must
>   communicate to the guest that it cannot isolate these devices from each
>   others. The method used to communicate this is outside the scope of this
>   specification. The IOMMU device must ensure that devices that cannot be

"IOMMU device" -> "IOMMU driver"

>   isolated by the host have the same address spaces.
>

Thanks
Kevin