Re: [Qemu-devel] [RFC 19/19] virtio-mmio: Remove user_creatable flag

[Laszlo Ersek]

On 04/04/17 21:35, Eduardo Habkost wrote:
> On Mon, Apr 03, 2017 at 05:50:13PM +0200, Laszlo Ersek wrote:
>> On 04/01/17 02:46, Eduardo Habkost wrote:
>>> virtio-mmio needs to be wired and mapped by other device or board
>>> code, and won't work with -device. Remove the user_creatable flag
>>> from the device class.
>>>
>>> Cc: Peter Maydell <address@hidden>
>>> Cc: Shannon Zhao <address@hidden>
>>> Cc: "Michael S. Tsirkin" <address@hidden>
>>> Signed-off-by: Eduardo Habkost <address@hidden>
>>> ---
>>>  hw/virtio/virtio-mmio.c | 5 -----
>>>  1 file changed, 5 deletions(-)
>>>
>>> diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
>>> index b595512a3d..5807aa87fe 100644
>>> --- a/hw/virtio/virtio-mmio.c
>>> +++ b/hw/virtio/virtio-mmio.c
>>> @@ -450,11 +450,6 @@ static void virtio_mmio_class_init(ObjectClass *klass, 
>>> void *data)
>>>      dc->reset = virtio_mmio_reset;
>>>      set_bit(DEVICE_CATEGORY_MISC, dc->categories);
>>>      dc->props = virtio_mmio_properties;
>>> -    /*
>>> -     * FIXME: Set only for compatibility on q35 machine-type.
>>> -     * Probably never meant to be user-creatable
>>> -     */
>>> -    dc->user_creatable = true;
>>>  }
>>>  
>>>  static const TypeInfo virtio_mmio_info = {
>>>
>>
>> Possible addition to the commit message: a reference to commit
>> 587078f0ed63 ("hw/arm/virt: explain device-to-transport mapping in
>> create_virtio_devices()", 2015-02-05).
> 
> I'm confused by the comments there: it says "Unfortunately, we
> can't counteract the kernel change by reversing the loop; it
> would break existing command lines". But, which comment-lines it
> would break,

Reversing the order in which the platform code generates the virtio-mmio
transports would break guest kernel command lines that identify the root
filesystem by virtio device name, such as /dev/vda1 vs. /dev/vdb1.

And, a QEMU command line can actually contain the guest kernel command
line; consider -kernel / -initrd / -append. In that sense, if you break
the guest kernel command line, you break the QEMU command line as well.

> if "-device virtio-mmio" was never supported?

The relevant "-device" options on the qemu command line are not "-device
virtio-mmio"; they are "-device virtio-blk-device". QEMU first
auto-generates the virtio-mmio transports, then assigns those virtio
block devices to the transports. The comment documents the interplay between
- order of virtio mmio transport creation (QEMU),
- order of assigning virtio block devices to transports (QEMU),
- order of naming disks based on transport address (guest kernel).

Anyway, it's not important to include a reference to commit 587078f0ed63.

Thanks
Laszlo

> 
>>
>> That's another example showing that board code has to participate in
>> virtio-mmio transport placement.
>>
>> Reviewed-by: Laszlo Ersek <address@hidden>
> 
> Thanks!
>