qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop
Date: Wed, 16 Mar 2016 14:10:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0


On 16/03/2016 14:04, Cornelia Huck wrote:
> > No, it would not.  ioeventfd=off,vhost=on would mean: "when vhost is
> > off, use vCPU thread notification".
> 
> *confused*
> 
> Is ioeventfd=off supposed to mean "don't talk to the kernel, do
> everything in qemu"?

For KVM, it means do everything in the QEMU vCPU thread (using userspace
vmexits).

>> > When turning on vhost you'd still stop ioeventfd (i.e. stop processing
>> > the virtqueue in QEMU's main iothread), but you don't need to do
>> > anything to the event notifier.  vhost will pick it up and work on the
>> > virtqueue if necessary.  Likewise for dataplane.
> 
> So "disassociate the handler and switch over to the new one"?

Yes, if we prohibit combinations which switch from vCPU thread
notification to vhost or dataplane (such as ioeventfd=off,vhost=on).  If
we always use an eventfd, we always have a handler to switch to.

> > > > If they aren't, it should be okay to remove the
> > > > virtio_queue_host_notifier_read call in
> > > > virtio_queue_set_host_notifier_fd_handler and
> > > > virtio_queue_aio_set_host_notifier_handler.  That's because a handler
> > > > for the notifier will always be set _somewhere_.  It could be the usual
> > > > ioeventfd handler, the vhost handler or the dataplane handler, but one
> > > > will be there.
> > > 
> > > It should; but we probably need to do a final read when we stop the
> > > ioeventfd.
> > 
> > I was thinking of handing the final read directly to the next guy who
> > polls the event notifier instead.  So, when called from vhost or
> > dataplane, virtio_pci_stop_ioeventfd would use
> > assign=true/set_handler=false ("a new notifier is going to be set up by
> > the caller").
> 
> OK, then we'd need to pass a new parameter for this.

Yes, agreed.

> > The host notifier API unfortunately is full of indirections.  I'm not
> > sure how many of them are actually necessary.
> 
> Oh yes, it's very hard to follow, especially with not-very-well defined
> parameters.

And full of duplicate code.  If copied code were moved to the virtio bus
level, it would be easier to change too.

Paolo



reply via email to

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