[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v3 ATCH 0/5] char: expose CirMemCharDriver and pro
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [RFC v3 ATCH 0/5] char: expose CirMemCharDriver and provide QMP interface |
Date: |
Wed, 19 Sep 2012 14:40:54 -0300 |
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.
- Re: [Qemu-devel] [PATCH 4/5] QAPI: Introduce memchar-read QMP command, (continued)
- [Qemu-devel] [PATCH 5/5] HMP: Introduce console command, Lei Li, 2012/09/12
- [Qemu-devel] [PATCH 3/5] QAPI: Introduce memchar-write QMP command, Lei Li, 2012/09/12
- [Qemu-devel] [PATCH 2/5] Expose CirMemCharDriver via command line, Lei Li, 2012/09/12
- Re: [Qemu-devel] [RFC v3 ATCH 0/5] char: expose CirMemCharDriver and provide QMP interface, Avi Kivity, 2012/09/12
- Re: [Qemu-devel] [RFC v3 ATCH 0/5] char: expose CirMemCharDriver and provide QMP interface, Daniel P. Berrange, 2012/09/12