Re: [QEMU HCI-8.0 PATCH 4/5] vhost-blk: watch the device for resize events

[Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com>]

On 9/3/26 17:45, Andrey Drobyshev wrote:
> On 9/3/26 6:30 PM, Andrey Zhadchenko wrote:
>>
>>
>> On 9/3/26 16:56, Andrey Drobyshev wrote:
>>> The approach introduced by this and subsequent patches, i.e. subscribing
>>> to NETLINK_KOBJECT_UEVENT and filtering them - that looks very kludgy
>>> for production and will unlikely be ever accepted upstream.
>>
>> I also think qmp command is much cleaner.
>>
>>>
>>> So, QEMU must get the knowledge about updated size.  It can only do so
>>> by getting this knowledge from libvirt (as it used to be with
>>> qmp_block_resize) or from the kernel via some kind of notification.
>>
>> Updated size can be read again with llseek/BLKSZGET. I would avoid
>> passing it into QEMU explicitly via QMP (we also don't pass it during
>> the start, so it matches)
> 
> Currently libvirt calls QMP block-resize which has size as an explicit
> argument.  You're saying we should just issue a command with no args,
> smth like 'qmp_trigger_size_reread'.  That's generally fine, but what if
> for some reason final size which we get by lseek() doesn't match what
> was requested from libvirt? When passing an argument we can at least
> compare the expectation vs reality and emit an error.

I don't think that detecting size mismatch makes much sense. It won't 
protect us against concurrent resize anyway (it can happen after lseek, 
etc.) and just increase the amount of code.
In my opinion it is perfectly fine to infer the size from the device 
instead of doing it + also checking against user input.

> 
>>
>>>
>>> So our options:
>>>
>>> 1. Another QMP command sent directly from libvirt, smth like
>>> 'vhost-blk-config-update id=virtio-disk0 data={...}'
>>>
>>> 2. Patching the kernel so it knows the size, caches it.  Making ploop
>>> send an ioctl to inform the kernel about new size.  Then establishing
>>> eventfd from vhost-blk backend -> qemu, and processing the events.
>>>
>>> I think 1st is cleaner and requires less work.
>>>
>>> Andrey
>>>
>>
>