[Qemu-devel] QOM-ify QemuConsoles ...

[Qemu-devel] QOM-ify QemuConsoles ...

[Gerd Hoffmann]

  Hi,

So, the big qemu console data structure overhauls is done, patches just
posted to the list.

I think the next logical step ahead is to QOM-ify the QemuConsoles, so
we can link the QemuConsole to the thing actually backing it.  For a
graphical console that would be the emlated graphic device.  For a text
console it would be the serial line or monitor hooked up to it.

With this in place we should be able to answer questions like "which
device backs this QemuConsole" by inspecting the object tree and handle
requests like "do a screendump of this device please".  It will also be
useful to setup input routing: "pointer events from $this QemuConsole
should to $that virtual input device".

Hints how to do that best?  Pointers to sample code to look at?  From a
brief look it seems we only QOM-ified emulated devices and not host-side
objects yet ...

thanks,
  Gerd

Re: [Qemu-devel] QOM-ify QemuConsoles ...

[Andreas Färber]

Hi Gerd,

Am 20.03.2013 10:55, schrieb Gerd Hoffmann:
> I think the next logical step ahead is to QOM-ify the QemuConsoles, so
> we can link the QemuConsole to the thing actually backing it.  For a
> graphical console that would be the emlated graphic device.  For a text
> console it would be the serial line or monitor hooked up to it.
> 
> With this in place we should be able to answer questions like "which
> device backs this QemuConsole" by inspecting the object tree and handle
> requests like "do a screendump of this device please".  It will also be
> useful to setup input routing: "pointer events from $this QemuConsole
> should to $that virtual input device".
> 
> Hints how to do that best?  Pointers to sample code to look at?  From a
> brief look it seems we only QOM-ified emulated devices and not host-side
> objects yet ...

You could look at virtio-rng. TPM doesn't use QOM yet AFAIR.

Cheers,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] QOM-ify QemuConsoles ...

[Anthony Liguori]

Andreas Färber <afaerber@suse.de> writes:

> Hi Gerd,
>
> Am 20.03.2013 10:55, schrieb Gerd Hoffmann:
>> I think the next logical step ahead is to QOM-ify the QemuConsoles, so
>> we can link the QemuConsole to the thing actually backing it.  For a
>> graphical console that would be the emlated graphic device.  For a text
>> console it would be the serial line or monitor hooked up to it.
>> 
>> With this in place we should be able to answer questions like "which
>> device backs this QemuConsole" by inspecting the object tree and handle
>> requests like "do a screendump of this device please".  It will also be
>> useful to setup input routing: "pointer events from $this QemuConsole
>> should to $that virtual input device".
>> 
>> Hints how to do that best?  Pointers to sample code to look at?  From a
>> brief look it seems we only QOM-ified emulated devices and not host-side
>> objects yet ...
>
> You could look at virtio-rng. TPM doesn't use QOM yet AFAIR.

I think the first step is to figure out what the relationships are.  I
was looking through the changes and vaguely, it appears that its:

 - Each UI has one or more DisplayChangeListeners

 - Each DisplayChangeListener can be mapped to 1 or more QemuConsoles

 - Each QemuConsole can then be mapped to some thing that's drawing.

So DisplayChangeListener is basically a QemuConsole multiplexer.  If we
are keeping this basic design, then I think it's just a matter of
converting DisplayChangeListener to a QOM object, QemuConsole to QOM
object, then finally each UI.

Then you can select via links what QemuConsoles map to each DCL.

Regards,

Anthony Liguori

>
> Cheers,
> Andreas
>
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] QOM-ify QemuConsoles ...

[Gerd Hoffmann]

  Hi,

> I think the first step is to figure out what the relationships are.  I
> was looking through the changes and vaguely, it appears that its:
> 
>  - Each UI has one or more DisplayChangeListeners

Yes.

>  - Each DisplayChangeListener can be mapped to 1 or more QemuConsoles

Each DisplayChangeListener shows one QemuConsole at a time.

The relationship can either be fixed (gtk, spice), so the
DisplayChangeListener shows the very same QemuConsole all the time.

Or the DisplayChangeListener shows the "active" console, so each
console_select() call will change the QemuConsole it is showing.

I'm happy with that for the moment.

>  - Each QemuConsole can then be mapped to some thing that's drawing.

Yes.  This is what I want model first for sane qapi interfaces.

We have graphical QemuConsoles, which are linked directly to a emulated
graphic card (they create one via graphic_console_init).

We have text QemuConsoles, which are linked directly to a vc chardev,
then indirectly via chardev to something else, which could be either a
guest device (serial line) or some qemu thingy (monitor).

I want a qmp command which can write out screen dumps from any graphic
card (and if it happens to be easy from vc consoles too, but that isn't
a priority).  And I want some sane API for that.  I think QOM is the way
to go for that.  Specify the gfx card by id or path, then go find the
QemuConsole belonging to it using QOM, then dump it.

There is also the input side of things.  I want add a QemuConsole
argument to the kbd_put_keycode + kbd_mouse_event so the qemu input code
has an idea where the event came from.  Then have some way to link input
devices to QemuConsoles, so we can route events to different input
devices depending on the source.  Where I thing again QOM is the best
answer for "some way".

cheers,
  Gerd

Re: [Qemu-devel] QOM-ify QemuConsoles ...

[Stefan Berger]

On 03/20/2013 09:39 AM, Andreas Färber wrote:
> Hi Gerd,
>
> Am 20.03.2013 10:55, schrieb Gerd Hoffmann:
>> I think the next logical step ahead is to QOM-ify the QemuConsoles, so
>> we can link the QemuConsole to the thing actually backing it.  For a
>> graphical console that would be the emlated graphic device.  For a text
>> console it would be the serial line or monitor hooked up to it.
>>
>> With this in place we should be able to answer questions like "which
>> device backs this QemuConsole" by inspecting the object tree and handle
>> requests like "do a screendump of this device please".  It will also be
>> useful to setup input routing: "pointer events from $this QemuConsole
>> should to $that virtual input device".
>>
>> Hints how to do that best?  Pointers to sample code to look at?  From a
>> brief look it seems we only QOM-ified emulated devices and not host-side
>> objects yet ...
> You could look at virtio-rng. TPM doesn't use QOM yet AFAIR.

Yes, I am doing the conversion for TPM.

    Stefan