On Thu, 30 May 2024 10:34:55 +0800
Jason Wang wrote:
> >
> > IMHO changing the semantic of the VHOST_GET_FEATURES ioctl is not viable,
> > but also not necessary. What I am proposing is changing the (in QEMU)
> > logic of processing the features returned by VHOST_GET_FEATURES, while
> >
On Wed, May 29, 2024 at 02:49:28PM GMT, Halil Pasic wrote:
On Tue, 28 May 2024 17:32:26 +0200
Stefano Garzarella wrote:
>1) The uses is explicitly asking for a vhost device and giving the user
>a non vhost device is not an option.
I didn't get this point :-( can you elaborate?
I was
On Wed, May 29, 2024 at 8:18 PM Halil Pasic wrote:
>
> On Tue, 28 May 2024 11:25:51 +0800
> Jason Wang wrote:
>
> > > 5) Based on the following, I would very much prefer a per device list of
> > > features with the semantic "hey QEMU can do that feature without any
> > > specialized vhost-device
On Tue, 28 May 2024 17:32:26 +0200
Stefano Garzarella wrote:
> >1) The uses is explicitly asking for a vhost device and giving the user
> >a non vhost device is not an option.
>
> I didn't get this point :-( can you elaborate?
I was thinking along the lines: QEMU gets told what devices to
On Tue, 28 May 2024 11:25:51 +0800
Jason Wang wrote:
> > 5) Based on the following, I would very much prefer a per device list of
> > features with the semantic "hey QEMU can do that feature without any
> > specialized vhost-device support (e.g. like VIRTIO_SCSI_F_CHANGE)"
>
> Indeed the
On Mon, May 27, 2024 at 01:27:10PM GMT, Halil Pasic wrote:
On Thu, 16 May 2024 10:39:42 +0200
Stefano Garzarella wrote:
[..]
>---
>
>This is a minimal fix, that follows the current patterns in the
>codebase, and not necessarily the best one.
Yeah, I did something similar with commit
On Mon, May 27, 2024 at 7:27 PM Halil Pasic wrote:
>
> On Thu, 16 May 2024 10:39:42 +0200
> Stefano Garzarella wrote:
>
> [..]
> > >---
> > >
> > >This is a minimal fix, that follows the current patterns in the
> > >codebase, and not necessarily the best one.
> >
> > Yeah, I did something
On Thu, 16 May 2024 10:39:42 +0200
Stefano Garzarella wrote:
[..]
> >---
> >
> >This is a minimal fix, that follows the current patterns in the
> >codebase, and not necessarily the best one.
>
> Yeah, I did something similar with commit 562a7d23bf ("vhost: mask
> VIRTIO_F_RING_RESET for
On Mon, Apr 29, 2024 at 01:33:34PM GMT, Halil Pasic wrote:
Not having VIRTIO_F_RING_PACKED in feature_bits[] is a problem when the
vhost-vsock device does not offer the feature bit VIRTIO_F_RING_PACKED
but the in QEMU device is configured to try to use the packed layout
(the virtio property
On Tue, 7 May 2024 21:26:30 +0200
Halil Pasic wrote:
> > Not having VIRTIO_F_RING_PACKED in feature_bits[] is a problem when the
> > vhost-vsock device does not offer the feature bit VIRTIO_F_RING_PACKED
> > but the in QEMU device is configured to try to use the packed layout
> > (the virtio
On Mon, 29 Apr 2024 13:33:34 +0200
Halil Pasic wrote:
> Not having VIRTIO_F_RING_PACKED in feature_bits[] is a problem when the
> vhost-vsock device does not offer the feature bit VIRTIO_F_RING_PACKED
> but the in QEMU device is configured to try to use the packed layout
> (the virtio property
Not having VIRTIO_F_RING_PACKED in feature_bits[] is a problem when the
vhost-vsock device does not offer the feature bit VIRTIO_F_RING_PACKED
but the in QEMU device is configured to try to use the packed layout
(the virtio property "packed" is on).
As of today, the Linux kernel vhost-vsock
12 matches
Mail list logo
