On Wed, Sep 11, 2019 at 11:20:40AM +0200, Johannes Berg wrote:
>
> > 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?
Like other
> 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 Tue, Sep 10, 2019 at 05:52:36PM +0200, Johannes Berg wrote:
> 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
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 section that lists 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.
> > > bit 4 after NEED_REPLY). Qemu
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.
> > bit 4 after NEED_REPLY). Qemu in vhost_user_read_header() validates that
> > it received
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 message at that
> point.
>
>
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, Sep 09, 2019 at 03:50:48PM +0200, Johannes Berg wrote:
> 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
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, Sep 09, 2019 at 03:05:08PM +0200, Johannes Berg wrote:
> 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
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 Mon, Sep 09, 2019 at 01:35:19PM +0200, Johannes Berg wrote:
> 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.
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
On Fri, Sep 06, 2019 at 05:32:02PM +0200, Johannes Berg wrote:
> 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
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
On Fri, Sep 06, 2019 at 04:48:39PM +0200, Johannes Berg wrote:
> 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
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, definitely needed.
I was just
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?
> ---
> contrib/libvhost-user/libvhost-user.c | 61 +++
> contrib/libvhost-user/libvhost-user.h
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
20 matches
Mail list logo
