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.mayd...@linaro.org>
>>> Cc: Shannon Zhao <zhaoshengl...@huawei.com>
>>> Cc: "Michael S. Tsirkin" <m...@redhat.com>
>>> Signed-off-by: Eduardo Habkost <ehabk...@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 <ler...@redhat.com>
>
> Thanks!
>
