On 2020-04-28 00:24, Tony Krowiak wrote:
On 4/27/20 4:20 AM, Pierre Morel wrote:
On 2020-04-07 21:20, Tony Krowiak wrote:
Introduces a new driver callback to prevent a root user from unbinding
an AP queue from its device driver if the queue is in use. The intent of
this callback is to provide a driver with the means to prevent a root
user
from inadvertently taking a queue away from a guest and giving it to the
host while the guest is still using it.
...snip...
This functionality is valid for the host as for the guests and is
handled automatically by the firmware with the CRYCB.
The AP bus uses QCI to retrieve the host CRYCB and build the hosts AP
queues.
If instead to mix VFIO CRYCB matrix handling and queues at the same
level inside the AP bus we separate these different firmware entities
in two different software entities.
If we make the AP bus sit above a CRYCB/Matrix bus, and in the way
virtualize the QCI and test AP queue instructions:
- we can directly pass a matrix device to the guest though a VFIO
matrix device
- the consistence will be automatic
- the VFIO device and parent device will be of the same kind which
would make the design much more clearer.
- there will be no need for these callback because the consistence of
the matrix will be guaranteed by firmware
As stated in my response above, the issue here is not consistency. While
the design you describe
may be reasonable, it is a major departure from what is out in the
field. In other words, that ship
has sailed.
The current VFIO-AP driver works as before, without any change, above
the Matrix device I suggest.
Aside the old scheme which can continue, the Matrix device can be used
directly to build a VFIO Matrix device, usable by QEMU without any
modification.
Once the dynamic extensions proposed in this series and the associated
tools are out on the field, then yes the ship is really far.
For now, the existing user's API do not change, the existing tools do
not need modifications and we can repair the ship for its long journey.
The inconsistency between device and VFIO device and the resulting
complexity is not going to ease future enhancement.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
