From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Dutile Subject: Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU Date: Mon, 04 Jun 2012 19:52:59 -0400 Message-ID: <4FCD4A5B.2050604@redhat.com> References: <1338845342-12464-1-git-send-email-ddutile@redhat.com> <1338845342-12464-3-git-send-email-ddutile@redhat.com> <1338849430.10884.288.camel@shinybook.infradead.org> <4FCD401D.9000304@redhat.com> <1338852196.26785.10.camel@shinybook.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1338852196.26785.10.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: David Woodhouse Cc: chrisw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, mingo-X9Un+BFzKDI@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: iommu@lists.linux-foundation.org T24gMDYvMDQvMjAxMiAwNzoyMyBQTSwgRGF2aWQgV29vZGhvdXNlIHdyb3RlOgo+IE9uIE1vbiwg MjAxMi0wNi0wNCBhdCAxOTowOSAtMDQwMCwgRG9uIER1dGlsZSB3cm90ZToKPj4+IElmIHRoZSBC SU9TICpkb2Vzbid0KiBkbyB0aGF0LCB0aGVuIEkgYmVsaWV2ZSB0aGlzIHNob3VsZCBiZQo+Pj4g V0FSTl9UQUlOVF9PTkNFKOKAplRBSU5UX0ZJUk1XQVJFX1dPUktBUk9VTkTigKYpIGxpa2Ugb3Ro ZXIgQklPUyBwcm9ibGVtcwo+Pj4gdGhhdCB3ZSBoYXZlIGRpc2NvdmVyZWQuCj4+Pgo+PiB3ZWxs LCBvbmUgY291bGQgYXJndWUgaXQgbWF5IGJlIGVhc2llciB0byBjbGFpbSB0aGUgc3BhY2UgcmVz ZXJ2ZWQgaW4KPj4gdGhlIE9TIHRoZW4gbWFraW5nIHlldCBhbm90aGVyIGhvbGUgaW4gdGhlIGF2 YWlsYWJsZSBJTyBhZGRyZXNzIHNwYWNlCj4+IGluIHRoZSBBQ1BJIHRhYmxlcy4KPgo+IEJ1dCBo b3c/IEl0J3MgZ290IHRvIHdvcmsgd2l0aCBvcGVyYXRpbmcgc3lzdGVtcyB0aGF0IHByZWRhdGUg dGhlIElPTU1VLgo+IFRoZSByZWdpc3RlcnMgKmhhdmUqIHRvIGJlIGluIGEgbWFya2VkIGhvbGUu IElmICpub3QqLCB0aGVuIHdlIHNob3VsZAo+IGdpdmUgYSBjbGVhciAiWU9VUiBCSU9TIElTIEJS T0tFTiIgb3V0cHV0IGxpa2UgYWxsIHRoZSBzaW1pbGFyCj4gYnJlYWthZ2VzLCBhbmQgZG8gb3Vy IGJlc3QgdG8gd29yayBhcm91bmQgaXQuCj4KPiBXb3JraW5nIGFyb3VuZCBpdCBpcyBmaW5lOyBJ J20gbm90IHN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91bGQgV0FSTigpCj4gKmluc3RlYWQqIG9mIHdv cmtpbmcgYXJvdW5kIGl0Lgo+Cm9rLgoKPj4gSG93IGRvZXMgdGhlIGtlcm5lbCBwcm9iZSBmb3Ig Y2hpcHNldHMsIHRoZW4gcmVnaXN0ZXJzIHdpdGggdGhlIGNoaXBzZXRzCj4+IHRvIGZpbmQgdGhl IHByb2dyYW1tZWQgSU9NTVUgQkFSIHZhbHVlcz8KPj4gLS0gSSBtaXNzZWQgdGhhdCBjbGFzcy4u Li4gSSBvbmx5IGhhdmUgSW50ZWwgVmlydCBUZWNoIERpcmVjdGVkIEkvTwo+PiBBcmNoaXRlY3R1 cmUgc3BlYy4sIGFuZCB0aGUgYmVnaW5uaW5nIG9mIElPTU1VIGlzIGJhc2VkIG9uIERNQVIgdGFi bGVzLi4uCj4+IElmIHlvdSBoYXZlIG1vcmUgaW5mby9ndWlkYW5jZSwgSSdkIGFwcHJlY2lhdGUg aXQuCj4KPiBIbSwgSSB0aG91Z2h0IHdlJ2QgYWxyZWFkeSBzdGFydGVkIGRvaW5nIHNvbWUgb2Yg dGhhdCBpbiBvcmRlciB0bwo+IHNhbml0eS1jaGVjayB0aGUgRE1BUiB0YWJsZXMuIFRoZSBWVEJB UiByZWdpc3RlcnMgYXJlIGluIFBDSSBjb25maWcKPiBzcGFjZS4gVGhlIHF1aXJrX2lvYXRfc25i X2xvY2FsX2lvbW11KCkgY2hlY2sgaXMgYWxyZWFkeSBsb29raW5nIGF0Cj4gdGhlbS4uLgo+CmV4 Y2VwdCB0aGF0IHF1aXJrIGlzIGNvbmRpdGlvbmFsbHkgY29tcGlsZWQgaW4gaW50ZWwtaW9tbXUu YzsKdG8gZG8gdGhlIGNoZWNrIGluZGVwIG9mIElOVEVMLUlPTU1VIENPTkZJRyB0YWcsIGl0J2Qg aGF2ZSB0byBtb3ZlIGludG8KcGNpL3F1aXJrcy5jLiAuLi4gYW5kIGhvdyBkb2VzIGl0IGdldCB0 cmlnZ2VyZWQ/IC4uLiBhIGRtYXIgdGFibGUgY2hlY2s/Cih0eXBpY2FsIHF1aXJrcyBraWNrZWQg YmFzZWQgb24gdmlkL2RpZC4uLikKCj4gSSdtIG5vdCBxdWl0ZSBzdXJlIHdoaWNoIGRvY3VtZW50 IHRoZXkgYXJlIGRvY3VtZW50ZWQgaW4uIERvaW5nIGl0IGJhc2VkCj4gb24gdGhlIERNQVIgdGFi bGUsIGFzIHlvdSBoYXZlLCBpcyBjZXJ0YWlubHkgYSBnb29kIHN0YXJ0LiBCdXQgZG8gaXQKPiB3 aXRoIGEgYmlnZ2VyIHNob3V0eSBXQVJOKFRBSU5UX0ZJUk1XQVJFX1dPUktBUk9VTkQpLCBhbmQg ZG8gaXQgd2hlbiB0aGUKPiBJT01NVSBjb2RlIGlzbid0IGNvbXBpbGVkIGluLgo+ClRoZSAnZG8g aXQgZm9yIGludGVsLWlvbW11IHN5c3RlbXMgb25seScgYW5kIG5vdCBiZSBDT05GSUcgZGVwZW5k ZW50CmlzIGEgYml0IGNoYWxsZW5naW5nIGdpdmVuIGhvdyB0aGUgY29kZSBpcyBjb21waWxlZCwg YW5kIHRoZSBleHBlY3RlZC9ub3JtYWwKY29kZSBmbG93IHN0YXJ0aW5nIGZyb20gYSBkbWFyIHRh YmxlLgpvZiBjb3Vyc2UsIGlmIHRoZSBJT01NVSBqdXN0IGV4cG9zZWQgaXRzZWxmIGFzIHRoZSBm aXJzdCBkZXZpY2Ugb24gYSBQQ0kKYnVzLCB0aGlzIHdvdWxkIGJlIHRyaXZpYWwhCi0tIEkgcmVh bGx5IGhhdGUgQklPUyBkZXBlbmRlbmNpZXMgdG8gZ2V0IHRoaW5ncyByaWdodCEKCj4+IFNlZW1z IGxpa2UgdGhlIHBhdGNoIHdvdWxkIGJlIGVhc2llciB0byBzdXBwb3J0LCBhbHRob3VnaCBpdCBk b2Vzbid0Cj4+IHNvbHZlIHRoZSBwcm9ibGVtIHlvdSBtZW50aW9uZWQgYWJvdmUsIHVubGVzcyB0 aGUgcmVzZXJ2YXRpb24gY29kZSBpc24ndAo+PiBjb21waWxlZCBvdXQgYnkgSU5URUwtSU9NTVUg KGJ1dCBzb21ldGhpbmcgbW9yZSBnZW5lcmFsIGxpa2UgISh4ODYmJiAgUENJKSkuCj4+IHRoZSBm aXJtd2FyZSB0YWludCBtZXNzYWdlIHdvdWxkIGJlIGluZm9ybWF0aXZlIGFzIHRvIHRoZSBxdWFs aXR5IG9mCj4+IHRoZSBmaXJtd2FyZSwgYnV0IG15IGV4cGVyaWVuY2UgaXMgbm90aGluZyBjaGFu Z2VzIHVubGVzcyBpdCdzIGNyaXRpY2FsCj4+IHRvIGEgc3lzdGVtIHNoaXBwaW5nLgo+Cj4+ICAg IFRoZSBCSU9TJ3MgYXJlIGdldHRpbmcgYmV0dGVyLCBidXQgSSd2ZSBzZWVuIHR1cnRsZXMgcnVu IGZhc3Rlci4uLiA7LSkgLgo+Cj4gVGhhbmtmdWxseSwgdGhlcmUgYXJlIG5vdyBzb21lIG1vZGVy biBJbnRlbCBzeXN0ZW1zIG9uIHdoaWNoIHlvdSBjYW4gcnVuCj4gQ29yZWJvb3QuIFRoaXMgc2hv dWxkIGJlIGEgaHVnZSBiZW5lZml0IOKAlCB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gYnVpbGQgYW4K PiB1cC10by1kYXRlIFRpYW5vY29yZSBhbmQgZGVwbG95IGl0IGFzIHlvdXIgQ29yZWJvb3QgcGF5 bG9hZCwgcmF0aGVyIHRoYW4KPiBoYXZpbmcgdG8gcHV0IHVwIHdpdGggdGhlIGNyYXAgdGhhdCdz IG9uIHRoZSBzeXN0ZW0gd2hlbiB5b3UgcmVjZWl2ZSBpdC4KPgo+CmV4Y2VwdCwgbW9zdCBzeXN0 ZW0gKGh3LCBvcywgYXBwbGljKSBjZXJ0aWZpY2F0aW9ucyBhcmUgYmFzZWQgb24gdmVuZG9yJ3MK c2hpcHBlZCBCSU9TLCBzbyBDb3JlYm9vdCBpc24ndCBhIGd1YXJhbnRlZSBlaXRoZXIuICBBZGRp dGlvbmFsbHksIHRlbGxpbmcKYSBjdXN0b21lciB0byByZXBsYWNlIHRoZWlyIHBhaWQtZm9yLUJJ T1MgZm9yIGEgYnVpbGQteW91ci1vd24tY29yZWJvb3QgYmlvcwppcyBhIHRvdWdoIHdheSB0byBj bG9zZSBhIGJ6LiA7LSkKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KaW9tbXUgbWFpbGluZyBsaXN0CmlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3Jn Cmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvbW11 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761246Ab2FDXxL (ORCPT ); Mon, 4 Jun 2012 19:53:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39738 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753223Ab2FDXxK (ORCPT ); Mon, 4 Jun 2012 19:53:10 -0400 Message-ID: <4FCD4A5B.2050604@redhat.com> Date: Mon, 04 Jun 2012 19:52:59 -0400 From: Don Dutile User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110927 Red Hat/3.1.15-1.el6_1 Thunderbird/3.1.15 MIME-Version: 1.0 To: David Woodhouse CC: iommu@lists.linux-foundation.org, mingo@elte.hu, linux-kernel@vger.kernel.org, chrisw@redhat.com, suresh.b.siddha@intel.com Subject: Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU References: <1338845342-12464-1-git-send-email-ddutile@redhat.com> <1338845342-12464-3-git-send-email-ddutile@redhat.com> <1338849430.10884.288.camel@shinybook.infradead.org> <4FCD401D.9000304@redhat.com> <1338852196.26785.10.camel@shinybook.infradead.org> In-Reply-To: <1338852196.26785.10.camel@shinybook.infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/04/2012 07:23 PM, David Woodhouse wrote: > On Mon, 2012-06-04 at 19:09 -0400, Don Dutile wrote: >>> If the BIOS *doesn't* do that, then I believe this should be >>> WARN_TAINT_ONCE(…TAINT_FIRMWARE_WORKAROUND…) like other BIOS problems >>> that we have discovered. >>> >> well, one could argue it may be easier to claim the space reserved in >> the OS then making yet another hole in the available IO address space >> in the ACPI tables. > > But how? It's got to work with operating systems that predate the IOMMU. > The registers *have* to be in a marked hole. If *not*, then we should > give a clear "YOUR BIOS IS BROKEN" output like all the similar > breakages, and do our best to work around it. > > Working around it is fine; I'm not suggesting that we should WARN() > *instead* of working around it. > ok. >> How does the kernel probe for chipsets, then registers with the chipsets >> to find the programmed IOMMU BAR values? >> -- I missed that class.... I only have Intel Virt Tech Directed I/O >> Architecture spec., and the beginning of IOMMU is based on DMAR tables... >> If you have more info/guidance, I'd appreciate it. > > Hm, I thought we'd already started doing some of that in order to > sanity-check the DMAR tables. The VTBAR registers are in PCI config > space. The quirk_ioat_snb_local_iommu() check is already looking at > them... > except that quirk is conditionally compiled in intel-iommu.c; to do the check indep of INTEL-IOMMU CONFIG tag, it'd have to move into pci/quirks.c. ... and how does it get triggered? ... a dmar table check? (typical quirks kicked based on vid/did...) > I'm not quite sure which document they are documented in. Doing it based > on the DMAR table, as you have, is certainly a good start. But do it > with a bigger shouty WARN(TAINT_FIRMWARE_WORKAROUND), and do it when the > IOMMU code isn't compiled in. > The 'do it for intel-iommu systems only' and not be CONFIG dependent is a bit challenging given how the code is compiled, and the expected/normal code flow starting from a dmar table. of course, if the IOMMU just exposed itself as the first device on a PCI bus, this would be trivial! -- I really hate BIOS dependencies to get things right! >> Seems like the patch would be easier to support, although it doesn't >> solve the problem you mentioned above, unless the reservation code isn't >> compiled out by INTEL-IOMMU (but something more general like !(x86&& PCI)). >> the firmware taint message would be informative as to the quality of >> the firmware, but my experience is nothing changes unless it's critical >> to a system shipping. > >> The BIOS's are getting better, but I've seen turtles run faster... ;-) . > > Thankfully, there are now some modern Intel systems on which you can run > Coreboot. This should be a huge benefit — you should be able to build an > up-to-date Tianocore and deploy it as your Coreboot payload, rather than > having to put up with the crap that's on the system when you receive it. > > except, most system (hw, os, applic) certifications are based on vendor's shipped BIOS, so Coreboot isn't a guarantee either. Additionally, telling a customer to replace their paid-for-BIOS for a build-your-own-coreboot bios is a tough way to close a bz. ;-)