[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [RFC v3] qapi: command category to stimulate high-level m
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-arm] [RFC v3] qapi: command category to stimulate high-level machine devices |
Date: |
Thu, 7 Jun 2018 11:24:55 +0100 |
User-agent: |
Mutt/1.9.5 (2018-04-13) |
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 <address@hidden> 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
signature.asc
Description: PGP signature
Re: [Qemu-arm] [RFC v3] qapi: command category to stimulate high-level machine devices, Gerd Hoffmann, 2018/06/04