[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 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. 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. -- viresh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]