On Thu, 2020-01-23 at 09:17 +0100, Johannes Berg wrote:
> Hi,
>
> Here's a repost of all the patches I sent back in August, with the
> in-band notifications rebased over the reset patch, so IDs have now
> changed a bit.
Ping?
The patches still apply on top of latest qemu.
I want
From: Johannes Berg
The code here is odd, for example will it print out invalid
file descriptor numbers that were never sent in the message.
Clean that up a bit so it's actually possible to implement
a device that uses polling.
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost
From: Johannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but
as it's not desired by default, don't enable it unless the device
implementation opts in by returning it from its protocol features
callback.
Note that I updated vu_set_vring_err_exec(), but didn't add any
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have scheduled according
Hi,
Here's a repost of all the patches I sent back in August, with the
in-band notifications rebased over the reset patch, so IDs have now
changed a bit.
I've marked this all as v5 even if it really wasn't for all of them,
just the VugDev main fd cleanup patch was at v4 before.
I've also
From: Johannes Berg
If we use NULL, we just get the main program default mainloop
here. Using g_main_context_get_thread_default() has basically
the same effect, but it lets us start different devices in
different threads with different mainloops, which can be useful.
Reviewed-by: Stefan
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
From: Johannes Berg
This is really simple, since we know whether a response is
already requested or not, so we can just send a (successful)
response when there isn't one already.
Given that, it's not all _that_ useful but the master can at
least be sure the message was processed, and we can
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
On Mon, 2019-09-23 at 10:25 +0100, Stefan Hajnoczi wrote:
>
> According to unix(7):
>
> The addrlen argument that describes the enclosing sockaddr_un
> structure should have a value of at least:
>
> offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
>
> or, more simply,
On Wed, 2019-09-18 at 10:39 +0100, Stefan Hajnoczi wrote:
>
> > vu_check_queue_msg_file(VuDev *dev, VhostUserMsg *vmsg)
> > {
> > int index = vmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK;
> > +bool nofd = vmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK;
> >
> > if (index >=
From: Johannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but
as it's not desired by default, don't enable it unless the device
implementation opts in by returning it from its protocol features
callback.
Note that I updated vu_set_vring_err_exec(), but didn't add any
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have scheduled according
From: Johannes Berg
This implements
* the UM protocol to access the simulation calendar,
* the underlying simulation calendar, and
* a very trivial simulated network as a vhost-user
virtio_net device.
Currently the code is a bit rough and mostly an example,
things such as the network
From: Johannes Berg
The code here is odd, for example will it print out invalid
file descriptor numbers that were never sent in the message.
Clean that up a bit so it's actually possible to implement
a device that uses polling.
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost
From: Johannes Berg
If we use NULL, we just get the main program default mainloop
here. Using g_main_context_get_thread_default() has basically
the same effect, but it lets us start different devices in
different threads with different mainloops, which can be useful.
Signed-off-by: Johannes
On Mon, 2019-09-16 at 11:30 -0400, Michael S. Tsirkin wrote:
>
> So first we really need to fix up Starting and stopping section,
> explaining that if the FD is invalid, this means ring
> is immediately started, right?
It actually does say that, and ... I even changed it already to say the
ring
Hi Michael,
I had just wanted to prepare a resend, but
> > Hmm I don't like this. I propose that with
> > VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS
> > we just don't allow VHOST_USER_SET_VRING_CALL (if you think it's
> > important to allow them, we can say that we do not require them).
>
>
On Thu, 2019-09-12 at 14:22 +0200, Stefan Hajnoczi wrote:
>
> The vhost-user spec is unclear and inconsistent. Patches are welcome.
:)
> A footnote describing the old terminology would be necessary so that
> existing documentation, code, etc can still be decyphered when the spec
> changes the
On Thu, 2019-09-12 at 09:09 +0100, Dr. David Alan Gilbert wrote:
>
> You're actually using the same trick of using
> REPLY_ACK/need_reply to make it synchronous that set_mem_table does;
I don't think it's really the same - though arguably I could have
spec'ed the inband signal to *require* an
On Wed, 2019-09-11 at 20:15 +0100, Dr. David Alan Gilbert wrote:
> > Extend the protocol slightly, so that a message can be used for kick
> > and call instead, if VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS is
> > negotiated. This in itself doesn't guarantee synchronisation, but both
> > sides
On Wed, 2019-09-11 at 17:36 +0200, Johannes Berg wrote:
> On Wed, 2019-09-11 at 17:31 +0200, Stefan Hajnoczi wrote:
>
> > > +``VHOST_USER_VQ_CALL``
It should also be VRING, not VQ, but I did indeed fix that in v2 already
along with the CALL<->KICK inversion.
So I guess I
On Wed, 2019-09-11 at 17:31 +0200, Stefan Hajnoczi wrote:
> > +``VHOST_USER_VQ_CALL``
>
> "call" should be "kick". "kick" is the driver->device request
> submission notification and "call" is the device->driver request
> completion notification.
Ahrg, yes. I confuse this all the time, sorry,
On Wed, 2019-09-11 at 10:07 -0400, Michael S. Tsirkin wrote:
>
> > + #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD12
> > + #define VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS 13
>
> INFLIGHT so INBAND?
*shrug*, sure
> > + instead of waiting for the call; however, if the protocol
From: Johannes Berg
Add support for VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS, but
as it's not desired by default, don't enable it unless the device
implementation opts in by returning it from its protocol features
callback.
Note that I updated vu_set_vring_err_exec(), but didn't add any
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have scheduled according
Here's a respin of both the docs and the code, hopefully addressing
most of the requests from review. Let me know if I've missed anything
or not done it in the way you thought.
Thanks,
johannes
> Each feature is documented near the description of the functionality it
> enables, that can work for this.
Hmm, so you mean I should add a section on in-band notifications, and
document things there?
> I don't much like F_KICK_CALL_MSGS as
> not generic enough but it's not simulation as
On Wed, 2019-09-11 at 09:35 +0200, Stefan Hajnoczi wrote:
> On Tue, Sep 10, 2019 at 05:14:36PM +0200, Johannes Berg wrote:
> > On Tue, 2019-09-10 at 17:03 +0200, Stefan Hajnoczi wrote:
> > > > Now, this means that the CPU (that's part of the simulation) has to
> > >
On Mon, 2019-09-09 at 15:50 +0200, Johannes Berg wrote:
> > We can document how to behave in case of inconsistent protocol features,
> > yes.
>
> OK.
Coming back to this, I was just looking at it.
How/where would you like to see this done?
There isn't really any
On Tue, 2019-09-10 at 11:33 -0400, Michael S. Tsirkin wrote:
> On Tue, Sep 10, 2019 at 05:14:36PM +0200, Johannes Berg wrote:
> > Is any of you familiar with the process of getting a virtio device ID
> > assigned, and if so, do you think it'd be feasible? Without that, it
On Tue, 2019-09-10 at 17:03 +0200, Stefan Hajnoczi wrote:
>
> > Now, this means that the CPU (that's part of the simulation) has to
> > *wait* for the device to add an entry to the simulation calendar in
> > response to the kick... That means that it really has to look like
> >
> > CPU
On Mon, 2019-09-09 at 18:00 +0200, Stefan Hajnoczi wrote:
> Is this really necessary?
Yes* :)
> Can the simulation interpose between the
> call/kick eventfds in order to control when events happen?
>
> CPU --cpu_kickfd--> Simulation --vhost_kickfd--> vhost-user device
>
> and:
>
>
On Mon, 2019-09-09 at 11:45 -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 09, 2019 at 05:34:13PM +0200, Johannes Berg wrote:
> > On Mon, 2019-09-09 at 17:26 +0200, Johannes Berg wrote:
> > > Maybe instead we should just add a "VHOST_USER_REPLY_ERROR" bit (e.g.
> &g
On Mon, 2019-09-09 at 17:26 +0200, Johannes Berg wrote:
>
> Maybe instead we should just add a "VHOST_USER_REPLY_ERROR" bit (e.g.
> bit 4 after NEED_REPLY). Qemu in vhost_user_read_header() validates that
> it received REPLY_MASK | VERSION, so it would reject the m
On Mon, 2019-09-09 at 10:59 -0400, Michael S. Tsirkin wrote:
> > > Next command is GET_FEATURES. Return an error response from that
> > > and device init will fail.
> >
> > Hmm, what's an error here though? You can only return a value, no?
>
> Either returning id that does not match
On Mon, 2019-09-09 at 09:48 -0400, Michael S. Tsirkin wrote:
> > I suppose we could fail a later command that already needs a reply
> > without REPLY_ACK, but that seems difficult to debug?
>
> Next command is GET_FEATURES. Return an error response from that
> and device init will fail.
Hmm,
On Mon, 2019-09-09 at 08:41 -0400, Michael S. Tsirkin wrote:
> > The only thing we could do is crash if it wants to use this feature
> > without the others, but would that really be helpful?
>
> We can return failure from SET_PROTOCOL_FEATURES.
> We can also fail all following messages.
Only if
On Sun, 2019-09-08 at 09:13 -0400, Michael S. Tsirkin wrote:
> > I think the only use for this extension would be for simulation
> > purposes, and even then only combined with the REPLY_ACK and SLAVE_REQ
> > extensions, i.e. you explicitly *want* your virtual machine to lock up /
> > wait for a
Hi,
> Oh. Apparently qemu mailman chose this time to kick me out
> of list subscription (too many bounces or something?)
> so I didn't see it.
D'oh. Well, it's really my mistake, I should've CC'ed you.
> What worries me is the load this places on the socket.
> ATM if socket buffer is full qemu
Hi,
On Fri, 2019-09-06 at 10:22 -0400, Michael S. Tsirkin wrote:
> On Fri, Sep 06, 2019 at 03:13:50PM +0300, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > Signed-off-by: Johannes Berg
>
> a bit more content here about the motivation for this?
Heh, right, def
From: Johannes Berg
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost-user.c | 61 +++
contrib/libvhost-user/libvhost-user.h | 3 ++
2 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-user.c
b/contrib/libvhost
> +``VHOST_USER_VQ_CALL``
> + :id: 34
> + :equivalent ioctl: N/A
> + :slave payload: vring state description
> + :master payload: N/A
Oops. This message should be called VHOST_USER_VRING_KICK.
This file doesn't take about virtqueues, just vrings, and I inverted the
call/kick.
[...]
>
From: Johannes Berg
This simplifies the various has_feature() checks, we already
have vu_has_feature() but it checks features, not protocol
features.
Signed-off-by: Johannes Berg
---
contrib/libvhost-user/libvhost-user.c | 20 ++--
1 file changed, 10 insertions(+), 10
From: Johannes Berg
It doesn't look like this could possibly work properly since
VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD is defined to 10, but the
dev->protocol_features has a bitmap. I suppose the peer this
was tested with also supported VHOST_USER_PROTOCOL_F_LOG_SHMFD,
in which case the test wo
From: Johannes Berg
It doesn't look like this could possibly work properly since
VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD is defined to 10, but the
dev->protocol_features has a bitmap. I suppose the peer this
was tested with also supported VHOST_USER_PROTOCOL_F_LOG_SHMFD,
in which case the test wo
From: Johannes Berg
This is really simple, since we know whether a response is
already requested or not, so we can just send a (successful)
response when there isn't one already.
Given that, it's not all _that_ useful but the master can at
least be sure the message was processed, and we can
Hi all,
First of all, I'm not sure if QEMU actually maintains the master copy of
this document and it isn't like virtio? It *looks* like it does, given
that the updates are "do something" rather than "sync to some version",
but please let me know if I need to send this elsewhere.
Secondly, I'm
From: Johannes Berg
For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU
have are scheduled
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
Hi,
> > +g_source_unref(src);
> > +g_source_destroy(src);
>
> I would call destroy() (detach) before unref().
Fair enough. I think there's an internal reference, but it's probably
safer that way.
> > +vugg_source_destroy(vi.evsrc);
>
> typo
Oops. I thought I compiled it, I guess
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
Hi,
> What other problems? Sure we need the caller to unref.
Don't recall, and now I can't reproduce it, sorry.
> > > Imho, we should change the behaviour of the function to return a ref
> > > source.
> >
> > Which "the function" do you mean?
>
> The vug_source_new() function.
[...]
> Sure we
On Tue, 2019-08-27 at 14:47 +0400, Marc-André Lureau wrote:
> Hi
>
> On Tue, Aug 27, 2019 at 12:32 PM Johannes Berg
> wrote:
> > From: Johannes Berg
> >
> > If you try to make a device implementation that can handle multiple
> > connections and allow disco
From: Johannes Berg
If you try to make a device implementation that can handle multiple
connections and allow disconnections (which requires overriding the
VHOST_USER_NONE handling), then glib will warn that we remove a src
while it's still on the mainloop, and will poll() an FD that doesn't
On Thu, 2019-05-23 at 15:41 +0100, Stefan Hajnoczi wrote:
> > Also, not sure I understand how the client is started?
>
> The vhost-user device backend can be launched before QEMU. QEMU is
> started with the UNIX domain socket path so it can connect.
Hmm. I guess I'm confusing the terminology
Hi Stefan,
> Check out vhost-user. It's a protocol for running a subset of a VIRTIO
> device's emulation in a separate process (usually just the data plane
> with the PCI emulation and other configuration/setup still handled by
> QEMU).
Yes, I think that's basically what I'm looking for.
>
Hi Anton,
> > I'm thinking about adding virt-io support to UML, but the tricky part is
> > that while I want to use the virt-io basics (because it's a nice
> > interface from the 'inside'), I don't actually want the stock drivers
> > that are part of the kernel now (like virtio-net etc.) but
Hi,
While my main interest is mostly in UML right now [1] I've CC'ed the
qemu and virtualization lists because something similar might actually
apply to other types of virtualization.
I'm thinking about adding virt-io support to UML, but the tricky part is
that while I want to use the virt-io
60 matches
Mail list logo
