在 2021/6/1 下午1:42, Tian, Kevin 写道:
From: Jason Wang
Sent: Tuesday, June 1, 2021 1:30 PM
在 2021/6/1 下午1:23, Lu Baolu 写道:
Hi Jason W,
On 6/1/21 1:08 PM, Jason Wang wrote:
2) If yes, what's the reason for not simply use the fd opened from
/dev/ioas. (This is the question that is not answered) and what
happens
if we call GET_INFO for the ioasid_fd?
3) If not, how GET_INFO work?
oh, missed this question in prior reply. Personally, no special reason
yet. But using ID may give us opportunity to customize the management
of the handle. For one, better lookup efficiency by using xarray to
store the allocated IDs. For two, could categorize the allocated IDs
(parent or nested). GET_INFO just works with an input FD and an ID.
I'm not sure I get this, for nesting cases you can still make the
child an fd.
And a question still, under what case we need to create multiple
ioasids on a single ioasid fd?
One possible situation where multiple IOASIDs per FD could be used is
that devices with different underlying IOMMU capabilities are sharing a
single FD. In this case, only devices with consistent underlying IOMMU
capabilities could be put in an IOASID and multiple IOASIDs per FD could
be applied.
Though, I still not sure about "multiple IOASID per-FD" vs "multiple
IOASID FDs" for such case.
Right, that's exactly my question. The latter seems much more easier to
be understood and implemented.
A simple reason discussed in previous thread - there could be 1M's
I/O address spaces per device while #FD's are precious resource.
Is the concern for ulimit or performance? Note that we had
#define NR_OPEN_MAX ~0U
And with the fd semantic, you can do a lot of other stuffs: close on
exec, passing via SCM_RIGHTS.
For the case of 1M, I would like to know what's the use case for a
single process to handle 1M+ address spaces?
So this RFC treats fd as a container of address spaces which is each
tagged by an IOASID.
If the container and address space is 1:1 then the container seems useless.
Thanks
Thanks
Kevin
