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:09:17 -0400 Message-ID: <4FCD401D.9000304@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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1338849430.10884.288.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 T24gMDYvMDQvMjAxMiAwNjozNyBQTSwgRGF2aWQgV29vZGhvdXNlIHdyb3RlOgo+IE9uIE1vbiwg MjAxMi0wNi0wNCBhdCAxNzoyOSAtMDQwMCwgRG9uYWxkIER1dGlsZSB3cm90ZToKPj4gSW50ZWwt aW9tbXUgaW5pdGlhbGl6YXRpb24gZG9lc24ndCBjdXJyZW50bHkgcmVzZXJ2ZSB0aGUgbWVtb3J5 IHVzZWQKPj4gZm9yIHRoZSBJT01NVSByZWdpc3RlcnMuIFRoaXMgY2FuIGFsbG93IHRoZSBwY2kg cmVzb3VyY2UgYWxsb2NhdG9yCj4+IHRvIGFzc2lnbiBhIGRldmljZSBCQVIgdG8gdGhlIHNhbWUg YWRkcmVzcyBhcyB0aGUgSU9NTVUgcmVnaXN0ZXJzLgo+PiBUaGlzIGNhbiBjYXVzZSBzb21lIG5v dCBzbyBuaWNlIHNpZGUgYWZmZWN0cyB3aGVuIHRoZSBkcml2ZXIKPj4gaW9yZW1hcCdzIHRoYXQg cmVnaW9uLgo+Cj4gcy9hZmZlY3QvZWZmZWN0Lwo+Cm9rLgoKPiBBbmQgc3VyZWx5IHRoaXMgY2Fu IGhhcHBlbiBldmVuIHdoZW4gSU9NTVUgc3VwcG9ydCBpcyBjb21waWxlZCBvdXQgb2YKPiB0aGUg a2VybmVsLiBTaG91bGRuJ3QgdGhlIEJJT1MgYmUgKnRlbGxpbmcqIHVzIHRoYXQgdGhpcyByZWdp b24gaXMKPiB1bmF2YWlsYWJsZSBmb3IgUENJIHJlc291cmNlIGFsbG9jYXRpb24gKG9yIGFueXRo aW5nIGVsc2UsIGZvciB0aGF0Cj4gbWF0dGVyKT8KPgpnb29kIHBvaW50Li4uLgoKPiBJZiB0aGUg QklPUyAqZG9lc24ndCogZG8gdGhhdCwgdGhlbiBJIGJlbGlldmUgdGhpcyBzaG91bGQgYmUKPiBX QVJOX1RBSU5UX09OQ0Uo4oCmVEFJTlRfRklSTVdBUkVfV09SS0FST1VOROKApikgbGlrZSBvdGhl ciBCSU9TIHByb2JsZW1zCj4gdGhhdCB3ZSBoYXZlIGRpc2NvdmVyZWQuCj4Kd2VsbCwgb25lIGNv dWxkIGFyZ3VlIGl0IG1heSBiZSBlYXNpZXIgdG8gY2xhaW0gdGhlIHNwYWNlIHJlc2VydmVkIGlu CnRoZSBPUyB0aGVuIG1ha2luZyB5ZXQgYW5vdGhlciBob2xlIGluIHRoZSBhdmFpbGFibGUgSU8g YWRkcmVzcyBzcGFjZQppbiB0aGUgQUNQSSB0YWJsZXMuICBBbHRob3VnaCBJIHRoaW5rIHRoZSB3 b3JrYXJvdW5kcyBtb3JlIHN5c3RlbXMKaW1wbGVtZW50IGlzIHRvIHN0aWNrIHRoZSBJT01NVXMg aW50byBhbiBleGlzdGluZyBob2xlIHRvIGF2b2lkIHRoaXMgcHJvYmxlbS4KCj4gQW5kIHdlIHNo b3VsZCBwcm9iYWJseSBkbyBpdCBiYXNlZCBvbiB0aGUgYWN0dWFsIGNoaXBzZXQgcmVnaXN0ZXJz LCBub3QKPiB0aGUgRE1BUiB0YWJsZXMgKHdoaWNoIHRoZSBCSU9TIGhhcyBhbHNvIGJlZW4ga25v d24gdG8gbGllIGFib3V0KS4KPgpidXQuLi4uIHRoZSBETUFSIHRhYmxlcyBhcmUgdGhlIHNvdXJj ZSBvZiBhbGwgaW5mb3JtYXRpb24uLi4uIHdpc2UgYW5kIC4uLiBlciwgdW0uLi4gOy0pCnllcywg SSd2ZSBiZWVuIG9uIHRoZSByZWNlaXZpbmcgc2lkZSBvZiBtb3JlIGJ6J3Mgd3J0IGJhZCBETUFS IHRhYmxlcyB0aGVuIEkgY2FuIGNvdW50LApidXQuLi4KCkhvdyBkb2VzIHRoZSBrZXJuZWwgcHJv YmUgZm9yIGNoaXBzZXRzLCB0aGVuIHJlZ2lzdGVycyB3aXRoIHRoZSBjaGlwc2V0cwp0byBmaW5k IHRoZSBwcm9ncmFtbWVkIElPTU1VIEJBUiB2YWx1ZXM/Ci0tIEkgbWlzc2VkIHRoYXQgY2xhc3Mu Li4uIEkgb25seSBoYXZlIEludGVsIFZpcnQgVGVjaCBEaXJlY3RlZCBJL08KQXJjaGl0ZWN0dXJl IHNwZWMuLCBhbmQgdGhlIGJlZ2lubmluZyBvZiBJT01NVSBpcyBiYXNlZCBvbiBETUFSIHRhYmxl cy4uLgpJZiB5b3UgaGF2ZSBtb3JlIGluZm8vZ3VpZGFuY2UsIEknZCBhcHByZWNpYXRlIGl0LgoK U2VlbXMgbGlrZSB0aGUgcGF0Y2ggd291bGQgYmUgZWFzaWVyIHRvIHN1cHBvcnQsIGFsdGhvdWdo IGl0IGRvZXNuJ3QKc29sdmUgdGhlIHByb2JsZW0geW91IG1lbnRpb25lZCBhYm92ZSwgdW5sZXNz IHRoZSByZXNlcnZhdGlvbiBjb2RlIGlzbid0CmNvbXBpbGVkIG91dCBieSBJTlRFTC1JT01NVSAo YnV0IHNvbWV0aGluZyBtb3JlIGdlbmVyYWwgbGlrZSAhKHg4NiAmJiBQQ0kpKS4KdGhlIGZpcm13 YXJlIHRhaW50IG1lc3NhZ2Ugd291bGQgYmUgaW5mb3JtYXRpdmUgYXMgdG8gdGhlIHF1YWxpdHkg b2YKdGhlIGZpcm13YXJlLCBidXQgbXkgZXhwZXJpZW5jZSBpcyBub3RoaW5nIGNoYW5nZXMgdW5s ZXNzIGl0J3MgY3JpdGljYWwKdG8gYSBzeXN0ZW0gc2hpcHBpbmcuCgpJTU8sIGlmIHdlIGNhbiBh dm9pZCBhIEJJT1MgcHJvYmxlbSwgd2Ugc2hvdWxkLgpUaGUgZW1waXJpY2FsIGRhdGEgSSd2ZSBn YXRoZXJlZCBzbyBmYXIgaW4gdGhpcyBzcGFjZQooSU9NTVUsIHVzZSBieSBTUklPViBWRiBkZXZp Y2VzKSwgc2hvd3MgdGhlIEJJT1MgaGFzIG51bWVyb3VzCndlYWtuZXNzZXMsIGFuZCB0aGlzIGlz IHlldCBhbm90aGVyIG9uZS4gIFRoZSBCSU9TJ3MgYXJlIGdldHRpbmcgYmV0dGVyLApidXQgSSd2 ZSBzZWVuIHR1cnRsZXMgcnVuIGZhc3Rlci4uLiA7LSkgLgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmlvbW11IG1haWxpbmcgbGlzdAppb21tdUBsaXN0 cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcv bWFpbG1hbi9saXN0aW5mby9pb21tdQ== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761151Ab2FDXJb (ORCPT ); Mon, 4 Jun 2012 19:09:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53714 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693Ab2FDXJa (ORCPT ); Mon, 4 Jun 2012 19:09:30 -0400 Message-ID: <4FCD401D.9000304@redhat.com> Date: Mon, 04 Jun 2012 19:09:17 -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> In-Reply-To: <1338849430.10884.288.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 06:37 PM, David Woodhouse wrote: > On Mon, 2012-06-04 at 17:29 -0400, Donald Dutile wrote: >> Intel-iommu initialization doesn't currently reserve the memory used >> for the IOMMU registers. This can allow the pci resource allocator >> to assign a device BAR to the same address as the IOMMU registers. >> This can cause some not so nice side affects when the driver >> ioremap's that region. > > s/affect/effect/ > ok. > And surely this can happen even when IOMMU support is compiled out of > the kernel. Shouldn't the BIOS be *telling* us that this region is > unavailable for PCI resource allocation (or anything else, for that > matter)? > good point.... > 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. Although I think the workarounds more systems implement is to stick the IOMMUs into an existing hole to avoid this problem. > And we should probably do it based on the actual chipset registers, not > the DMAR tables (which the BIOS has also been known to lie about). > but.... the DMAR tables are the source of all information.... wise and ... er, um... ;-) yes, I've been on the receiving side of more bz's wrt bad DMAR tables then I can count, but... 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. 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. IMO, if we can avoid a BIOS problem, we should. The empirical data I've gathered so far in this space (IOMMU, use by SRIOV VF devices), shows the BIOS has numerous weaknesses, and this is yet another one. The BIOS's are getting better, but I've seen turtles run faster... ;-) .