On Wed, 12 Sep 2012 20:58:00 -0500 Anthony Liguori <aligu...@us.ibm.com> wrote:
> "Daniel P. Berrange" <berra...@redhat.com> 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.