[0/2] block: add blk_lookup() for getting device by node_name

Message

Anton Kuchin Jan. 28, 2019, 2:27 p.m. UTC

Some HMP and QMP commands are targeting BlockBackend but
for hotplugged devices name of BB is deprecated, instead
name of root BlockDriverState is set. These patches add
functions to search BB by attached root BDS name.

This approach isn't perfect, but I couldn't invent a better
one and I belive it's more convinient than accessing BB
by QOM path.

Anton Kuchin (2):
  block: add functions to search BlockBackend by root BDS name
  block: migrate callers from blk_by_name to blk_lookup

 block/block-backend.c          | 29 +++++++++++++++++++++++++++++
 blockdev-nbd.c                 |  2 +-
 blockdev.c                     |  6 +++---
 hmp.c                          |  2 +-
 include/sysemu/block-backend.h |  7 +++++++
 5 files changed, 41 insertions(+), 5 deletions(-)

Comments

Kevin Wolf Jan. 28, 2019, 2:47 p.m. UTC | #1

Am 28.01.2019 um 15:27 hat Anton Kuchin geschrieben:
> Some HMP and QMP commands are targeting BlockBackend but
> for hotplugged devices name of BB is deprecated, instead
> name of root BlockDriverState is set. These patches add
> functions to search BB by attached root BDS name.
> 
> This approach isn't perfect, but I couldn't invent a better
> one and I belive it's more convinient than accessing BB
> by QOM path.

There could be more than one BlockBackend attached to a single node, so
this approach is simply wrong.

I think the qdev ID is actually not only a pretty convenient way, but in
fact the only logical way to address a guest device (and BlockBackends
that can be accessed by the monitor are essentially a part of the guest
device).

Does your series allow to perform any operation that isn't possible
currently? If so, it's probably this operation that needs to be fixed to
either accept node names (if it's a backend operation) or a device ID
(if it's a frontend operation).

Kevin

Anton Kuchin Jan. 28, 2019, 4:53 p.m. UTC | #2

On 28/01/2019 17:47, Kevin Wolf wrote:
> Am 28.01.2019 um 15:27 hat Anton Kuchin geschrieben:
>> Some HMP and QMP commands are targeting BlockBackend but
>> for hotplugged devices name of BB is deprecated, instead
>> name of root BlockDriverState is set. These patches add
>> functions to search BB by attached root BDS name.
>>
>> This approach isn't perfect, but I couldn't invent a better
>> one and I belive it's more convinient than accessing BB
>> by QOM path.
> There could be more than one BlockBackend attached to a single node, so
> this approach is simply wrong.

I was thinking about this but couldn't imagine configuration when it's 
having more than one root. Can you give an example, please, so I 
understand this case better.

> I think the qdev ID is actually not only a pretty convenient way, but in
> fact the only logical way to address a guest device (and BlockBackends
> that can be accessed by the monitor are essentially a part of the guest
> device).

As far as I remember backends currently have emply qdev ID so the only 
way to address them now is QOM path like 
".../my_hotplug_drive/virtio-backend". So I have to remember the name of 
the root driver it is connected to and also add this "/virtio-backend" 
suffix.

Can you explain a bit what are "monitor referenced" backends and which 
one can be accessed from monitor and which can not.

> Does your series allow to perform any operation that isn't possible
> currently? If so, it's probably this operation that needs to be fixed to
> either accept node names (if it's a backend operation) or a device ID
> (if it's a frontend operation).

Yes. It fixes latency histogram setting, nbd server binding to remove 
event and a couple of hmp comands. I also suspect that this can affect 
migration but I could't figure out what name is used for identifying drives.

Some of this code is also linked to utilities (qemu-img, qemu-io-cmds 
...) which require linking all QAPI stuff to them, that seems to be an 
overkill. I'll prepare the patch to eliminate this dependency and allow 
using QOM here if we decide that this is the best way.

> Kevin
>

Kevin Wolf Jan. 28, 2019, 6:02 p.m. UTC | #3

Am 28.01.2019 um 17:53 hat Anton Kuchin geschrieben:
> On 28/01/2019 17:47, Kevin Wolf wrote:
> > Am 28.01.2019 um 15:27 hat Anton Kuchin geschrieben:
> > > Some HMP and QMP commands are targeting BlockBackend but
> > > for hotplugged devices name of BB is deprecated, instead
> > > name of root BlockDriverState is set. These patches add
> > > functions to search BB by attached root BDS name.
> > > 
> > > This approach isn't perfect, but I couldn't invent a better
> > > one and I belive it's more convinient than accessing BB
> > > by QOM path.
> > There could be more than one BlockBackend attached to a single node, so
> > this approach is simply wrong.
> 
> I was thinking about this but couldn't imagine configuration when it's
> having more than one root. Can you give an example, please, so I understand
> this case better.

You can configure such setups explicitly by just using the same -device
drive=node-name twice, though I admit this is unusual.

The more practical case are internal BlockBackends for use by block jobs
or the NBD server. In that case, the user might modify a completely
different BlockBackend than they had in mind.

> > I think the qdev ID is actually not only a pretty convenient way, but in
> > fact the only logical way to address a guest device (and BlockBackends
> > that can be accessed by the monitor are essentially a part of the guest
> > device).
> 
> As far as I remember backends currently have emply qdev ID so the only way
> to address them now is QOM path like ".../my_hotplug_drive/virtio-backend".
> So I have to remember the name of the root driver it is connected to and
> also add this "/virtio-backend" suffix.

virtio-blk is ugly, indeed, because the device is split in two halves
and the half with the assigned ID isn't the half that owns the
BlockBackend. But the paths are relative to /machine/peripheral, so I
think just "my_hotplug_drive/virtio-backend" should work.

For all other devices, it's just the ID, as far as I know.

> Can you explain a bit what are "monitor referenced" backends and which one
> can be accessed from monitor and which can not.

The user isn't supposed to access internal BlockBackends, like those of
block jobs and the NBD server.

> > Does your series allow to perform any operation that isn't possible
> > currently? If so, it's probably this operation that needs to be fixed to
> > either accept node names (if it's a backend operation) or a device ID
> > (if it's a frontend operation).
> 
> Yes. It fixes latency histogram setting, nbd server binding to remove event
> and a couple of hmp comands. I also suspect that this can affect migration
> but I could't figure out what name is used for identifying drives.

qmp_x_block_latency_histogram_set() uses blk_by_name() to get the
BlockBackend. The fix is to make it use qmp_get_blk() instead.

I'm not sure what the exact NBD thing is you mean.

Kevin