search for: qemuxxxx

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...

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...

..._match); >> >> >> >> +#ifdef CONFIG_ACPI >> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> >> + { "LNRO0005", }, >> >> + { } >> >> +}; >> > >> > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. >> > >> > Pater - do you think it's a good idea to change this before QEMU 2.4 >> > is released? >> >> Shannon's call, I guess. I don't know enough about ACPI to say. >> I thought these ACPI IDs were alrea...

..._match); >> >> >> >> +#ifdef CONFIG_ACPI >> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> >> + { "LNRO0005", }, >> >> + { } >> >> +}; >> > >> > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. >> > >> > Pater - do you think it's a good idea to change this before QEMU 2.4 >> > is released? >> >> Shannon's call, I guess. I don't know enough about ACPI to say. >> I thought these ACPI IDs were alrea...

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 co...

...o_match[] = { >> }; >> MODULE_DEVICE_TABLE(of, virtio_mmio_match); >> >> +#ifdef CONFIG_ACPI >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> + { "LNRO0005", }, >> + { } >> +}; > > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. > > Pater - do you think it's a good idea to change this before QEMU 2.4 > is released? Shannon's call, I guess. I don't know enough about ACPI to say. I thought these ACPI IDs were already fixed because they were what the kernel was lookin...

...o_match[] = { >> }; >> MODULE_DEVICE_TABLE(of, virtio_mmio_match); >> >> +#ifdef CONFIG_ACPI >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> + { "LNRO0005", }, >> + { } >> +}; > > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. > > Pater - do you think it's a good idea to change this before QEMU 2.4 > is released? Shannon's call, I guess. I don't know enough about ACPI to say. I thought these ACPI IDs were already fixed because they were what the kernel was lookin...

...her 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...

...her 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...

ACPI spec 5.0 allows the use of PCI vendor IDs. 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

ACPI spec 5.0 allows the use of PCI vendor IDs. 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

On 28 July 2015 at 11:33, G Gregory <graeme.gregory at linaro.org> wrote: > We assigned LNRO in ASWG to avoid collisions with our prototypes/real > platforms so it makes sense to me to switch to QEMUXXXX. So just to check, if we switch virtio-mmio from an LNRO0005 ID to a QEMUxxxx ID we aren't going to break any existing widely shipped or deployed code, right? If we can change the ID without breaking anything significant then I think the QEMU ID makes more sense; but it doesn't really gai...

...gt;>> >> +#ifdef CONFIG_ACPI >>> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >>> >> + { "LNRO0005", }, >>> >> + { } >>> >> +}; >>> > >>> > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. >>> > >>> > Pater - do you think it's a good idea to change this before QEMU 2.4 >>> > is released? >>> >>> Shannon's call, I guess. I don't know enough about ACPI to say. >>> I thought t...

...possibly > also by UEFI?), so everybody needs to agree on what the > string is... I agree with Peter. Maybe we should record these IDs at some place. Since QEMU is owner of this device and we register QEMU in ASWG, the official ID can be assigned by QEMU and the ID could(or should) be "QEMUXXXX". But what's the exact ID for this virtio-mmio? That's what we need to agree on and record. P.S. I don't see "QEMU" in the list of approved Vendor IDs for ACPI. http://www.uefi.org/sites/default/files/resources/PNPID_List.pdf http://www.uefi.org/sites/default/files/resou...

...possibly > also by UEFI?), so everybody needs to agree on what the > string is... I agree with Peter. Maybe we should record these IDs at some place. Since QEMU is owner of this device and we register QEMU in ASWG, the official ID can be assigned by QEMU and the ID could(or should) be "QEMUXXXX". But what's the exact ID for this virtio-mmio? That's what we need to agree on and record. P.S. I don't see "QEMU" in the list of approved Vendor IDs for ACPI. http://www.uefi.org/sites/default/files/resources/PNPID_List.pdf http://www.uefi.org/sites/default/files/resou...

...gregory at linaro.org> >> >> +#ifdef CONFIG_ACPI >> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> >> + { "LNRO0005", }, >> >> + { } >> >> +}; >> > >> > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. >> > >> > Pater - do you think it's a good idea to change this before QEMU 2.4 >> > is released? >> >> Shannon's call, I guess. I don't know enough about ACPI to say. >> I thought these ACPI IDs were alrea...

...gregory at linaro.org> >> >> +#ifdef CONFIG_ACPI >> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> >> + { "LNRO0005", }, >> >> + { } >> >> +}; >> > >> > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. >> > >> > Pater - do you think it's a good idea to change this before QEMU 2.4 >> > is released? >> >> Shannon's call, I guess. I don't know enough about ACPI to say. >> I thought these ACPI IDs were alrea...

Added the match table and pointers for ACPI probing to the driver. This uses the same identifier for virt devices as being used for qemu ARM64 ACPI support. http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org> --- drivers/virtio/virtio_mmio.c | 10 ++++++++++ 1 file changed, 10

Added the match table and pointers for ACPI probing to the driver. This uses the same identifier for virt devices as being used for qemu ARM64 ACPI support. http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org> --- drivers/virtio/virtio_mmio.c | 10 ++++++++++ 1 file changed, 10

...733,21 @@ static struct of_device_id virtio_mmio_match[] = { > }; > MODULE_DEVICE_TABLE(of, virtio_mmio_match); > > +#ifdef CONFIG_ACPI > +static const struct acpi_device_id virtio_mmio_acpi_match[] = { > + { "LNRO0005", }, > + { } > +}; Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. Pater - do you think it's a good idea to change this before QEMU 2.4 is released? > +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); > +#endif > + > static struct platform_driver virtio_mmio_driver = { > .probe = virtio_mmio_probe, &g...