qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/5] Add feature to start QEMU without vhost-


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v2 0/5] Add feature to start QEMU without vhost-user backend
Date: Sun, 19 Jul 2015 15:48:00 +0300

On Wed, Jun 24, 2015 at 07:57:45AM +0200, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2015 at 02:46:30PM +0900, Tetsuya Mukawa wrote:
> > On 2015/06/23 18:41, Michael S. Tsirkin wrote:
> > > On Tue, Jun 23, 2015 at 05:31:06PM +0900, Tetsuya Mukawa wrote:
> > >> On 2015/06/22 17:14, Michael S. Tsirkin wrote:
> > >>> On Mon, Jun 22, 2015 at 12:50:43PM +0900, Tetsuya Mukawa wrote:
> > >>>> Hi guys,
> > >>>>
> > >>>> Here are patches to add feature to start QEMU without vhost-user 
> > >>>> backend.
> > >>>> Currently, if we want to use vhost-user backend, the backend must 
> > >>>> start before
> > >>>> QEMU.
> > >>> Aren't you looking for something like xinetd?
> > >> It will help for restricting starting order, but not help for
> > >> reconnection of vhost-user backend.
> > > At this point, I suggest that we always connect at vm start.
> > > With that, you can add an option to reset the VM
> > > on backend disconnect.
> > > So
> > >   - detect backend disconnect
> > >   - reset and stop (notifying management)
> > >   - reconnect or detect backend reconnect
> > >   - proceed with boot
> > >
> > > As I tried to explain below, getting the full functionality
> > > will require guest driver changes. They aren't hard to get
> > > done, patches welcome.
> > >
> > 
> > Could you please let me know your thinking about using
> > DEVICE_NEEDS_RESET for vhost-user reconnection?
> > If it's works, I will try to submit it.
> 
> DEVICE_NEEDS_RESET is hard to handle correctly in guest:
> you need to reconfigure a bunch of state,
> so far no one wrote the necessary support.


But yes, if you write the guest code, I think
it can work.

We probably want a feature bit so host can know guest can
handle reconnections, but that's a minor detail, it
would be easy to add afterwards.

-- 
MST



reply via email to

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