From: Denis Plotnikov <dplotnikov@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
"berrange@redhat.com" <berrange@redhat.com>,
"ehabkost@redhat.com" <ehabkost@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"mreitz@redhat.com" <mreitz@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
Denis Lunev <den@virtuozzo.com>
Subject: Re: [PATCH v0 2/2] block: allow to set 'drive' property on a realized block device
Date: Mon, 16 Dec 2019 15:58:05 +0000 [thread overview]
Message-ID: <089551c1-54d0-dd75-1700-2bfd1c49eebe@virtuozzo.com> (raw)
In-Reply-To: <20191216153823.GD6610@linux.fritz.box>
On 16.12.2019 18:38, Kevin Wolf wrote:
> Am 16.12.2019 um 15:51 hat Denis Plotnikov geschrieben:
>> On 13.12.2019 13:32, Kevin Wolf wrote:
>>> Am 18.11.2019 um 11:50 hat Denis Plotnikov geschrieben:
>>>> Another problem here, is that the "size" of the device dev may not match
>>>> after setting a drive.
>>>> So, we should update it after the drive setting.
>>>> It was found, that it could be done by calling
>>>> BlockDevOps.bdrv_parent_cb_resize.
>>>>
>>>> But I have some concerns about doing it so. In the case of virtio scsi
>>>> disk we have the following callstack
>>>>
>>>> bdrv_parent_cb_resize calls() ->
>>>> scsi_device_report_change(dev, SENSE_CODE(CAPACITY_CHANGED)) ->
>>>> virtio_scsi_change ->
>>>> virtio_scsi_push_event(s, dev, VIRTIO_SCSI_T_PARAM_CHANGE,
>>>> sense.asc |
>>>> (sense.ascq << 8));
>>> I think the safest option for now (and which should solve the case you
>>> want to address) is checking whether old and new size match and
>>> returning an error otherwise.
>>>
>>>> virtio_scsi_change pushes the event to the guest to make the guest
>>>> ask for size refreshing. If I'm not mistaken, here we can get a race
>>>> condition when some another request is processed with an unchanged
>>>> size and then the size changing request is processed.
>>> I think this is actually a problem even without resizing: We need to
>>> quiesce the device between removing the old root and inserting the new
>>> one. They way to achieve this is probably by splitting blk_drain() into
>>> a blk_drain_begin()/end() and then draining the BlockBackend here while
>>> we're working on it.
>>>
>>> Kevin
>> Why don't we use bdrv_drained_begin/end directly? This is what
>> blk_drain does.
>> If we want to split blk_drain we must keep track if blk's brdv isn't
>> change otherwise we can end up with drain_begin one and drain end
>> another bdrv if we do remove/insert in between.
> Hmm, true, we would have to keep track of draining at the BlockBackend
> level and consider it in blk_remove_bs() and blk_insert_bs(). Maybe
> that's not worth it.
>
> If we use bdrv_drained_begin/end directly, I think we need to drain both
> the old and the new root node during the process.
>
>> Another thing is should we really care about this if we have VM
>> stopped and the sizes matched?
> How do we know that the VM is stopped? And why would we require this?
I implied the scenario of VM migration over a shared storage with an
exclusive file access model.
The VM is stopped on drive changing phase.
If there is no use to require it, than ok.
Denis
> Your patch doesn't implement or at least check this, and it seems a bit
> impractical for example when all you want is inserting a filter node.
>
> Kevin
next prev parent reply other threads:[~2019-12-16 15:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-10 19:03 [PATCH v0 0/2] allow to set 'drive' property on a realized block device Denis Plotnikov
2019-11-10 19:03 ` [PATCH v0 1/2] qdev-properties-system: extend set_pionter for unrealized devices Denis Plotnikov
2019-11-18 18:54 ` Eduardo Habkost
2019-11-22 11:36 ` Denis Plotnikov
2019-11-25 15:30 ` Eduardo Habkost
2019-11-26 6:49 ` Denis Plotnikov
2019-11-26 16:38 ` Kevin Wolf
2019-11-10 19:03 ` [PATCH v0 2/2] block: allow to set 'drive' property on a realized block device Denis Plotnikov
2019-11-10 19:08 ` Denis Plotnikov
2019-11-18 10:50 ` Denis Plotnikov
2019-12-13 7:30 ` [PING]Re: " Denis Plotnikov
2019-12-13 10:32 ` Kevin Wolf
2019-12-16 14:51 ` Denis Plotnikov
2019-12-16 15:38 ` Kevin Wolf
2019-12-16 15:58 ` Denis Plotnikov [this message]
2019-11-18 10:30 ` [PATCH v0 0/2] " Denis Plotnikov
2020-03-02 13:38 ` Kevin Wolf
2020-03-02 13:55 ` Denis Plotnikov
2020-03-02 15:39 ` Kevin Wolf
2020-03-03 7:43 ` Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=089551c1-54d0-dd75-1700-2bfd1c49eebe@virtuozzo.com \
--to=dplotnikov@virtuozzo.com \
--cc=berrange@redhat.com \
--cc=den@virtuozzo.com \
--cc=ehabkost@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).