qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/2] add pci-serial device.
Date: Thu, 27 Sep 2012 07:53:47 +0200	[thread overview]
Message-ID: <5063E9EB.2020009@redhat.com> (raw)
In-Reply-To: <87wqzhuedo.fsf@codemonkey.ws>

  Hi,

> Understood, but I'd really prefer a file in docs/.  We should be
> rigorous about having formal specs for all of our paravirtual devices.
> The code shouldn't be the spec.

Well, pci-serial and pci-bridge are *not* paravirtual devices.

They follow a specification describing the programming interface, and
likewise does real hardware.  Same is true for all usb host controllers
and ahci btw.  I can certainly place a text file for pci-serial in
docs/spec/, but there isn't much qemu-specific to specify ...

Guests have generic drivers which just match the PCI class and
programming interface fields in the pci config space and don't care
(much) what the pci id is.  The pci id is used to print the name of the
hardware, apply quirks, handle vendor-specific extensions, and in case
of pci-serial windows also uses it to figure whenever the device is just
a serial port or a modem (behind a 16550).

Whenever we'll pick the pci ids of existing hardware or assign a unique
one is a matter of taste.  Picking unique IDs from Red Hat vendor space
doesn't make the devices paravirtual.  usb controllers and ahci got IDs
matching the ones of the intel chipsets (piix, q35) emulated by qemu,
which makes sense in that case.

For pci-serial windows needs a "driver" (which is just a inf file, the
driver itself is shipped by windows).  So in that case it is easier to
go with our own ids I think, as we can simply ship a inf file then.
When picking the IDs of other cards, existing as real hardware, users
would have to hunt down the (non-redistributable) driver package for the
real hardware to get it going in windows.

cheers,
  Gerd

  reply	other threads:[~2012-09-27  5:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-24 11:28 [Qemu-devel] [PATCH 0/2] add pci-serial device Gerd Hoffmann
2012-09-24 11:28 ` [Qemu-devel] [PATCH 1/2] serial: split serial.c Gerd Hoffmann
2012-09-24 11:28 ` [Qemu-devel] [PATCH 2/2] serial: add pci variant Gerd Hoffmann
2012-09-25 23:43 ` [Qemu-devel] [PATCH 0/2] add pci-serial device Anthony Liguori
2012-09-26  0:18   ` Jan Kiszka
2012-09-26  6:54     ` Gerd Hoffmann
2012-09-26  6:44   ` Gerd Hoffmann
2012-09-26 13:01     ` Anthony Liguori
2012-09-27  5:53       ` Gerd Hoffmann [this message]
2012-09-28 10:06         ` Michael S. Tsirkin
2012-09-28 11:45           ` Gerd Hoffmann
2012-09-28 10:07       ` Michael S. Tsirkin

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=5063E9EB.2020009@redhat.com \
    --to=kraxel@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.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).