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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jun 07, 2018 at 11:24:55AM +0100, Stefan Hajnoczi wrote:
> 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.

FWIW, add ability to use websockets protocol over chardevs is fairly
easy. We already have a QIOChannelWebsock for the VNC server, so it
is just a little work to wire it into the chardev.

If the -monitor / -qmp arg took a filename containing a whitelist of
allowed monitor commands, you could indeed use the regular QMP monitor
instead of writing something new.

> 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 :-).

FWIW, you could  use the "-sandbox spawn=off,elevateprivileges=off"
arg to prevent ability of QEMU to fork/exec/setuid. Even if the
monitor still allows it, it thus get blocked, albeit by immediately
terminating the process.

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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|