Cornelia Huck cohuck@redhat.com writes:
On Wed, Dec 06 2023, Viresh Kumar viresh.kumar@linaro.org wrote:
On 05-12-23, 14:18, Cornelia Huck wrote:
On Tue, Dec 05 2023, Viresh Kumar viresh.kumar@linaro.org wrote:
<snip>
- The transport MUST provide a mechanism for the device and the driver to notify each other, for example about availability of a buffer on the virtqueue.
Probably a mechanism for the device to notify the driver, and a mechanism for the driver to notify the device? They can be different, as long both of them are present.
- The transport SHOULD provide a mechanism for the driver to initiate a reset of the virtqueues and device.
Can we mandate a mechanism for a device reset? Reset of virtqueues needs to be optional, I'm not sure whether a SHOULD would be appropriate for that (or maybe we should finally come up with something for ccw ;)
Other things that probably should be mandatory:
- A way for the driver to change the device status. Reading it would probably be a strong SHOULD.
- A way to implement config space. (For example, channel devices don't have a config space or anything similar enough to repurpose, so I had to invent a mechanism for ccw... maybe future transports will be in the same boat.)
I think Bill has run into problems with config space on OpenAMP setups where there can be no specific trapping between domains making it hard to manage a config space where both sides might want to make updates. I guess the original MMIO transport gets away with it because config space is always in the trap-and-emulate address space in a normal VM/emulation situation.
Bill,
Is the plan to introduce a new transport that manages config in a different way?