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, 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

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.

I don't really understand what's the big deal about it, though...

> There're also other more sophisticated features like HW debounce,
> pinmux, etc, that are to come later - as *optional* features that some
> device may or may not support.
> Note that this isn't just about moving drivers into some VMM, but also
> about actual hardware.

... I do understand why you are so adamant on not changing this. And
lemme say this again for clarity.

We are not going to write a new protocol in a BUGGY way, because some
existing hardware implements it in a BROKEN way. You should have
upstreamed the specification before finalizing the hardware and make
sure such chicken and egg situations do not occur.


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