[RFC,19/19] virtio-mmio: Remove user_creatable flag

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 <peter.maydell@linaro.org>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 hw/virtio/virtio-mmio.c | 5 -----
 1 file changed, 5 deletions(-)

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 <peter.maydell@linaro.org>
> Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  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).

That's another example showing that board code has to participate in
virtio-mmio transport placement.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

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 <peter.maydell@linaro.org>
> > Cc: Shannon Zhao <zhaoshenglong@huawei.com>
> > Cc: "Michael S. Tsirkin" <mst@redhat.com>
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> >  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, if "-device virtio-mmio" was never supported?

> 
> That's another example showing that board code has to participate in
> virtio-mmio transport placement.
> 
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks!

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 <peter.maydell@linaro.org>
>>> Cc: Shannon Zhao <zhaoshenglong@huawei.com>
>>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>>> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>>> ---
>>>  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 <lersek@redhat.com>
> 
> Thanks!
>