On Fri, Jan 31, 2020 at 05:22:47PM +0100, Paolo Bonzini wrote:
> I have just found this email... sorry for the delay.
>
> On 10/01/20 07:10, Yang Zhong wrote:
> >> No. If virtio-blk works, the bug is in vhost-user-blk; if virtio-blk needs
> >> no check in cpu count, vhost-user-blk also doesn't.
>
On Fri, Jan 31, 2020 at 05:22:47PM +0100, Paolo Bonzini wrote:
> I have just found this email... sorry for the delay.
>
> On 10/01/20 07:10, Yang Zhong wrote:
> >> No. If virtio-blk works, the bug is in vhost-user-blk; if virtio-blk needs
> >> no check in cpu count, vhost-user-blk also doesn't.
>
I have just found this email... sorry for the delay.
On 10/01/20 07:10, Yang Zhong wrote:
>> No. If virtio-blk works, the bug is in vhost-user-blk; if virtio-blk needs
>> no check in cpu count, vhost-user-blk also doesn't.
>>
>> You need to check first if the bug is in QEMU or the vhost-user-blk s
On Fri, Jan 03, 2020 at 10:18:58PM +0100, Paolo Bonzini wrote:
> Il ven 3 gen 2020, 16:08 Yang Zhong ha scritto:
>
> > I also tried virtio-blk device like below:
> > https://patchwork.kernel.org/cover/10873193/
> >
> > The virtio-blk can work with this changes, but vhost-user-blk device
>
On Fri, Jan 03, 2020 at 10:18:58PM +0100, Paolo Bonzini wrote:
> Il ven 3 gen 2020, 16:08 Yang Zhong ha scritto:
>
> > I also tried virtio-blk device like below:
> > https://patchwork.kernel.org/cover/10873193/
> >
> > The virtio-blk can work with this changes, but vhost-user-blk device
> >
Il ven 3 gen 2020, 16:08 Yang Zhong ha scritto:
> I also tried virtio-blk device like below:
> https://patchwork.kernel.org/cover/10873193/
>
> The virtio-blk can work with this changes, but vhost-user-blk device
> failed with this kernel patch.
>
> in vhost_virtqueue_start() function,
On Mon, Dec 23, 2019 at 06:33:26PM +0100, Paolo Bonzini wrote:
> On 23/12/19 15:25, Michael S. Tsirkin wrote:
> > On Mon, Dec 23, 2019 at 12:02:18PM +0100, Paolo Bonzini wrote:
> >> On 23/12/19 10:18, Yang Zhong wrote:
> >>> In this time, the queue number in the front-end block driver is 2, but
>
On 23/12/19 15:25, Michael S. Tsirkin wrote:
> On Mon, Dec 23, 2019 at 12:02:18PM +0100, Paolo Bonzini wrote:
>> On 23/12/19 10:18, Yang Zhong wrote:
>>> In this time, the queue number in the front-end block driver is 2, but
>>> the queue number in qemu side is still 4. So the guest virtio_blk
On Mon, Dec 23, 2019 at 12:02:18PM +0100, Paolo Bonzini wrote:
> On 23/12/19 10:18, Yang Zhong wrote:
> > In this time, the queue number in the front-end block driver is 2, but
> > the queue number in qemu side is still 4. So the guest virtio_blk
> > driver will failed to create vq with backe
On 23/12/19 10:18, Yang Zhong wrote:
> In this time, the queue number in the front-end block driver is 2, but
> the queue number in qemu side is still 4. So the guest virtio_blk
> driver will failed to create vq with backend.
Where?
> There is no "set back"
> mechnism for block driver t
On Mon, Dec 23, 2019 at 09:44:46AM +0100, Paolo Bonzini wrote:
> On 23/12/19 09:28, Yang Zhong wrote:
> > In the guest kernel driver, like virtio_blk.c and virtio_scsi.c,
> > there are some definitions like below:
> >
> > num_vqs = min_t(unsigned int, nr_cpu_ids, num_vqs)
> >
> > If the queue num
On 23/12/19 09:28, Yang Zhong wrote:
> In the guest kernel driver, like virtio_blk.c and virtio_scsi.c,
> there are some definitions like below:
>
> num_vqs = min_t(unsigned int, nr_cpu_ids, num_vqs)
>
> If the queue number is bigger than vcpu number, the VM will be
> stuck in the guest driver be
In the guest kernel driver, like virtio_blk.c and virtio_scsi.c,
there are some definitions like below:
num_vqs = min_t(unsigned int, nr_cpu_ids, num_vqs)
If the queue number is bigger than vcpu number, the VM will be
stuck in the guest driver because the qemu and guest driver have
different queu
13 matches
Mail list logo