From: Kevin Wolf <kwolf@redhat.com>
To: Denis Plotnikov <dplotnikov@virtuozzo.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 16:38:23 +0100 [thread overview]
Message-ID: <20191216153823.GD6610@linux.fritz.box> (raw)
In-Reply-To: <e982f384-0d94-7519-8cb1-48208025217a@virtuozzo.com>
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?
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:40 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 [this message]
2019-12-16 15:58 ` Denis Plotnikov
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=20191216153823.GD6610@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=berrange@redhat.com \
--cc=den@virtuozzo.com \
--cc=dplotnikov@virtuozzo.com \
--cc=ehabkost@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).