Re: [Qemu-block] [PATCH 1/2] xen: add xen disk naming for use in monitor

[Bruce Rogers]

>>> On 6/13/2018 at 5:46 AM, Anthony PERARD <address@hidden> wrote:
> On Tue, Jun 12, 2018 at 05:51:02PM ‑0600, Bruce Rogers wrote:
>> Provide monitor naming of xen disks, including associating an
>> attached dev_id for a BlockBackend which has legacy_dev set.
>> Currently, only xen disks have legacy_dev set to true.
>> 
>> Signed‑off‑by: Bruce Rogers <address@hidden>
>> ‑‑‑
>>  block/block‑backend.c |  5 ++++‑
>>  hw/block/xen_disk.c   | 15 +++++++++++++++
>>  include/hw/xen/xen.h  |  2 ++
>>  stubs/xen‑common.c    |  5 +++++
>>  4 files changed, 26 insertions(+), 1 deletion(‑)
>> 
>> diff ‑‑git a/block/block‑backend.c b/block/block‑backend.c
>> index d55c328736..db39dfe867 100644
>> ‑‑‑ a/block/block‑backend.c
>> +++ b/block/block‑backend.c
>> @@ ‑23,6 +23,7 @@
>>  #include "qemu/option.h"
>>  #include "trace.h"
>>  #include "migration/misc.h"
>> +#include "hw/xen/xen.h"
>>  
>>  /* Number of coroutines to reserve per attached device model */
>>  #define COROUTINE_POOL_RESERVATION 64
>> @@ ‑895,7 +896,9 @@ char *blk_get_attached_dev_id(BlockBackend *blk)
>>  {
>>      DeviceState *dev;
>>  
>> ‑    assert(!blk‑>legacy_dev);
>> +    if (blk‑>legacy_dev) {
>> +        return xen_blk_get_attached_dev_id(blk‑>dev);
>> +    }
>>      dev = blk‑>dev;
>>  
>>      if (!dev) {
> 
> Hi Bruce,
> 
> Thanks for your patches!
> 
> But I don't think that the right way to go. We probably needs to
> qdevifie xen_disk instead. This is point out by the numerous TODO about
> "qdevified", and this very old mail:
> https://lists.nongnu.org/archive/html/qemu‑devel/2016‑09/msg07902.html 

Understood. These patches come from an effort to provide this functionality
to older qemu releases that SUSE supports. I didn't try to work on a qdevify 
type
solution, as I figured if the block experts hadn't done that yet, I would 
probably
not be too successful myself.
>From what I can see, the xen support in qemu is not well integrated in general,
so my patches here are implemented in that "spirit" - not elegant, but getting 
the
job done. I'd certainly rather see good integration of the xen model into qemu,
and if that is the right way forward to get this type of functionality, I'd be 
happy
with that approach as well.

Bruce