linux-kernel - Re: [PATCH] drivers: virtio_blk: notify blk-core when hw-queue number changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b17ce95d-b11c-a74b-4118-ac8fa0be4bc1@redhat.com>
Date:	Mon, 1 Aug 2016 11:58:52 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Bob Liu <bob.liu@...cle.com>
Cc:	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org, mst@...hat.com
Subject: Re: [PATCH] drivers: virtio_blk: notify blk-core when hw-queue number
 changes



On 28/07/2016 10:18, Bob Liu wrote:
>>> >> A guest might be migrated to other hosts with different num_queues, the
>>> >> blk-core should aware of that else the reference of &vblk->vqs[qid] may be wrong.
>>> >>
>>> >> Signed-off-by: Bob Liu <bob.liu@...cle.com>
>>> >> ---
>>> >>  drivers/block/virtio_blk.c | 3 +++
>>> >>  1 file changed, 3 insertions(+)
>>> >>
>>> >> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>>> >> index 42758b5..c169238 100644
>>> >> --- a/drivers/block/virtio_blk.c
>>> >> +++ b/drivers/block/virtio_blk.c
>>> >> @@ -819,6 +819,9 @@ static int virtblk_restore(struct virtio_device *vdev)
>>> >>  	if (ret)
>>> >>  		return ret;
>>> >>  
>>> >> +	if (vblk->num_vqs != vblk->tag_set.nr_hw_queues)
>>> >> +		blk_mq_update_nr_hw_queues(&vblk->tag_set, vblk->num_vqs);
>>> >> +
>>> >>  	virtio_device_ready(vdev);
>>> >>  
>>> >>  	blk_mq_start_stopped_hw_queues(vblk->disk->queue, true);
>>> >>
>> > 
>> > This should never happen; it'd be a configuration problem.
>> > 
> Do you mean all hosts have to be configured with the same number of ->num_vqs?
> What about cases like migrating a guest from HostA to HostB while HostB is much more powerful
> and would like to run more hardware queues to get better performance.

The number of queues should be equal to the number of CPUs for the
guest, not to the number of CPUs or queues on the host.  The idea is to
have one queue per guest vCPU.

Paolo