search for: aswg

...{ >> }; >> 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 looking for......

...{ >> }; >> 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 looking for......

...;> >> >> >> +#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...

...;> >> >> >> +#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...

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

...ly on UEFI and ACPICA. > > Copy paste Erik's initial response below on how to get a new table, > seems to confirm with the process you stated above. > > "Fairly easy. You reserve a 4-letter symbol by sending a message > requesting to reserve the signature to Mike or the ASWG mailing list or > info at acpi.info Great! I think this is going to be the path forward here. Regards, Joerg > > There is also another option. You can have ASWG own this new table so > that not one entity or company owns the new table."

...>> +#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 ACP...

...ng less official. The table is > constructed by QEMU and read by the kernel (and 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/sit...

...ng less official. The table is > constructed by QEMU and read by the kernel (and 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/sit...

...inaro.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 already fixed...

...inaro.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 already fixed...

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

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

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

...atic 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, > .re...

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

...I agree with Peter. Maybe we should record these IDs at some place. Right. And it should apply even if you keep using LNRO. Pls create docs/specs/acpi_ids.txt and list them there. For simplicity, I'd just replace LNRO with QEMU. > 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. So far we only had PVPANIC with ACPI ID QEMU0001. > P.S. I don't see "QEMU&quo...

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