[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Vmchannel PCI device.

From: Thiemo Seufer
Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device.
Date: Mon, 15 Dec 2008 02:18:19 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Daniel P. Berrange wrote:
> > If you don't have QEMU as a broker, it makes it very hard for QEMU to 
> > virtualization all of the resources exposed to the guest.  This 
> > complicates things like save/restore and complicates security policies 
> > since you now have things being done on behalf of a guest originating 
> > from another process.  It generally breaks the model of guest-as-a-process.
> This really depends on what you define the semantics of the vmchannel
> protocol to be - specifically whether you want save/restore/migrate to
> be totally opaque to the guest or not. I could imagine one option is to
> have the guest end of the device be given -EPIPE when the backend is
> restarted for restore/migrate, and choose to re-establish its connection
> if so desired. This would not require QEMU to maintain any backend state.
> For stateless datagram (UDP-like) application protocols there's nothing 
> that there's no special support required for save/restore.
> > What's the argument to do these things external to QEMU?
> There are many potential uses cases for VMchannel,

Could you describe a practical use case of VMchannel in Qemu? I think I
missed what this feature is good for. :-)

> not all are going to be general purpose things that everyone wants to
> use.

If it is only good for specialized esoteric stuff, why should it be in


reply via email to

[Prev in Thread] Current Thread [Next in Thread]