Re: [Qemu-devel] [RFC v3 ATCH 0/5] char: expose CirMemCharDriver and provide QMP interface

[Luiz Capitulino]

On Wed, 12 Sep 2012 20:58:00 -0500
Anthony Liguori <address@hidden> wrote:

> "Daniel P. Berrange" <address@hidden> writes:
> 
> > On Wed, Sep 12, 2012 at 07:57:21PM +0800, Lei Li wrote:
> >> 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
> >
> > Unbounded disk usage is only relevant if telling QEMU to write directly
> > to its file backend. If you use a socket backend the mgmt app can provide
> > whatever policy it desires.
> >
> >> So we want to use a circular buffer in QEMU instead, and then OpenStack
> >> can periodically read the buffer in QEMU and log it.
> >
> > With any circular buffer you obviously have a race condition where
> > the buffer may overflow before the application can consume the data.
> > By implementing the circular buffer in QEMU you are imposing a
> > specific policy for overflow on the applications using QEMU, namely
> > that data gets overwritten/lost.
> >
> > If the circular buffering is done outside QEMU, then the application
> > can implement a variety of policies on overflow. At the very least
> > they can detect when overflow would occur, and insert a marker to
> > the effect that there is a log discontinuity. Or they can pause the
> > VM for a period of time, or reduce its scheduling priority, or any
> > number of different things.
> >
> > The further advantage of doing it outside QEMU, is that OpenStack will
> > work with all existing QEMU/KVM/libvirt versions.
> 
> I'm not sure what is the best solution for libvirt and OpenStack but I
> think you're missing a few key points.
> 
> CDS doesn't propagate flow control to the guest (in some cases, it
> simply can't because hardware doesn't).  That means that there has to be
> some policy in QEMU about what to do with data that cannot be written to
> a socket.
> 
> Today we simply drop new data.  This adds a mechanism where we drop old
> data.  For some cases, dropping old data is much nicer than dropping new
> data.
> 
> But there are other compelling use-cases for this beyond libvirt.  This
> will allow us to implement a 'console' command which will be pretty nice
> within HMP.
> 
> It also provides a very nice way to write tests.  It's much easier to
> use something like this from qtest than it is to setup a socket in in
> listen mode and then queue incoming data to be read.

Sorry for catching up with this late, and hopefully my idea won't be
stupid.

But what about adding a fd backend chardev, which allows for i/o through
an fd passed by the client. Then we could add monitor_fd_add(), so that
internal qemu code (ie. hmp_console()) could add an fd to the monitor's poll.

That should eliminate the internal buffer and allow for the console
command.