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 t
On Wed, Sep 11, 2019 at 05:36:32PM +0200, Johannes Berg wrote:
> 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
>
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 just have to include the
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, wi
On Mon, Sep 2, 2019 at 2:13 PM Johannes Berg wrote:
>
> 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 simul
On Wed, Sep 11, 2019 at 11:13 AM Johannes Berg
wrote:
> 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:
> > I'm suggesting this because it seems like a clean
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
> > > > *wait* for the device to add a
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
> > > *wait* for the device to add an entry to the simulation calendar in
> > > response to the k
On Tue, Sep 10, 2019 at 05:34:57PM +0200, Johannes Berg wrote:
> 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
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'd
> > probably be difficul
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'd
> probably be difficult to upstream the patch to support this protocol to
> user-mode Linux
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, Sep 09, 2019 at 07:34:24PM +0200, Johannes Berg wrote:
> 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 --
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:
>
> vhost
On Thu, Sep 05, 2019 at 10:28:33PM +0200, Johannes Berg wrote:
>
> > +``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
> +``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.
[...]
> +``
16 matches
Mail list logo
