Open Stack

On Thu, 2020-11-12 at 17:09 -0800, melanie witt wrote:
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.

Not quite. libvirt on x86 will automatically add a PS2 mouse and
keyboard (even if you request something else) because that's what QEMU
does. On all other platforms (to the best of my knowledge, based on
Kashyap quizzing a handful of multi-arch libvirt devs), this must be
done manually. We currently only do this for AArch64, through the non-
configurable addition of a USB keyboard [1]. There is currently no way
to request e.g. a USB or virtio keyboard on any architecture.

[1] https://github.com/openstack/nova/commit/b92e3bc95fd

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?

My concerns are twofold. Firstly, having the value of
'hw_pointer_model' influence the keyboard bus is poor UX, since this
"feature" is not at all apparent from the property name. Secondly,
'hw_pointer_model' is a poorly designed property, given it configured
the bus as well as the model, munging the two.

To be clear, I agree that having different buses for keyboard and
pointer makes no sense. There's no reason they shouldn't be the same.
I'm just saying that configuring the bus for input devices via an
appropriately named 'hw_input_bus' image metadata property makes much
more sense that maybe getting one configured magically based on the
"pointer model" in use.

>From what I understand, the pointer is the only user selection we can guarantee and the keyboard is architecture dependent.

Again, not really. There isn't an analog for pointer vs. mouse when it
comes to keyboards. The keyboard isn't architecture dependent. What is
architecture dependent is whether you get a keyboard and mouse by
default (yes on x86, in the form of a PS2 mouse and keyboard, and no
for everyone else).

> 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
> than hw_pointer_model?

They can choose the _bus_ that the keyboard uses. There's an assumption
here that if you request a graphics device (VNC, SPICE, ...) then you
will get a keyboard and tablet input devices, because that graphics
device is unusable otherwise. There is also an assumption (based on
dansmith's comments about mouse being only used for legacy compat
reasons) that the user will never want to explicitly request a 'mouse'
pointer model and should therefore get 'tablet' by default. Based on
these two assumptions, the only thing remaining is to decide how the
keyboard and tablet devices will be attached to the guest...achieved
via a sensibly named 'hw_input_bus' image metadata property. That seems
reasonable to me.

Stephen

Best,
-melanie

> 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 [1].
> 
> Cheers,
> Stephen
> 
> [1] https://review.opendev.org/#/c/756552/
> 
>