From: Alex Williamson <alex.williamson@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, allen.m.kay@intel.com,
kvm@vger.kernel.org, "Zhao, Xinda" <xinda.zhao@intel.com>,
Kevin Tian <kevin.tian@intel.com>
Subject: Re: [Qemu-devel] [PATCH v6 6/8] vfio/pci: Intel graphics legacy mode assignment
Date: Wed, 18 May 2016 10:50:45 -0600 [thread overview]
Message-ID: <20160518105045.010d84c5@t450s.home> (raw)
In-Reply-To: <1463581318.30045.66.camel@redhat.com>
On Wed, 18 May 2016 16:21:58 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Di, 2016-05-17 at 14:19 -0600, Alex Williamson wrote:
> > +static int igd_gen(VFIOPCIDevice *vdev)
> > +{
> > + if ((vdev->device_id & 0xfff) == 0xa84) {
> > + return 8; /* Broxton */
> > + }
> > +
> > + switch (vdev->device_id & 0xff00) {
> > + /* Old, untested, unavailable, unknown */
> > + case 0x0000:
> > + case 0x2500:
> > + case 0x2700:
> > + case 0x2900:
> > + case 0x2a00:
> > + case 0x2e00:
> > + case 0x3500:
> > + case 0xa000:
> > + return -1;
> > + /* SandyBridge, IvyBridge, ValleyView, Haswell */
> > + case 0x0100:
> > + case 0x0400:
> > + case 0x0a00:
> > + case 0x0c00:
> > + case 0x0d00:
> > + case 0x0f00:
> > + return 6;
> > + /* BroadWell, CherryView, SkyLake, KabyLake */
> > + case 0x1600:
> > + case 0x1900:
> > + case 0x2200:
> > + case 0x5900:
> > + return 8;
> > + }
> > +
> > + return 8; /* Assume newer is compatible */
> > +}
> > +
>
> This link:
> https://github.com/01org/Igvtg-qemu/commit/ea32e6769004d6eb98d2dbd859d81bf1885c6ad2#diff-9d4d99332b83a7de33cbeed489d60448R920
>
> happened to land in my inbox these days. It provides a bunch of
> functions called is_$codename() and intel_gen_version(). Looks more
> complete to me. Maybe we should pick up them and find a place in the
> qemu source tree where both vfio and intel-vgpu (and maybe xen device
> assignment too) can share those functions?
Yeah, I used to have something more similar to that, this was an
attempt to simplify since I know I'm already dealing with an Intel VGA
device. That let's me not care that some of the device IDs I'll match
won't be IGD devices because they'll never get to this filter. For me
the is_sandbridge() and is_ivybridge() tests simplifies to that single
first case of 0x0100. All of is_haswell() is covered by the next four
lines, is_broadwell() and is_skylake() the first two in the next
section. So I think I have those sufficiently covered and I add a few
more, but it's entirely possible that there's no VT-d support on those
extras, I didn't lookup ark specs for every processor in the series.
I'm all for re-using a common function once we have more than one user,
but I think for now this is simple and does the job. Thanks,
Alex
next prev parent reply other threads:[~2016-05-18 16:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 20:19 [Qemu-devel] [PATCH v6 0/8] Series short description Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 1/8] vfio: Enable sparse mmap capability Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 2/8] vfio: Create device specific region info helper Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 3/8] vfio/pci: Fix return of vfio_populate_vga() Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 4/8] vfio/pci: Consolidate VGA setup Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 5/8] vfio/pci: Setup BAR quirks after capabilities probing Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 6/8] vfio/pci: Intel graphics legacy mode assignment Alex Williamson
2016-05-18 14:21 ` Gerd Hoffmann
2016-05-18 16:50 ` Alex Williamson [this message]
2016-05-17 20:20 ` [Qemu-devel] [PATCH v6 7/8] vfio/pci: Add a separate option for IGD OpRegion support Alex Williamson
2016-05-17 20:20 ` [Qemu-devel] [PATCH v6 8/8] vfio/pci: Add IGD documentation Alex Williamson
2016-05-18 2:23 ` Eric Blake
2016-05-18 18:35 ` Alex Williamson
2016-05-18 19:28 ` Eric Blake
2016-05-17 20:42 ` [Qemu-devel] vfio IGD assignment (was Re: [PATCH v6 0/8] Series short description) Alex Williamson
2016-05-18 14:24 ` Gerd Hoffmann
2016-05-18 18:45 ` Alex Williamson
2016-05-19 9:00 ` Gerd Hoffmann
2016-05-20 12:19 ` Gerd Hoffmann
2016-05-20 15:08 ` Alex Williamson
2016-05-23 13:34 ` Gerd Hoffmann
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=20160518105045.010d84c5@t450s.home \
--to=alex.williamson@redhat.com \
--cc=allen.m.kay@intel.com \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=xinda.zhao@intel.com \
/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).