Re: [Qemu-devel] Re: [PATCH 10/15] virtio-serial: Add QMP events for failed port/device add

[Amit Shah]

On (Fri) Mar 26 2010 [04:07:54], Jamie Lokier wrote:
> Amit Shah wrote:
> > On (Fri) Mar 26 2010 [01:17:49], Jamie Lokier wrote:
> > > Luiz Capitulino wrote:
> > > > On Thu, 25 Mar 2010 09:17:17 +0530
> > > > Amit Shah <address@hidden> wrote:
> > > > 
> > > > > On (Wed) Mar 24 2010 [17:34:15], Luiz Capitulino wrote:
> > > > > > On Wed, 24 Mar 2010 20:19:28 +0530
> > > > > > Amit Shah <address@hidden> wrote:
> > > > > > 
> > > > > > > When adding a port or a device to the guest fails, management 
> > > > > > > software
> > > > > > > might be interested in knowing and then cleaning up the host-side 
> > > > > > > of the
> > > > > > > port. Introduce QMP events to signal such errors.
> > > > > > 
> > > > > >  I'm completely unfamiliar with virtio-serial, so let me ask: how 
> > > > > > are ports
> > > > > > added? I'd expect the command performing this operation to fail in 
> > > > > > this case.
> > > > > 
> > > > > If adding the port fails in qemu, then the command will fail. However 
> > > > > if
> > > > > adding the port in the guest fails, we raise this QMP event. Adding in
> > > > > the guest could fail because of several reasons, like ENOMEM. In this
> > > > > case, the mgmt might want to hot-unplug the port from qemu so that
> > > > > resources are freed and also apps are notified of guest side not 
> > > > > ready.
> > > > 
> > > >  Ok, what about a disconnect? Does virtio-serial have this kind of 
> > > > action?
> > > 
> > > Disconnect would be valuable.  E.g. if the guest app dies (but not the
> > > guest kernel), it won't get a chance to send an "I'm going away"
> > > message.
> > 
> > That's something applications should be able to handle: If an app on the
> > guest dies, the app on the host should be able to discover this.
> 
> Sure.  Does the host app see an EOF on its input when that happens?
> (I.e. *not* like a real serial port).

If it's an in-qemu app, it gets the guest_closed() callback. So I guess
qmp events for non-qemu apps is what you're looking for?

> If so, there's no need for a disconnect event, otherwise, if it's like
> a serial port, there is.
> 
> > > Machine reboot, PCI reset and so on, should probably trigger a
> > 
> > All these messages belong to other subsystems, not virtio-serial. Eg,
> b> libvirt or other mgmt app should know that a reset event, when received,
> > affects virtio ports as well. Similar for pci events.
> 
> Fine (although I don't like that a non-mgmt host app only interested
> talking to a guest with an architecture-neutral protocol might need to
> know about PCI, or even need to know anything about how the VM was
> launched).
> 
> But what I really meant was, if the guest resets, and then it boots up
> before the host apps manage to process their events (e.g. due to
> timing, remoteness, swapping or whatever), it's important that the
> virtio-serial using host app knows where the discontinuity in the byte
> stream is.  Otherwise the app needs to use a silly overcomplicated
> protocol just to provide a reliable layer over the byte stream.

I'd rather that the apps used the existing QMP notifications for guest
reset so that we don't have to do anything special for virtio-serial
(and for other devices as well).

Also, if it might help, the 'guest device ready' and 'guest port ready'
QMP events can be sent on success as well (right now they're only sent
on failure).

                Amit