> From: Michael S. Tsirkin <[email protected]>
> Sent: Thursday, July 6, 2023 2:06 PM
>
> But again even if you add it there, you can not claim it's exactly the same as
> legacy because the address is different, the address type is different, the
> driver
> is different (this is owner driver) and even the device is different.
>
You drafted below, that I included,
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified.
We extend this further by saying Queue notify notifications is sent via MMIO as,
The driver of the owner device can send a driver notification to the member
device by executing VIRTIO_ADMIN_CMD_LEGACY_COMMON_CFG_WRITE with the
\field{offset} matching \field{Queue Notify} and the \field{data} containing
the virtqueue index to be notified or by performing memory or I/O write in
the any of the notification region at offset 0 supplied by the device in
VIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO result.
> Please also call out the unusual configuration where the type is "member" and
> then you have the owner driver access the memory of the member device.
> People might be confused.
>
> I also think we should explain that order of entries is a hint to driver: use
> the 1st
> entry that you can.
Driver really can choose any valid entry out of the 4 that driver likes.
I really don't see a need for overwriting this area as I fail to see why one
will expose multiple entries from the device side in reality.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
