From: Paolo Bonzini <pbonzini@redhat.com> To: "Chen, Tiejun" <tiejun.chen@intel.com>, daniel.vetter@ffwll.ch, jani.nikula@linux.intel.com, airlied@linux.ie Cc: intel-gfx@lists.freedesktop.org, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, qemu-devel@nongnu.org Subject: Re: [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type Date: Wed, 25 Jun 2014 08:48:32 +0200 [thread overview] Message-ID: <53AA70C0.2000806@redhat.com> (raw) In-Reply-To: <53A692F9.3060200@intel.com> Il 22/06/2014 10:25, Chen, Tiejun ha scritto: > In qemu-upstream, as you commented we can't create this as a ISA class > type explicitly. Note I didn't say that QEMU doesn't like having two ISA bridges. I commented that the firmware will see two ISA bridges and will try to initialize both of them. It currently doesn't just because it only knows of two southbridge PCI IDs, and both of them are old or relatively old (PIIX3/4 and ICH9). But what would happen if you did graphics passthrough on a machine with an ICH9 southbridge? Your code will create the PIIX4 ISA bridge, and will create an ICH9 southbridge just to please the i915 driver. The BIOS will recognize the ICH9's vendor/device ids and try to initialize it. It will write to the configuration space to set up PCI PIRQ[A-H] routing, for example, which makes no sense since your ICH9 is just a dummy device. Second problem. Your IGD passthrough code currently works with QEMU's PIIX4-based machine. But what happens if you try to extend it, so that it works with QEMU's ICH9-based machine? That's a more modern machine that has a PCIe chipset and hence has its ISA bridge at 00:1f.0. Now you have a conflict. In other words, if you want IGD passthrough in QEMU, you need a solution that is future-proof. > So we compromise by faking this ISA bridge without ISA > class type setting (as I recall you already said this way is slightly > better). It is only slightly better, but the right solution is to fix the driver. There is absolutely zero reason why a graphics driver should know about the vendor/device ids of the PCH. The right way could be to make QEMU add a vendor-specific capability to the video device. The driver can probe for that capability before looking at the PCI bus. QEMU can add the capability to the list, it is easy because all accesses to the video device's configuration space trap to QEMU. Then you do not need to add fake devices to the machine. In fact, it would be nice if Intel added such a capability on the next generation of integrated graphics, too. On real hardware, ACPI or some other kind of firmware can probe the PCH at 00:1f.0 and initialize that vendor-specific capability. QEMU would just forward the value from the host, so that virtualized guests never depend on the PCH at 00:1f.0. Paolo > Maybe we will figure better way in the future. But anyway, this > is always registered as 00:15.0, right? So I think the i915 driver can > go back to probe the devfn like the native environment.
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com> To: "Chen, Tiejun" <tiejun.chen@intel.com>, daniel.vetter@ffwll.ch, jani.nikula@linux.intel.com, airlied@linux.ie Cc: intel-gfx@lists.freedesktop.org, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type Date: Wed, 25 Jun 2014 08:48:32 +0200 [thread overview] Message-ID: <53AA70C0.2000806@redhat.com> (raw) In-Reply-To: <53A692F9.3060200@intel.com> Il 22/06/2014 10:25, Chen, Tiejun ha scritto: > In qemu-upstream, as you commented we can't create this as a ISA class > type explicitly. Note I didn't say that QEMU doesn't like having two ISA bridges. I commented that the firmware will see two ISA bridges and will try to initialize both of them. It currently doesn't just because it only knows of two southbridge PCI IDs, and both of them are old or relatively old (PIIX3/4 and ICH9). But what would happen if you did graphics passthrough on a machine with an ICH9 southbridge? Your code will create the PIIX4 ISA bridge, and will create an ICH9 southbridge just to please the i915 driver. The BIOS will recognize the ICH9's vendor/device ids and try to initialize it. It will write to the configuration space to set up PCI PIRQ[A-H] routing, for example, which makes no sense since your ICH9 is just a dummy device. Second problem. Your IGD passthrough code currently works with QEMU's PIIX4-based machine. But what happens if you try to extend it, so that it works with QEMU's ICH9-based machine? That's a more modern machine that has a PCIe chipset and hence has its ISA bridge at 00:1f.0. Now you have a conflict. In other words, if you want IGD passthrough in QEMU, you need a solution that is future-proof. > So we compromise by faking this ISA bridge without ISA > class type setting (as I recall you already said this way is slightly > better). It is only slightly better, but the right solution is to fix the driver. There is absolutely zero reason why a graphics driver should know about the vendor/device ids of the PCH. The right way could be to make QEMU add a vendor-specific capability to the video device. The driver can probe for that capability before looking at the PCI bus. QEMU can add the capability to the list, it is easy because all accesses to the video device's configuration space trap to QEMU. Then you do not need to add fake devices to the machine. In fact, it would be nice if Intel added such a capability on the next generation of integrated graphics, too. On real hardware, ACPI or some other kind of firmware can probe the PCH at 00:1f.0 and initialize that vendor-specific capability. QEMU would just forward the value from the host, so that virtualized guests never depend on the PCH at 00:1f.0. Paolo > Maybe we will figure better way in the future. But anyway, this > is always registered as 00:15.0, right? So I think the i915 driver can > go back to probe the devfn like the native environment.
next prev parent reply other threads:[~2014-06-25 6:48 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-19 9:53 [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type Tiejun Chen 2014-06-19 9:53 ` Tiejun Chen 2014-06-19 9:53 ` [Qemu-devel] " Tiejun Chen 2014-06-20 9:40 ` Chen, Tiejun 2014-06-20 9:40 ` Chen, Tiejun 2014-06-20 9:40 ` [Qemu-devel] " Chen, Tiejun 2014-06-20 12:32 ` Daniel Vetter 2014-06-20 12:32 ` Daniel Vetter 2014-06-20 12:32 ` [Qemu-devel] " Daniel Vetter 2014-06-22 8:00 ` Chen, Tiejun 2014-06-22 8:00 ` Chen, Tiejun 2014-06-22 8:00 ` [Qemu-devel] " Chen, Tiejun 2014-06-20 12:48 ` Paolo Bonzini 2014-06-20 12:48 ` [Qemu-devel] " Paolo Bonzini 2014-06-22 8:25 ` Chen, Tiejun 2014-06-22 8:25 ` [Qemu-devel] " Chen, Tiejun 2014-06-25 6:48 ` Paolo Bonzini [this message] 2014-06-25 6:48 ` Paolo Bonzini 2014-06-25 7:34 ` Chen, Tiejun 2014-06-25 7:34 ` [Qemu-devel] " Chen, Tiejun 2014-06-25 7:55 ` Paolo Bonzini 2014-06-25 7:55 ` [Qemu-devel] " Paolo Bonzini 2014-06-30 3:13 ` Chen, Tiejun 2014-06-30 3:13 ` [Qemu-devel] " Chen, Tiejun 2014-06-30 10:56 ` Paolo Bonzini 2014-06-30 10:56 ` [Qemu-devel] " Paolo Bonzini 2014-07-07 14:49 ` Daniel Vetter 2014-07-07 14:49 ` Daniel Vetter 2014-07-07 14:49 ` [Qemu-devel] " Daniel Vetter 2014-07-07 14:57 ` Paolo Bonzini 2014-07-07 14:57 ` [Qemu-devel] " Paolo Bonzini 2014-07-07 17:54 ` [Intel-gfx] " Daniel Vetter 2014-07-07 17:54 ` Daniel Vetter 2014-07-07 17:54 ` [Qemu-devel] " Daniel Vetter 2014-07-07 17:58 ` Paolo Bonzini 2014-07-07 17:58 ` [Qemu-devel] " Paolo Bonzini 2014-07-07 18:40 ` Daniel Vetter 2014-07-07 18:40 ` Daniel Vetter 2014-07-07 18:40 ` [Qemu-devel] [Intel-gfx] " Daniel Vetter 2014-07-10 21:08 ` Tian, Kevin 2014-07-10 21:08 ` Tian, Kevin 2014-07-10 21:08 ` [Qemu-devel] [Intel-gfx] " Tian, Kevin 2014-07-11 6:29 ` Daniel Vetter 2014-07-11 6:29 ` Daniel Vetter 2014-07-11 6:29 ` [Qemu-devel] " Daniel Vetter 2014-07-11 19:42 ` [Xen-devel] " Konrad Rzeszutek Wilk 2014-07-11 19:42 ` [Xen-devel] " Konrad Rzeszutek Wilk 2014-07-11 19:42 ` [Qemu-devel] [Xen-devel] [Intel-gfx] " Konrad Rzeszutek Wilk 2014-07-11 20:30 ` Tian, Kevin 2014-07-11 20:30 ` [Xen-devel] " Tian, Kevin 2014-07-11 20:30 ` [Qemu-devel] [Xen-devel] [Intel-gfx] " Tian, Kevin 2014-07-12 10:13 ` [Intel-gfx] [Xen-devel] " Daniel Vetter 2014-07-12 10:13 ` Daniel Vetter 2014-07-12 10:13 ` [Qemu-devel] [Intel-gfx] " Daniel Vetter 2014-06-24 2:59 ` [Intel-gfx] " Zhenyu Wang 2014-06-24 2:59 ` Zhenyu Wang 2014-06-24 2:59 ` [Qemu-devel] [Intel-gfx] " Zhenyu Wang 2014-06-25 2:28 ` Chen, Tiejun 2014-06-25 2:28 ` Chen, Tiejun 2014-06-25 2:28 ` [Qemu-devel] [Intel-gfx] " Chen, Tiejun 2014-07-07 14:51 ` Daniel Vetter 2014-07-07 14:51 ` Daniel Vetter 2014-07-07 14:51 ` [Qemu-devel] " Daniel Vetter 2014-06-30 11:18 ` Michael S. Tsirkin 2014-06-30 11:18 ` Michael S. Tsirkin 2014-06-30 11:18 ` [Qemu-devel] " Michael S. Tsirkin 2014-07-01 1:52 ` Chen, Tiejun 2014-07-01 1:52 ` Chen, Tiejun 2014-07-01 1:52 ` [Qemu-devel] " Chen, Tiejun 2014-07-02 6:21 ` Michael S. Tsirkin 2014-07-02 6:21 ` Michael S. Tsirkin 2014-07-02 6:21 ` [Qemu-devel] " Michael S. Tsirkin 2014-07-02 8:27 ` Chen, Tiejun 2014-07-02 8:27 ` Chen, Tiejun 2014-07-02 8:27 ` [Qemu-devel] " Chen, Tiejun
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=53AA70C0.2000806@redhat.com \ --to=pbonzini@redhat.com \ --cc=airlied@linux.ie \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jani.nikula@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=qemu-devel@nongnu.org \ --cc=tiejun.chen@intel.com \ --cc=xen-devel@lists.xensource.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: linkBe 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.