On 2020/9/30 下午4:07, Michael S. Tsirkin wrote:
On Tue, Sep 29, 2020 at 07:38:24PM +0100, Stefan Hajnoczi wrote:
On Tue, Sep 29, 2020 at 06:04:34AM -0400, Michael S. Tsirkin wrote:
On Tue, Sep 29, 2020 at 09:57:51AM +0100, Stefan Hajnoczi wrote:
On Tue, Sep 29, 2020 at 02:09:55AM -0400,
On 2020/9/28 下午11:32, Stefan Hajnoczi wrote:
On Mon, Sep 28, 2020 at 03:21:56PM +0400, Marc-André Lureau wrote:
On Mon, Sep 28, 2020 at 1:25 PM Stefan Hajnoczi
Where this converges with multi-process QEMU
At this point QEMU can run ad-hoc
On Thu, Oct 01, 2020 at 09:28:37AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > Architecturally, I think we can have 3 processes:
> > >
> > > VMM -- guest device emulation -- host backend
> > >
> > > to me this looks like increasing our defence in depth strength,
> > > as opposed to just
Hi,
> > Architecturally, I think we can have 3 processes:
> >
> > VMM -- guest device emulation -- host backend
> >
> > to me this looks like increasing our defence in depth strength,
> > as opposed to just shifting things around ...
>
> Cool idea.
Isn't that exactly what we can do once the
On Wed, Sep 30, 2020 at 03:57:52PM +0100, Stefan Hajnoczi wrote:
> IMO "Inflight I/O tracking" is best placed into libvhost-user instead of
> the vhost-user protocol.
Oh I agree qemu does nothing with it. The reason we have it defined in
the spec is to facilitate compatibility across backends.
I
On Wed, Sep 30, 2020 at 03:57:52PM +0100, Stefan Hajnoczi wrote:
> > Architecturally, I think we can have 3 processes:
> >
> >
> > VMM -- guest device emulation -- host backend
> >
> >
> > to me this looks like increasing our defence in depth strength,
> > as opposed to just shifting things
On Wed, Sep 30, 2020 at 04:07:59AM -0400, Michael S. Tsirkin wrote:
> On Tue, Sep 29, 2020 at 07:38:24PM +0100, Stefan Hajnoczi wrote:
> > On Tue, Sep 29, 2020 at 06:04:34AM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Sep 29, 2020 at 09:57:51AM +0100, Stefan Hajnoczi wrote:
> > > > On Tue, Sep
On Tue, Sep 29, 2020 at 07:38:24PM +0100, Stefan Hajnoczi wrote:
> On Tue, Sep 29, 2020 at 06:04:34AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Sep 29, 2020 at 09:57:51AM +0100, Stefan Hajnoczi wrote:
> > > On Tue, Sep 29, 2020 at 02:09:55AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon, Sep
On Tue, Sep 29, 2020 at 06:04:34AM -0400, Michael S. Tsirkin wrote:
> On Tue, Sep 29, 2020 at 09:57:51AM +0100, Stefan Hajnoczi wrote:
> > On Tue, Sep 29, 2020 at 02:09:55AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Sep 28, 2020 at 10:25:37AM +0100, Stefan Hajnoczi wrote:
> > > > Why extend
On Tue, Sep 29, 2020 at 09:57:51AM +0100, Stefan Hajnoczi wrote:
> On Tue, Sep 29, 2020 at 02:09:55AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 28, 2020 at 10:25:37AM +0100, Stefan Hajnoczi wrote:
> > > Why extend vhost-user with vDPA?
> > >
> > > Reusing
On Tue, Sep 29, 2020 at 02:09:55AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 28, 2020 at 10:25:37AM +0100, Stefan Hajnoczi wrote:
> > Why extend vhost-user with vDPA?
> >
> > Reusing VIRTIO emulation code for vhost-user backends
> >
Thanks for the post!
I have one comment:
On Mon, Sep 28, 2020 at 10:25:37AM +0100, Stefan Hajnoczi wrote:
> Why extend vhost-user with vDPA?
>
> Reusing VIRTIO emulation code for vhost-user backends
> -
> It is a
On Mon, Sep 28, 2020 at 03:21:56PM +0400, Marc-André Lureau wrote:
> On Mon, Sep 28, 2020 at 1:25 PM Stefan Hajnoczi > Where this converges with multi-process QEMU
> >
> > At this point QEMU can run ad-hoc vhost-user backends using existing
> > VIRTIO
Hi
On Mon, Sep 28, 2020 at 1:25 PM Stefan Hajnoczi Where this converges with multi-process QEMU
>
> At this point QEMU can run ad-hoc vhost-user backends using existing
> VIRTIO device models. It is possible to go further by creating a
> qemu-dev
Hi,
Thanks for the positive responses to the initial discussion about
introducing VHOST_USER_PROTOCOL_F_VDPA to use vDPA semantics and bring
the full VIRTIO device model to vhost-user:
https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05181.html
Below is an inlined version of the more
On Thu, Sep 10, 2020 at 10:55:00AM +0200, Maxime Coquelin wrote:
> I understand the need and like the idea.
If no one plans to work on this within the next 6 months it could be an
internship project since the Outreachy December-March round is coming
up.
The time requirement is typically ~5 hours
l.
>
> A vdpa-user protocol (or vhost-user 2.0) would replace the current mess
> with a full VIRTIO device model. Both VMMs and device backends would
> require changes to support this, but it would be a cleaner path forward
> for the vhost-user protocol.
>
> One way of doing this
to support this, but it would be a cleaner path forward
for the vhost-user protocol.
One way of doing this would be a new VHOST_USER_PROTOCOL_F_VDPA feature
bit that indicates all the currently existing Linux vDPA ioctl messages
are available. Legacy vhost-user messages with overlapping functionality
must
for the vhost-user protocol.
One way of doing this would be a new VHOST_USER_PROTOCOL_F_VDPA feature
bit that indicates all the currently existing Linux vDPA ioctl messages
are available. Legacy vhost-user messages with overlapping functionality
must not be used when this bit is set. Most
19 matches
Mail list logo
