search for: 103f

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 pci drivers do) which will allow us to pass in the...

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 pci drivers do) which will allow us to pass in the...

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

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

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

On 29 July 2015 at 20:16, Michael S. Tsirkin <mst at redhat.com> wrote: > 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 pci drivers do) which will...

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