Re: [Qemu-devel] [RFC v3] qapi: command category to stimulate high-level machine devices

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]

On Mon, Jun 04, 2018 at 12:12:21PM +0200, Gerd Hoffmann wrote:
> On Mon, Jun 04, 2018 at 10:29:40AM +0100, Peter Maydell wrote:
> > On 4 June 2018 at 10:20, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > > Many of these inputs/outputs can be tied to an external UI.  A degree of
> > > timing precision is required so that the UI is responsive, although
> > > cycle-accurate timing is not what I'd expect from QMP.
> > 
> > Would we also be able to tie them to an internal UI, ie
> > something that appears as another view in the GTK/etc
> > UI frontends we have?
> 
> Should be doable too.  Basically a display device, which isn't a *real*
> display but the UI.  Could show a rendering of the board, simliar to how
> web emulation environments are doing it.  LED status could be rendered
> directly to the board.  A virtual mouse could map mouse clicks to button
> presses.
> 
> Doing more complex input that way (say a slider for the temperature
> sensor) isn't going to work very well though ...
> 
> Sensor input in general is pretty much unsupported in qemu.

For the micro:bit we've been thinking of a WebSocket monitor interface.
This way a web UI can work with both local and remote QEMU instances.

For security reasons, the WebSocket cannot be the regular QMP monitor.
A slimmed down monitor is required with a subset of QMP commands and
events.  For example, users must not be able to migrate to an exec:
destination so we need to ban that command on the UI monitor :-).

Pros:
 + Remote control is possible over sockets
   (Important for hosting QEMU on a server.  Nowadays this is becoming a
   popular way to deliver emulation to users.  They don't need to
   install software locally.)
 + UI is cleanly isolated from QEMU process
Cons:
 - Binary or high-frequency I/O is a bad fit for a JSON WebSocket
   interface

I prefer the WebSocket route over creating a fake display that will not
be able to implement complex widgets well.

Gerd: What is your preference?  Do you want board-specific fake displays
inside the QEMU process as the long-term direction for UIs?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]