Re: [Qemu-devel] [RFC PATCH 0/4] char: expose MemoryCharDriver to users and provide QMP interface

[Anthony Liguori <aliguori@us.ibm.com>]

Lei Li <lilei@linux.vnet.ibm.com> writes:

> This RFC series attempts to convert the MemCharDriver to use a circular
> buffer for input and output, expose it to users by introducing QMP commands
> memchar_write and memchar_read and via the command line like the other
> CharDriverStates.
>
> Serial ports in qemu always use CharDriverStates as there backends,
> Right now, all of our backends always try to write the data from the
> guest to a socket or file. The concern from OpenStack is that this could
> lead to unbounded disk space usage since they log the serial output.
> For more detail of the background info:
> https://bugs.launchpad.net/nova/+bug/832507

The other neat feature this could allow is an HMP "console" command that
allows you to temporarily connect to the serial console from within the
monitor.  This could provide a cleaner approach to how we currently do
chardev muxing.

It also means you can interact with multiple chardevs via a single
monitor socket (or via the GDB monitor interface).

> So we want to use a circular buffer in QEMU instead, and then OpenStack
> can periodically read the buffer in QEMU and log it.
>
> The QMP commands introduced like:
>
> { 'command': 'memchar_write',
>   'data': {'chardev': 'str', 'size': 'int', 'data': 'str'} }
>
> { 'command': 'memchar_read',
>   'data': {'chardev': 'str', 'size': 'int'},
>   'returns': 'str' }
>
> Expose MemCharDriver via the command line like:
>
> qemu -chardev memchr,max-capacity=640k,id=foo -serial chardev:foo
>
> Note:
> This series is just a incomplete sketch and not completely tested which
> I am still struggling with, but I want to get this out ealier to have
> your suggestion. Please comment and let me know if this seems like the
> direction we should be headed, thanks!
>
> TODO:
> 1) Expose the MemCharDriver via the command line like the other
>    CharDriverStates.
> 2) Wherther to add locking or notification mechanism.

Notification is an interesting topic.  I thought a lot about it and I
believe that we should simply avoid notification for now.

When we introduce async commands, we could make the read command block
which I think is a lot nicer.

BTW, we should introduce options for the read and write command that
specifies behavior when the queue is full/empty.  For instance,

..., '*control': 'CongestionControl' }

{ 'enum': 'CongestionControl', 'data': [ 'drop', 'block' ] }

We would default to control=drop which would result in reads returning
empty strings and writes dropping queued data.

OTOH, when we get sync commands, we would add the 'block' enum option
and then we could make the session block until data was available or the
queue had space available.

Regards,

Anthony Liguori

>
>
> Lei Li (4):
>   qemu-char: Convert MemCharDriver to circular buffer
>   monitor: Adjust qmp_human_monitor_command to new MemCharDriver
>   QAPI: Introduce memchar_write QMP command
>   QAPI: Introduce memchar_read QMP command
>
>  monitor.c        |    2 +-
>  qapi-schema.json |   40 +++++++++++++++++
>  qemu-char.c      |  130 ++++++++++++++++++++++++++++++++++++++++++++++--------
>  qemu-char.h      |    2 +-
>  qmp-commands.hx  |   60 ++++++++++++++++++++++++-
>  5 files changed, 212 insertions(+), 22 deletions(-)