qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

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