Displaying 7 results from an estimated 7 matches for "qemu0005".
2015 Jul 30
3
[Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio
..., 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-m...
2015 Jul 30
3
[Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio
..., 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-m...
2015 Jul 30
2
[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
>
2015 Jul 30
1
[Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio
...ll 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,...
2015 Jul 30
1
[Qemu-devel] [PATCH v2] arm: change vendor ID for virtio-mmio
...ll 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,...
2015 Jul 28
2
[PATCH] virtio_mmio: add ACPI probing
On 28 July 2015 at 11:27, Michael S. Tsirkin <mst at redhat.com> wrote:
> On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote:
>> On 28 July 2015 at 11:08, Michael S. Tsirkin <mst at redhat.com> wrote:
>> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
>> >> Added the match table and pointers for ACPI probing to the driver.
2015 Jul 28
2
[PATCH] virtio_mmio: add ACPI probing
On 28 July 2015 at 11:27, Michael S. Tsirkin <mst at redhat.com> wrote:
> On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote:
>> On 28 July 2015 at 11:08, Michael S. Tsirkin <mst at redhat.com> wrote:
>> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
>> >> Added the match table and pointers for ACPI probing to the driver.