From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH 0/2] add pci-serial device.
Date: Fri, 28 Sep 2012 12:06:00 +0200 [thread overview]
Message-ID: <20120928100600.GA7522@redhat.com> (raw)
In-Reply-To: <5063E9EB.2020009@redhat.com>
On Thu, Sep 27, 2012 at 07:53:47AM +0200, Gerd Hoffmann wrote:
> 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
Any way to bypass the need to distribute the inf?
--
MST
next prev parent reply other threads:[~2012-09-28 10:04 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
2012-09-28 10:06 ` Michael S. Tsirkin [this message]
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=20120928100600.GA7522@redhat.com \
--to=mst@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=kraxel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.