qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "igvt-g@ml01.01.org" <igvt-g@ml01.01.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] vfio/igd: handle q35 machine type
Date: Wed, 09 Mar 2016 16:00:50 +0100	[thread overview]
Message-ID: <1457535650.676.50.camel@redhat.com> (raw)
In-Reply-To: <1457510637.676.15.camel@redhat.com>

  Hi,

[ context for igvt list: how do we deal with the ich9 lpc emulated by
  q35 machine type best, when pci-assigning a igd? ]

> > It seems
> > quite limiting of igd assignment on q35 VMs if we're going to remove
> > collateral device modification.  Should we only claim "legacy" igd
> > support on 440FX and support only universal passthrough on q35?  Thanks,
> 
> I'll go test this a bit more.  Possibly we can drop the whole lpc
> tweaking.  At least when looking at the linux driver code it doesn't
> seem to be very important.

Ok, we can't, it's actually checked in quite a few places.  The checks
are hidden in a macro though which I initially didn't spot.  The bios is
unhappy too if the lpc @ 1f.0 goes away.

But just copying over the pci ids doesn't work either, it breaks
firmware q35 initialization.  Which in turn breaks acpi (partly), so
some things like poweroff stop working.  And I have some irq routing
errors in the kernel log too.

So, q35 works (without lpc tweaks) with 4.5-rc6+ guest kernel (should be
4.4.5+ soon) and bios rom disabled.  That is at least a start.

To get the bios and older kernels working we have to fiddle with the
lpc.  Copying from the host looks bad to me, we have to maintain tons of
pci ids in the firmware then.  At least the intel driver only needs to
know which pch generation is used, so we might be able to get away with
one pch per igd generation, and hopefully can stop doing that long term,
when intel untangles igd and pch in hardware.

cheers,
  Gerd

  reply	other threads:[~2016-03-09 15:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04  8:41 [Qemu-devel] [PATCH v2] vfio/igd: handle q35 machine type Gerd Hoffmann
2016-03-07 21:41 ` Alex Williamson
2016-03-08  8:04   ` Gerd Hoffmann
2016-03-08 15:15     ` Alex Williamson
2016-03-09  8:03       ` Gerd Hoffmann
2016-03-09 15:00         ` Gerd Hoffmann [this message]
2016-03-10  5:49           ` [Qemu-devel] [iGVT-g] " Tian, Kevin
2016-03-09 15:02         ` [Qemu-devel] " 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=1457535650.676.50.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=igvt-g@ml01.01.org \
    --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).