Linux Virtualization - Jul 2015 - [Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio

On 2015/7/30 3:16, Michael S. Tsirkin wrote:
> ACPI spec 5.0 allows the use of PCI vendor IDs.
> 
But virtio-mmio is not a PCI device, it's a platform device.
Why do we drop the previous way using "QEMUXXXX"? Something I missed?
> Since we have one for virtio, it seems neater to use that
> rather than LNRO. For the device ID, use 103F which is a legacy ID that
> isn't used in virtio PCI spec - seems to make sense since virtio-mmio
is
> a legacy device but we don't know the correct device type.
> 
> Guests should probably match everything in the range 1000-103F
> (just like legacy pci drivers do) which will allow us to pass in the
> actual ID in the future if we want to.
> 
> Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
> ---
>  hw/arm/virt-acpi-build.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index f365140..dea61ba 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope,
>  
>      for (i = 0; i < num; i++) {
>          Aml *dev = aml_device("VR%02u", i);
> -        aml_append(dev, aml_name_decl("_HID",
aml_string("LNRO0005")));
> +        aml_append(dev, aml_name_decl("_HID",
aml_string("1AF4103F")));
>          aml_append(dev, aml_name_decl("_UID", aml_int(i)));
>  
>          Aml *crs = aml_resource_template();
> 
-- 
Shannon

On 2015/7/30 16:04, Michael S. Tsirkin wrote:
> On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote:
>>
>>
>> On 2015/7/30 3:16, Michael S. Tsirkin wrote:
>>> ACPI spec 5.0 allows the use of PCI vendor IDs.
>>>
>> But virtio-mmio is not a PCI device, it's a platform device.
> 
> Yes. ACPI spec 5.0 says:
> 
> 	A valid PNP ID must be of the form "AAA####" where A is an
uppercase
> 	letter and # is a hex digit. A valid ACPI ID must be of the form
> 	"NNNN####" where N is an uppercase letter or a digit
('0'-'9') and # is
> 	a hex digit. This specification reserves the string "ACPI" for
use only
> 	with devices defined herein.
> 
> 	It further reserves all strings representing 4 HEX digits for
> 	exclusive use with PCI-assigned Vendor IDs.
> 
> The second paragraph means if PCI SIG assigned you an ID, you
> can use that without need to register it with ASWG.
> 
> 
>> Why do we drop the previous way using "QEMUXXXX"? Something I
missed?
> 
> So that guests that bind to this interface will work fine with non QEMU
> implementations of virtio-mmio.
> 
I think kernel driver supports multiple IDs. If they don't want to
"QEMUXXXX" as ACPI ID, it's free to add a new one like below.

+static const struct acpi_device_id virtio_mmio_acpi_match[] = {
+       { "QEMU0005", },
+       { "1AF4103F", },
+	{ }
+};
+MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> It's just playing nice with others.
> 
> We could have done something similar to pvpanic as well, except we
> didn't and guests using the QEMU prefix have been released,
> so we have to keep using that.
> 
>>> Since we have one for virtio, it seems neater to use that
>>> rather than LNRO. For the device ID, use 103F which is a legacy ID
that
>>> isn't used in virtio PCI spec - seems to make sense since
virtio-mmio is
>>> a legacy device but we don't know the correct device type.
>>>
>>> Guests should probably match everything in the range 1000-103F
>>> (just like legacy pci drivers do) which will allow us to pass in
the
>>> actual ID in the future if we want to.
>>>
>>> Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
>>> ---
>>>  hw/arm/virt-acpi-build.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>>> index f365140..dea61ba 100644
>>> --- a/hw/arm/virt-acpi-build.c
>>> +++ b/hw/arm/virt-acpi-build.c
>>> @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope,
>>>  
>>>      for (i = 0; i < num; i++) {
>>>          Aml *dev = aml_device("VR%02u", i);
>>> -        aml_append(dev, aml_name_decl("_HID",
aml_string("LNRO0005")));
>>> +        aml_append(dev, aml_name_decl("_HID",
aml_string("1AF4103F")));
>>>          aml_append(dev, aml_name_decl("_UID",
aml_int(i)));
>>>  
>>>          Aml *crs = aml_resource_template();
>>>
>>
>> -- 
>> Shannon
> 
> .
> 
-- 
Shannon

On 30 July 2015 at 09:04, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote:
>>
>> Why do we drop the previous way using "QEMUXXXX"? Something I
missed?
>
> So that guests that bind to this interface will work fine with non QEMU
> implementations of virtio-mmio.
I don't understand this sentence. If there are pre-existing
non-QEMU virtio-mmio implementations, then they're using
LNRO0005, and we should use it too. If there are going to
be implementations of virtio-mmio in future, then they will
use whatever identifier we pick here. Either way, we get
interoperability. I don't see any difference between our
saying "the ID for virtio-mmio is QEMU0005" and saying
"the ID for virtio-mmio is 1AF4103F".

(The latter seems unnecessarily opaque to me, to be honest.
At least an ID string QEMUxxxx gives you a clue where to
look for who owns the thing.)

Note also that strictly you don't mean "non-QEMU implementations
of virtio-mmio", you mean "non-QEMU implementations of the
ACPI tables". The hardware implementation of virtio-mmio
doesn't care at all about the ACPI ID. (In fact the most
plausible other-implementation would be UEFI using its
own (hard-coded) ACPI tables on top of a QEMU vexpress-a15
model or something similar.)

-- PMM