[nova] How best to provide virtio-based input devices?
melwittt at gmail.com
Fri Nov 13 01:09:40 UTC 2020
On 11/12/20 11:03, Stephen Finucane wrote:
> Design discussion for interested parties. As discussed during the nova
> team meeting today, we're looking at providing support for virtio-based
> input devices in nova, given benefits w.r.t. performance and security
> (no emulated USB bus!). The current proposal I have for this is to
> introduce a new image metadata property, 'hw_input_bus', and extend the
> existing 'hw_pointer_model' image metadata property, which currently
> only accepts a 'usbtablet' value, to accept 'mouse' or 'tablet' values.
> This means you'd end up with a matrix something like so:
> | hw_pointer_model | hw_input_bus | Result |
> | - | - | PS2-based mouse [*] |
> | usbtablet | - | USB-based tablet |
> | usbtablet | usb | USB-based tablet |
> | usbtablet | virtio | **ERROR** |
> | mouse | - | USB-based mouse |
> | mouse | usb | USB-based mouse |
> | mouse | virtio | virtio-based mouse |
> | tablet | - | USB-based tablet |
> | tablet | usb | USB-based tablet |
> | tablet | virtio | virtio-based tablet |
> [*] libvirt adds these by default on x86 hosts
> dansmith noted that the only reason to select the 'mouse' pointer model
> nowadays is for compatibility, and something like a virtio-based mouse
> didn't really make sense. That being the case, I agree that this change
> is likely more complex that it needs to be.
+1, agree that having several user choices for pointer + bus that result
in invalid or nonsensical combinations would not be a positive UX.
> We do, however, disagree on
> the remedy. dansmith's idea is to drop the 'hw_input_bus' image
> metadata property entirely and simply add a new 'virtiotablet' value to
> 'hw_pointer_model' instead. This still leaves the question of what bus
> we should use for keyboards, and his suggestion there is to extrapolate
> out and use virtio for keyboards if 'hw_pointer_model=virtiotablet' is
> specified and presumably USB if 'hw_pointer_model=usbtablet'.
> Needless to say, I don't like this idea and prefer we took another tack
> and kept 'hw_input_bus' but didn't build on 'hw_pointer_model' and
> instead "deprecated" it. We can't really ever remove the an image
> metadata property, since that would be a breaking upgrade, which means
> we'll eventually be left with effectively dead code to maintain
> forever. However, I don't think that's a big deal.
> 'hw_pointer_model=usbtablet' is already on a path to obsolescence as
> the Q35 machine type slowly becomes the default on x86 hosts and the
> use of non-x86 hosts grows since neither support PS2 and must use a
> USB-based input device. In addition, I think the extrapolation of
> 'virtiotablet' to mean also virtio-based keyboard is unclear and leaves
> a gaping hole w.r.t. requesting USB-based keyboards on non-AArch64
> hosts (where it's currently added by default), since we don't currently
> do this extrapolation and introducing it would be breaking change on
> x86 hosts (instances would suddenly switch from PS2-based keyboards to
> USB-based ones).
If I understand correctly, we do choose the "best fit" keyboard based on
architecture, independent of the requested hw_pointer_model, today. It
feels like it would be simpler to continue doing that and add a virtio
choice to hw_pointer_model and let the driver pick the "best" keyboard
to go along with that. Is it your view that having the driver choose a
virtio keyboard if hw_pointer_model=virtiotablet is inconsistent with
the existing "best fit" keyboard selection behavior?
From what I understand, the pointer is the only user selection we can
guarantee and the keyboard is architecture dependent. If we "deprecated"
hw_pointer_model and introduced hw_input_bus, how does the user know
which thing (pointer or keyboard) they are specifying? If users can't
actually choose the keyboard and can only choose the pointer, wouldn't
presenting a selection of a generic "hw_input_bus" be more confusing
> We need to decide what approach to go for before I rework this. If
> anyone has input, particularly operators that think they'd use this
> feature, I'd love to hear it so that I can t̶e̶l̶l̶ ̶d̶a̶n̶s̶m̶i̶t̶h̶
> ̶t̶o̶ ̶s̶h̶o̶v̶e̶ ̶i̶t̶ come to the best possible solution ;-) Feel
> free to either reply here or on the review .
>  https://review.opendev.org/#/c/756552/
More information about the openstack-discuss