From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Anthony Liguori" <anthony@codemonkey.ws>,
marcel.a@redhat.com, "qemu list" <qemu-devel@nongnu.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Laine Stump" <laine@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] Attaching PCI devices to the PCIe root complex
Date: Mon, 30 Sep 2013 19:06:47 +0300 [thread overview]
Message-ID: <20130930160647.GE10306@redhat.com> (raw)
In-Reply-To: <1380556877.3922.48.camel@nilsson.home.kraxel.org>
On Mon, Sep 30, 2013 at 06:01:17PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Yes but, same as in the initial design,
> > it really makes it user's problem.
> >
> > So we'd have
> > virtio-net-pci-conventional
> > virtio-net-pci-express
> > virtio-net-pci-integrated
> >
> >
> > All this while users just really want to say "virtio"
> > (that's the expert user, what most people want is for guest to be faster).
>
> And for the actual device emulation it makes almost no difference. xhci
> exists in express and integrated variants too. The qemu-emulated device
> calls pcie_endpoint_cap_init() unconditionally, so the express endpoint
> capability shows up even if you plug it into the root bus. That should
> be handled better. But I think that would be the only difference in the
> xhci code. And even that could be handled in the pci core, for example
> by making pcie_endpoint_cap_init a nop unless the device is actually is
> a express endpoint from the bus topology point of view.
>
> Maybe PCIDeviceClass->is_express should move to PCIDevice and
> PCIDeviceClass should get a supports_express field instead.
>
> cheers,
> Gerd
Not sure why do you need is_express in PCIDevice.
We already have QEMU_PCI_CAP_EXPRESS set in cap_present.
next prev parent reply other threads:[~2013-09-30 16:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-24 10:01 [Qemu-devel] Attaching PCI devices to the PCIe root complex Laine Stump
2013-09-25 7:01 ` Michael S. Tsirkin
2013-09-25 8:48 ` Marcel Apfelbaum
2013-09-25 8:59 ` Michael S. Tsirkin
2013-10-02 8:53 ` Paolo Bonzini
2013-10-02 9:28 ` Michael S. Tsirkin
2013-09-25 9:39 ` Laine Stump
2013-09-25 10:00 ` Michael S. Tsirkin
2013-09-25 10:14 ` Laine Stump
2013-09-25 10:56 ` Michael S. Tsirkin
2013-09-25 10:58 ` Michael S. Tsirkin
2013-09-27 17:06 ` Markus Armbruster
2013-09-28 18:12 ` Michael S. Tsirkin
2013-09-30 9:55 ` Markus Armbruster
2013-09-30 10:44 ` Laine Stump
2013-09-30 10:48 ` Michael S. Tsirkin
2013-09-30 16:01 ` Gerd Hoffmann
2013-09-30 16:06 ` Michael S. Tsirkin [this message]
2013-10-01 21:14 ` 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=20130930160647.GE10306@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=laine@redhat.com \
--cc=marcel.a@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.