Daniel P. Berrange wrote: [snip] > > 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 Qemu? Thiemo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
