Re: [RFC 2/3] virtio-iommu: device probing and operations
On 22/08/17 07:24, Tian, Kevin wrote: >>> (sorry to pick up this old thread, as the .tex one is not good for review >>> and this thread provides necessary background for IOASID). >>> >>> Hi, Jean, >>> >>> I'd like to hear more clarification regarding the relationship between >>> IOASID and PASID. When reading back above explanation, it looks >>> confusing to me now (though I might get the meaning months ago :/). >>> At least Intel VT-d only understands PASID (or you can think IOASID >>> =PASID). There is no such layered address space concept. Then for >>> map/unmap type request, do you intend to steal some PASIDs for >>> that purpose on such architecture (since IOASID is a mandatory field >>> in map/unmap request)? >> >> IOASID is a logical ID, it isn't used by hardware. The address space >> concept in virtio-iommu allows to group endpoints together, so that they >> have the same address space. I thought it was pretty much the same as >> "domains" in VT-d? In any case, it is the same as domains in Linux. An >> IOASID provides a handle for communication between virtio-iommu device >> and >> driver, but unlike PASID, the IOASID number doesn't mean anything outside >> of virtio-iommu. > > Thanks. It's clear to me then. > > btw does it make more sense to use "domain id" instead of "IO address > space id"? For one, when talking about layered address spaces > usually parent address space is a superset of all child address spaces > which doesn't apply to this case, since either anonymous address > space or PASID-tagged address spaces are completely isolated. Instead> > 'domain' is a more inclusive terminology to embrace multiple address > spaces. For two, 'domain' is better aligned to software terminology (e.g. > iommu_domain) is easier for people to catch up. :-) I do agree that the naming isn't great. I didn't use "domain" for various reasons (it also has a different meanings in ARM) but I keep regretting it. As there is no virtio-iommu code upstream yet, it is still possible to change this one. I find that "address space" was a good fit for the baseline device, but the name doesn't scale. When introducing PASIDs, the address space moves one level down in the programming model. It is contexts, anonymous or PASID-tagged, that should be called address spaces. I was considering replacing it with "domain", "container", "partition"... Even though I don't want to use too much Linux terminology (virtio isn't just Linux), "domain" is better fitted, somewhat neutral, and gets the point across. A domain has one or more input address spaces and a single output address space. When introducing nested translation to virtio-iommu (for the guest to have virtual machines itself), there will be one or more intermediate address spaces. Domains will be nested, with the terminology "parent domain" and "child domain". I only briefly looked at a programming model for this but I think we can nest virtio-iommus without much hassle. If there is no objection the next version will use "domain" in place of "address_space". The change is quite invasive at this point, but I believe that it will makes things more clear down the road. >> I haven't introduced PASIDs in public virtio-iommu documents yet, but the >> way I intend it, PASID != IOASID. We will still have a logical address >> space identified by IOASID, that can contain multiple contexts identified >> by PASID. At the moment, after the ATTACH request, an address space >> contains a single anonymous context (NO PASID) that can be managed with >> MAP/UNMAP requests. With virtio-iommu v0.4, structures look like the >> following. The NO PASID context is implicit. >> >> address space context >> endpoint . .- mapping >> endpoint + IOASID NO PASID +- mapping >> endpoint ' '- mapping >> >> I'd like to add a flag to ATTACH that says "don't create a default >> anonymous context, I'll handle contexts myself". Then a new "ADD_TABLE" >> request to handle contexts. When creating a context, the guest decides if >> it wants to manage it via MAP/UNMAP requests (and a new "context" field), >> or instead manage mappings itself by allocating a page directory and use >> INVALIDATE requests. >> >> address space context >> endpoint . .- mapping >> endpoint + IOASID +--- NO PASID +- mapping >> endpoint '| '- mapping >> +--- PASID 0 pgd >> | ... >> '--- PASID N pgd >> >> In this example the guest chose to still have an anonymous context that >> uses MAP/UNMAP, along with a few PASID contexts with their own page >> tables. >> > > Above explanation is a good background. Is it useful to include it > in current spec? Though SVM
RE: [RFC 2/3] virtio-iommu: device probing and operations
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Monday, August 21, 2017 8:00 PM
>
> On 21/08/17 08:59, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> >> Sent: Monday, April 24, 2017 11:06 PM
> >> 1. Attach device
> >>
> >>
> >> struct virtio_iommu_req_attach {
> >>le32address_space;
> >>le32device;
> >>le32flags/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...
>
> I think it's simpler if we keep a single IOASID space per virtio-iommu
> device, because the maximum number of address spaces (described
> by
> ioasid_bits) might be a restriction of the pIOMMU. For page-table
> >> sharing
> you still need to define which devices will share a page directory using
> ATTACH requests, though that interface is not set in stone.
> >>>
> >>> got you. yes VM is supposed to consume less IOASIDs than physically
> >>> available. It doesn’t hurt to have one IOASID space for both IOVA
> >>> map/unmap usages (one IOASID per device) and SVM usages (multiple
> >>> IOASIDs per device). The former is digested by software and the latter
> >>> will be bound to hardware.
> >>>
> >>
> >> Hmm, I'm using address space indexed by IOASID for "classic" IOMMU,
> and
> >> then contexts indexed by PASID when talking about SVM. So in my mind
> an
> >> address space can have multiple sub-address-spaces (contexts). Number
> of
> >> IOASIDs is a limitation of the pIOMMU, and number of PASIDs is a
> >> limitation of the device. Therefore attaching devices to address spaces
> >> would update the number of available contexts in that address space.
> The
> >> terminology is not ideal, and I'd be happy to change it for something
> more
> >> clear.
> >>
> >
> > (sorry to pick up this old thread, as the .tex one is not good for review
> > and this thread provides necessary background for IOASID).
> >
> > Hi, Jean,
> >
> > I'd like to hear more clarification regarding the relationship between
> > IOASID and PASID. When reading back above explanation, it looks
> > confusing to me now (though I might get the meaning months ago :/).
> > At least Intel VT-d only understands PASID (or you can think IOASID
> > =PASID). There is no such layered address space concept. Then for
> > map/unmap type request, do you intend to steal some PASIDs for
> > that purpose on such architecture (since IOASID is a mandatory field
> > in map/unmap request)?
>
> IOASID is a logical ID, it isn't used by hardware. The address space
> concept in virtio-iommu allows to group endpoints together, so that they
> have the same address space. I thought it was pretty much the same as
> "domains" in VT-d? In any case, it is the same as domains in Linux. An
> IOASID provides a handle for communication between virtio-iommu device
> and
> driver, but unlike PASID, the IOASID number doesn't mean anything outside
> of virtio-iommu.
Thanks. It's clear to me then.
btw does it make more sense to use "domain id" instead of "IO address
space id"? For one, when talking about layered address spaces
usually parent address space is a superset of all child address spaces
which doesn't apply to this case, since either anonymous address
space or PASID-tagged address spaces are completely isolated. Instead
'domain' is a more inclusive terminology to embrace multiple address
spaces. For two, 'domain' is better aligned to software terminology (e.g.
iommu_domain) is easier for people to catch up. :-)
>
> I haven't introduced PASIDs in public virtio-iommu documents yet, but the
> way I intend it, PASID != IOASID. We will still have a logical address
> space identified by IOASID, that can contain multiple contexts identified
> by PASID. At the moment, after the ATTACH request, an address space
> contains a single anonymous context (NO PASID) that can be managed with
> MAP/UNMAP requests. With virtio-iommu v0.4, structures look like the
> following. The NO PASID context is implicit.
>
> address space context
> endpoint . .- mapping
> endpoint + IOASID NO PASID +- mapping
> endpoint ' '- mapping
>
> I'd like to add a flag to ATTACH that says "don't create a default
> anonymous context, I'll handle contexts myself". Then a new "ADD_TABLE"
> request to handle contexts. When creating a context, the guest decides if
> it wants to manage it via MAP/UNMAP requests (and a new "context" field),
> or instead manage mappings itself by allocating a page directory and use
> INVALIDATE requests.
>
Re: [RFC 2/3] virtio-iommu: device probing and operations
On 21/08/17 08:59, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
>> Sent: Monday, April 24, 2017 11:06 PM
>> 1. Attach device
>>
>>
>> struct virtio_iommu_req_attach {
>> le32address_space;
>> le32device;
>> le32flags/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...
I think it's simpler if we keep a single IOASID space per virtio-iommu
device, because the maximum number of address spaces (described by
ioasid_bits) might be a restriction of the pIOMMU. For page-table
>> sharing
you still need to define which devices will share a page directory using
ATTACH requests, though that interface is not set in stone.
>>>
>>> got you. yes VM is supposed to consume less IOASIDs than physically
>>> available. It doesn’t hurt to have one IOASID space for both IOVA
>>> map/unmap usages (one IOASID per device) and SVM usages (multiple
>>> IOASIDs per device). The former is digested by software and the latter
>>> will be bound to hardware.
>>>
>>
>> Hmm, I'm using address space indexed by IOASID for "classic" IOMMU, and
>> then contexts indexed by PASID when talking about SVM. So in my mind an
>> address space can have multiple sub-address-spaces (contexts). Number of
>> IOASIDs is a limitation of the pIOMMU, and number of PASIDs is a
>> limitation of the device. Therefore attaching devices to address spaces
>> would update the number of available contexts in that address space. The
>> terminology is not ideal, and I'd be happy to change it for something more
>> clear.
>>
>
> (sorry to pick up this old thread, as the .tex one is not good for review
> and this thread provides necessary background for IOASID).
>
> Hi, Jean,
>
> I'd like to hear more clarification regarding the relationship between
> IOASID and PASID. When reading back above explanation, it looks
> confusing to me now (though I might get the meaning months ago :/).
> At least Intel VT-d only understands PASID (or you can think IOASID
> =PASID). There is no such layered address space concept. Then for
> map/unmap type request, do you intend to steal some PASIDs for
> that purpose on such architecture (since IOASID is a mandatory field
> in map/unmap request)?
IOASID is a logical ID, it isn't used by hardware. The address space
concept in virtio-iommu allows to group endpoints together, so that they
have the same address space. I thought it was pretty much the same as
"domains" in VT-d? In any case, it is the same as domains in Linux. An
IOASID provides a handle for communication between virtio-iommu device and
driver, but unlike PASID, the IOASID number doesn't mean anything outside
of virtio-iommu.
I haven't introduced PASIDs in public virtio-iommu documents yet, but the
way I intend it, PASID != IOASID. We will still have a logical address
space identified by IOASID, that can contain multiple contexts identified
by PASID. At the moment, after the ATTACH request, an address space
contains a single anonymous context (NO PASID) that can be managed with
MAP/UNMAP requests. With virtio-iommu v0.4, structures look like the
following. The NO PASID context is implicit.
address space context
endpoint . .- mapping
endpoint + IOASID NO PASID +- mapping
endpoint ' '- mapping
I'd like to add a flag to ATTACH that says "don't create a default
anonymous context, I'll handle contexts myself". Then a new "ADD_TABLE"
request to handle contexts. When creating a context, the guest decides if
it wants to manage it via MAP/UNMAP requests (and a new "context" field),
or instead manage mappings itself by allocating a page directory and use
INVALIDATE requests.
address space context
endpoint . .- mapping
endpoint + IOASID +--- NO PASID +- mapping
endpoint '| '- mapping
+--- PASID 0 pgd
| ...
'--- PASID N pgd
In this example the guest chose to still have an anonymous context that
uses MAP/UNMAP, along with a few PASID contexts with their own page tables.
Thanks,
Jean
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 2/3] virtio-iommu: device probing and operations
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Monday, April 24, 2017 11:06 PM
> 1. Attach device
>
>
> struct virtio_iommu_req_attach {
> le32address_space;
> le32device;
> le32flags/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...
> >>
> >> I think it's simpler if we keep a single IOASID space per virtio-iommu
> >> device, because the maximum number of address spaces (described by
> >> ioasid_bits) might be a restriction of the pIOMMU. For page-table
> sharing
> >> you still need to define which devices will share a page directory using
> >> ATTACH requests, though that interface is not set in stone.
> >
> > got you. yes VM is supposed to consume less IOASIDs than physically
> > available. It doesn’t hurt to have one IOASID space for both IOVA
> > map/unmap usages (one IOASID per device) and SVM usages (multiple
> > IOASIDs per device). The former is digested by software and the latter
> > will be bound to hardware.
> >
>
> Hmm, I'm using address space indexed by IOASID for "classic" IOMMU, and
> then contexts indexed by PASID when talking about SVM. So in my mind an
> address space can have multiple sub-address-spaces (contexts). Number of
> IOASIDs is a limitation of the pIOMMU, and number of PASIDs is a
> limitation of the device. Therefore attaching devices to address spaces
> would update the number of available contexts in that address space. The
> terminology is not ideal, and I'd be happy to change it for something more
> clear.
>
(sorry to pick up this old thread, as the .tex one is not good for review
and this thread provides necessary background for IOASID).
Hi, Jean,
I'd like to hear more clarification regarding the relationship between
IOASID and PASID. When reading back above explanation, it looks
confusing to me now (though I might get the meaning months ago :/).
At least Intel VT-d only understands PASID (or you can think IOASID
=PASID). There is no such layered address space concept. Then for
map/unmap type request, do you intend to steal some PASIDs for
that purpose on such architecture (since IOASID is a mandatory field
in map/unmap request)?
Thanks
Kevin
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 2/3] virtio-iommu: device probing and operations
On 21/04/17 10:02, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
>> Sent: Wednesday, April 19, 2017 2:46 AM
>>
>> On 18/04/17 11:26, Tian, Kevin wrote:
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)?
>>
>> A start address would allow to provide something resembling a GART to the
>> guest: an IOMMU with one address space (ioasid_bits=0) and a small IOVA
>> aperture. I'm not sure how useful that would be in practice.
>
> Intel VT-d has no such limitation, which I can tell. :-)
>
>>
>> On a related note, the virtio-iommu itself doesn't provide a
>> per-address-space aperture as it stands. For example, attaching a device
>> to an address space might restrict the available IOVA range for the whole
>> AS if that device cannot write to high memory (above 32-bit). If the guest
>> attempts to map an IOVA outside this window into the device's address
>> space, it should expect the MAP request to fail. And when attaching, if
>> the address space already has mappings outside this window, then ATTACH
>> should fail.
>>
>> This too seems to be something that ought to be communicated by firmware,
>> but bits are missing (I can't find anything equivalent to DT's dma-ranges
>> for PCI root bridges in ACPI tables, for example). In addition VFIO
>> doesn't communicate any DMA mask for devices, and doesn't check them
>> itself. I guess that the host could find out the DMA mask of devices one
>> way or another, but it is tricky to enforce, so I didn't make this a hard
>> requirement. Although I should probably add a few words about it.
>
> If there is no such communication on bare metal, then same for pvIOMMU.
>
>>
>>> [...]
1. Attach device
struct virtio_iommu_req_attach {
le32address_space;
le32device;
le32flags/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...
>>
>> I think it's simpler if we keep a single IOASID space per virtio-iommu
>> device, because the maximum number of address spaces (described by
>> ioasid_bits) might be a restriction of the pIOMMU. For page-table sharing
>> you still need to define which devices will share a page directory using
>> ATTACH requests, though that interface is not set in stone.
>
> got you. yes VM is supposed to consume less IOASIDs than physically
> available. It doesn’t hurt to have one IOASID space for both IOVA
> map/unmap usages (one IOASID per device) and SVM usages (multiple
> IOASIDs per device). The former is digested by software and the latter
> will be bound to hardware.
>
Hmm, I'm using address space indexed by IOASID for "classic" IOMMU, and
then contexts indexed by PASID when talking about SVM. So in my mind an
address space can have multiple sub-address-spaces (contexts). Number of
IOASIDs is a limitation of the pIOMMU, and number of PASIDs is a
limitation of the device. Therefore attaching devices to address spaces
would update the number of available contexts in that address space. The
terminology is not ideal, and I'd be happy to change it for something more
clear.
Thanks,
Jean-Philippe
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 2/3] virtio-iommu: device probing and operations
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Wednesday, April 19, 2017 2:46 AM
>
> On 18/04/17 11:26, Tian, Kevin wrote:
> >> 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)?
>
> A start address would allow to provide something resembling a GART to the
> guest: an IOMMU with one address space (ioasid_bits=0) and a small IOVA
> aperture. I'm not sure how useful that would be in practice.
Intel VT-d has no such limitation, which I can tell. :-)
>
> On a related note, the virtio-iommu itself doesn't provide a
> per-address-space aperture as it stands. For example, attaching a device
> to an address space might restrict the available IOVA range for the whole
> AS if that device cannot write to high memory (above 32-bit). If the guest
> attempts to map an IOVA outside this window into the device's address
> space, it should expect the MAP request to fail. And when attaching, if
> the address space already has mappings outside this window, then ATTACH
> should fail.
>
> This too seems to be something that ought to be communicated by firmware,
> but bits are missing (I can't find anything equivalent to DT's dma-ranges
> for PCI root bridges in ACPI tables, for example). In addition VFIO
> doesn't communicate any DMA mask for devices, and doesn't check them
> itself. I guess that the host could find out the DMA mask of devices one
> way or another, but it is tricky to enforce, so I didn't make this a hard
> requirement. Although I should probably add a few words about it.
If there is no such communication on bare metal, then same for pvIOMMU.
>
> > [...]
> >> 1. Attach device
> >>
> >>
> >> struct virtio_iommu_req_attach {
> >>le32address_space;
> >>le32device;
> >>le32flags/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...
>
> I think it's simpler if we keep a single IOASID space per virtio-iommu
> device, because the maximum number of address spaces (described by
> ioasid_bits) might be a restriction of the pIOMMU. For page-table sharing
> you still need to define which devices will share a page directory using
> ATTACH requests, though that interface is not set in stone.
got you. yes VM is supposed to consume less IOASIDs than physically
available. It doesn’t hurt to have one IOASID space for both IOVA
map/unmap usages (one IOASID per device) and SVM usages (multiple
IOASIDs per device). The former is digested by software and the latter
will be bound to hardware.
Thanks
Kevin
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 2/3] virtio-iommu: device probing and operations
On 18/04/17 11:26, Tian, Kevin wrote:
>> 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)?
A start address would allow to provide something resembling a GART to the
guest: an IOMMU with one address space (ioasid_bits=0) and a small IOVA
aperture. I'm not sure how useful that would be in practice.
On a related note, the virtio-iommu itself doesn't provide a
per-address-space aperture as it stands. For example, attaching a device
to an address space might restrict the available IOVA range for the whole
AS if that device cannot write to high memory (above 32-bit). If the guest
attempts to map an IOVA outside this window into the device's address
space, it should expect the MAP request to fail. And when attaching, if
the address space already has mappings outside this window, then ATTACH
should fail.
This too seems to be something that ought to be communicated by firmware,
but bits are missing (I can't find anything equivalent to DT's dma-ranges
for PCI root bridges in ACPI tables, for example). In addition VFIO
doesn't communicate any DMA mask for devices, and doesn't check them
itself. I guess that the host could find out the DMA mask of devices one
way or another, but it is tricky to enforce, so I didn't make this a hard
requirement. Although I should probably add a few words about it.
> [...]
>> 1. Attach device
>>
>>
>> struct virtio_iommu_req_attach {
>> le32address_space;
>> le32device;
>> le32flags/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...
I think it's simpler if we keep a single IOASID space per virtio-iommu
device, because the maximum number of address spaces (described by
ioasid_bits) might be a restriction of the pIOMMU. For page-table sharing
you still need to define which devices will share a page directory using
ATTACH requests, though that interface is not set in stone.
>> 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"
Indeed
Thanks!
Jean-Philippe
>> isolated by the host have the same address spaces.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC 2/3] virtio-iommu: device probing and operations
> 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 {
> le32address_space;
> le32device;
> le32flags/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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
