On 02/08/21 06:34, schspa wrote:
> On Fri, 2021-02-05 at 15:08 +0100, Edgar E. Iglesias wrote:
>> Thanks, that matches how I thought things should work.
>>
>> I wonder if virtio_mmio_bus_get_dev_path() really should be peeking
>> into
>> Sysbus internals mmio[].addr?
>>
> I think mmio[].addr needs to be given a meaningful value even if we
> don't use it.
>
>> Sysbus mmio[].addr looks like a candidate for removal if we ever get
>> rid
>> of the default system_memory...
>>
>> I don't have any good suggestions how to fix this. I guess we could
>> wrap
>> memory_region_add_subregion() with a sysbus version of it that sets
>> mmio[].addr but that seems like a step backwards to me.
>> Perhaps there's a way fix this in virtio_mmio_bus_get_dev_path()?
>
> I think we can change virtio_mmio_bus_get_dev_path() with the following
> methods.
>
> 1. modify TYPE_VIRTIO_MMIO:
> add a prop to specify a unique device_path for virtio_mmio TypeInfo.
> 2. modify TYPE_VIRTIO_MMIO_BUS
> add a global static instance count to generate a unique device path.
>
Please don't CC me out of the blue mid-thread, without at least a hint
as to why the thread could be relevant to me.
If you are CC'ing me because I authored f58b39d2d5b6 ("virtio-mmio:
format transport base address in BusClass.get_dev_path", 2016-07-14),
for <https://bugs.launchpad.net/qemu/+bug/1594239>, *and* now this patch
is deemed incorrect or obsolete, then:
Feel free to do whatever you want with those functions, as long as
(a) the entries in the "bootorder" fw_cfg file remain intact,
(b) LP#1594239 remains fixed.
Thanks
Laszlo
