From: Anthony Liguori <anthony@codemonkey.ws>
To: Ian Campbell <Ian.Campbell@citrix.com>,
Paul Durrant <Paul.Durrant@citrix.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Citrix PV Bus device [V3]
Date: Wed, 03 Jul 2013 08:45:22 -0500 [thread overview]
Message-ID: <871u7fahal.fsf@codemonkey.ws> (raw)
In-Reply-To: <1372840803.27768.159.camel@zakaz.uk.xensource.com>
Ian Campbell <Ian.Campbell@citrix.com> writes:
> On Wed, 2013-07-03 at 09:34 +0100, Paul Durrant wrote:
>> Already did that :-)
>>
>> > There are also sub-vendor and sub-device IDs but I don't think they are
>> > so useful for us (AFAIK they are intended to allow the board
>> > manufacturer to "subclass" the IDs baked into the ASIC).
>> >
>>
>> I'm always hazy about what those mean. I thought the idea was that a
>> vendor may collect together many devices, potentially from different
>> vendors, into a single chip/board and they should use common subsystem
>> vendor/device info for all those devices to indicate that they were
>> all part of that larger unit - but maybe I'm completely wrong.
>
> I figured it was so the board vendor could add "value" in their drivers
> by taking advantage of the higher precedence given to the binding to the
> sub-ids by OSs.
It's essentially an OEM id. Often times it's an EEPROM setting on real
hardware. A different subsystem vendor/device does not indicate a
different programming interface.
We set it to a vendor/device ID reserved for QEMU by default. It's best
to keep it the QEMU ID to identify it as a device implemented by QEMU.
It's mighty handy as it lets software figure out that it's a Cirrus VGA
card emulated by QEMU (not real hardware). In fact, I believe the
kernel KMS driver for Cirrus only binds to the QEMU vendor/device ID
since that's the only thing reasonably testable these days.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2013-07-03 13:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 15:36 [Qemu-devel] [PATCH] Citrix PV Bus device [V3] Paul Durrant
2013-07-02 16:42 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini
2013-07-02 18:05 ` Stefano Stabellini
2013-07-02 18:31 ` Anthony Liguori
2013-07-03 8:28 ` Ian Campbell
2013-07-03 8:34 ` Paul Durrant
2013-07-03 8:40 ` Ian Campbell
2013-07-03 13:45 ` Anthony Liguori [this message]
2013-07-03 13:49 ` Ian Campbell
2013-07-03 7:58 ` Paul Durrant
2013-07-03 10:49 ` Stefano Stabellini
2013-07-03 10:57 ` Paul Durrant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871u7fahal.fsf@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Ian.Campbell@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).