Re: [virtio-dev] Re: [virtio-comment] [PATCH v2] virtio-gpio: add formal specification

[Viresh Kumar <viresh.kumar@linaro.org>]

On 01-07-21, 22:21, Viresh Kumar wrote:
> On 01-07-21, 16:43, Enrico Weigelt, metux IT consult wrote:
> > On 01.07.21 11:01, Arnd Bergmann wrote:
> > 
> > > Agreed, interrupt support is obviously something that can not be
> > > retrofitted easily if you don't get it right from the start.
> > 
> > It's basically present, the basic version (as now writting in this spec)
> > just can't do hardware masking - that part is planned as an optional
> > feature (which I haven't yet put into that spec version, since I wanted
> > to get the basic version finished up before doing the optional
> > features).
> 
> Finally you called it interrupt :)
> 
> > Actually, the optional feature will just add another message for
> > mask/unmask. I'll yet having conversations w/ HW engineers on certain
> > aspects, e.g. automatic masking (yes/no/configurable ?).
> 
> An interrupt should never occur unless asked for. Here is an example
> of how this is BROKEN right now.
> 
> Lets say the host passes 32 gpio lines to guest, guest moves them in
> input mode (some user requested for them) and then frees the gpio
> lines.
> 
> At this point there are no users of the GPIO block in the guest OS,
> but the virtio traffic will continue for the interrupts, as the host
> will keep sending the GPIO status changes to the guest.
> 
> This is simply BROKEN and NOT acceptable.
> 
> If you want to implement interrupts, then add them in a separate
> feature or just don't. Partial implementations aren't going to work.

Will it be possible to move this stuff a bit faster? We are still where
we were in December last year. Not a lot has changed.

We have future work blocked because of this, Linux driver and generic Backend
implementation (and their users later on), etc.

We really need to move it forward.

Thanks.

-- 
viresh