qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] contrib: add vhost-user-sim


From: Johannes Berg
Subject: Re: [Qemu-devel] [RFC] contrib: add vhost-user-sim
Date: Wed, 09 Oct 2019 17:01:26 +0200
User-agent: Evolution 3.30.5 (3.30.5-1.fc29)

On Wed, 2019-10-09 at 15:00 +0100, Stefan Hajnoczi wrote:

> > The first issue is that sometimes glib actually seems to reports an FD
> > as readable when it's not, so I even put them into non-blocking mode :(
> 
> Strange.  Spurious wakeups are possible in general.  I think when using
> fd monitoring (select(), poll(), etc) the fds should be in non-blocking
> mode.

Are they? I reimplemented all this on top of my (internal) testing
framework and use blocking FDs there, and had no issues whatsoever.

> But if you're seeing this often it makes me wonder if something else is
> unintentionally reading available bytes...

I have no idea, it'd be strange though, what would even get to the FD?

> > The second is that I can't seem to understand how to do recursive
> > mainloops.
> > 
> > To really do this *well*, it should remain a single-threaded
> > application, but would need a hook like
> > 
> > run_mainloop_until_fd_readable(vdev->call_fd)
> > 
> > inside the libvhost-user.c code, and that's a bit ugly ... if I even
> > could figure out how to implement that in glib.
> 
> Recursive mainloops are tricky since usually event loop code isn't
> written to be re-entrant.  It opens up a whole new dimension that
> existing code usually wasn't designed for.  In this case you are writing
> the code from scratch so maybe you can get it to work, but it makes me
> wonder why the recursive mainloop is necessary.

It's needed to handle different clients / connections.

For example, consider this flow

VM           net device & simtime
  <-------------- VHOST_USER_SLAVE_CALL_VRING
  --------------> request for time handling
  <-------------- response for time handling
  --------------> REPLY_ACK for VHOST_USER_SLAVE_CALL_VRING

I sort of solved it with different threads for the different entities
(netdev & simtime) but that also just causes deadlocks with the locking
that needs to happen.

Like I said, I had reimplemented this in the meantime with a (hand-
written) recursive mainloop as a single thread, and it works way better.
One of these days I need to sit down and port that to be independent of
my testing framework, so I can show the code ...

johannes




reply via email to

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