[virtio-dev] Re: [PATCH] virtio-transport: Clarify requirements

Cornelia Huck <[email protected]> writes:

> On Wed, Dec 06 2023, Viresh Kumar <[email protected]> wrote:
>
>> On 05-12-23, 14:18, Cornelia Huck wrote:
>>> On Tue, Dec 05 2023, Viresh Kumar <[email protected]> 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?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]