OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]