* Re: [PATCH -V3] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Mel Gorman @ 2013-12-06 11:30 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: riel, paulus, linuxppc-dev, linux-mm
In-Reply-To: <1386268702-30806-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Fri, Dec 06, 2013 at 12:08:22AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> change_prot_numa should work even if _PAGE_NUMA != _PAGE_PROTNONE.
> On archs like ppc64 that don't use _PAGE_PROTNONE and also have
> a separate page table outside linux pagetable, we just need to
> make sure that when calling change_prot_numa we flush the
> hardware page table entry so that next page access result in a numa
> fault.
>
> We still need to make sure we use the numa faulting logic only
> when CONFIG_NUMA_BALANCING is set. This implies the migrate-on-fault
> (Lazy migration) via mbind will only work if CONFIG_NUMA_BALANCING
> is set.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
You're right on that there is no direct dependance on numa balancing and
use of prot_none. The BUILD_BUG_ON was to flag very clearly that arches
wanting to support automatic NUMA balancing must ensure such things as
o _PAGE_NUMA is defined
o setting _PAGE_NUMA traps a fault and the fault can be uniquely
identified as being a numa hinting fault
o that pte_present still returns true for pte_numa pages even though the
underlying present bit may be cleared. Otherwise operations like
following and copying ptes will get confused
o shortly, arches will also need to avoid taking references on pte_numa
pages in get_user_pages to account for hinting faults properly
I guess the _PAGE_NUMA parts will already be caught by other checks and
the rest will fall out during testing so it's ok to remove.
Acked-by: Mel Gorman <mgorman@suse.de>
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
From: Aneesh Kumar K.V @ 2013-12-06 10:38 UTC (permalink / raw)
To: Hong H. Pham, linux-rt-users, linuxppc-dev
Cc: Paul Mackerras, Hong H. Pham, linux-stable
In-Reply-To: <1386258894-21851-1-git-send-email-hong.pham@windriver.com>
"Hong H. Pham" <hong.pham@windriver.com> writes:
> In pte_alloc_one(), pgtable_page_ctor() is passed an address that has
> not been converted by page_address() to the newly allocated PTE page.
>
> When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor()
> with an address to the PTE page that has been converted by page_address().
> The mismatch in the PTE's page address causes pgtable_page_dtor() to access
> invalid memory, so resources for that PTE (such as the page lock) is not
> properly cleaned up.
>
> This bug was introduced by commit d614bb041209fd7cb5e4b35e11a7b2f6ee8f62b8
> "powerpc: Move the pte free routines from common header".
>
> On a preempt-rt kernel, a spinlock is dynamically allocated for each
> PTE in pgtable_page_ctor(). When the PTE is freed, calling
> pgtable_page_dtor() with a mismatched page address causes a memory leak,
> as the pointer to the PTE's spinlock is bogus.
>
> On mainline, there isn't any immediately obvious symptoms, but the
> problem still exists here.
can you also specifiy the config details here. ie, 4K page size functions
are broken ?
>
> Fixes: d614bb041209fd7c "powerpc: Move the pte free routes from common header"
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: linux-stable <stable@vger.kernel.org> # v3.10+
> Signed-off-by: Hong H. Pham <hong.pham@windriver.com>
> ---
> arch/powerpc/include/asm/pgalloc-32.h | 2 +-
> arch/powerpc/include/asm/pgalloc-64.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pgalloc-32.h b/arch/powerpc/include/asm/pgalloc-32.h
> index 27b2386..7ff24f0 100644
> --- a/arch/powerpc/include/asm/pgalloc-32.h
> +++ b/arch/powerpc/include/asm/pgalloc-32.h
> @@ -87,7 +87,7 @@ static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
> struct page *page = page_address(table);
>
> tlb_flush_pgtable(tlb, address);
> - pgtable_page_dtor(page);
> + pgtable_page_dtor(table);
> pgtable_free_tlb(tlb, page, 0);
> }
> #endif /* _ASM_POWERPC_PGALLOC_32_H */
> diff --git a/arch/powerpc/include/asm/pgalloc-64.h b/arch/powerpc/include/asm/pgalloc-64.h
> index f65e27b..b187dc5 100644
> --- a/arch/powerpc/include/asm/pgalloc-64.h
> +++ b/arch/powerpc/include/asm/pgalloc-64.h
> @@ -147,7 +147,7 @@ static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
> struct page *page = page_address(table);
That one is also wrong right ? why not
>
> tlb_flush_pgtable(tlb, address);
> - pgtable_page_dtor(page);
> + pgtable_page_dtor(table);
> pgtable_free_tlb(tlb, page, 0);
> }
>
make it closer to what it was before,
pgtable_page_dtor(table);
pgtable_free_tlb(tlb, page_address(table), 0);
This is what we had before
-static inline void __pte_free_tlb(struct mmu_gather *tlb, struct page *ptepage,
- unsigned long address)
-{
- tlb_flush_pgtable(tlb, address);
- pgtable_page_dtor(ptepage);
- pgtable_free_tlb(tlb, page_address(ptepage), 0);
-}
-aneesh
^ permalink raw reply
* Re: [PATCH v3 00/11] Introduce pcim_enable_msi*() family helpers
From: Alexander Gordeev @ 2013-12-06 8:39 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Mark Lord, linux-pci, linux-kernel, Michael Ellerman,
Ben Hutchings, David Laight, H. Peter Anvin, Tejun Heo,
linuxppc-dev
In-Reply-To: <cover.1385399393.git.agordeev@redhat.com>
On Tue, Nov 26, 2013 at 10:09:49AM +0100, Alexander Gordeev wrote:
> Patches 3,4 - fixes for PowerPC pSeries platform
[...]
> PCI/MSI/pSeries: Fix wrong error code reporting
> PCI/MSI/pSeries: Make quota traversing and requesting race-safe
Hi Bjorn,
The two unreviewed PowerPC patches is not a blocker for the rest of the
series as they are completely independent with the rest of the changes.
I can rework them later if needed.
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Bharat Bhushan @ 2013-12-06 4:17 UTC (permalink / raw)
To: Scott Wood
Cc: linux-pci@vger.kernel.org, agraf@suse.de,
iommu@lists.linux-foundation.org, Stuart Yoder, Alex Williamson,
bhelgaas@google.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1386288052.7375.100.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNiwgMjAxMyA1OjMxIEFNDQo+IFRvOiBCaHVz
aGFuIEJoYXJhdC1SNjU3NzcNCj4gQ2M6IEFsZXggV2lsbGlhbXNvbjsgbGludXgtcGNpQHZnZXIu
a2VybmVsLm9yZzsgYWdyYWZAc3VzZS5kZTsgWW9kZXIgU3R1YXJ0LQ0KPiBCMDgyNDg7IGlvbW11
QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOyBiaGVsZ2Fhc0Bnb29nbGUuY29tOyBsaW51eHBw
Yy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcN
Cj4gU3ViamVjdDogUmU6IFtQQVRDSCAwLzkgdjJdIHZmaW8tcGNpOiBhZGQgc3VwcG9ydCBmb3Ig
RnJlZXNjYWxlIElPTU1VIChQQU1VKQ0KPiANCj4gT24gU3VuLCAyMDEzLTExLTI0IGF0IDIzOjMz
IC0wNjAwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEFsZXggV2lsbGlhbXNvbiBbbWFpbHRvOmFsZXgud2ls
bGlhbXNvbkByZWRoYXQuY29tXQ0KPiA+ID4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAyMiwgMjAx
MyAyOjMxIEFNDQo+ID4gPiBUbzogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IENjOiBCaHVzaGFu
IEJoYXJhdC1SNjU3Nzc7IGxpbnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmc7IGFncmFmQHN1c2UuZGU7
DQo+ID4gPiBZb2RlciBTdHVhcnQtQjA4MjQ4OyBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9u
Lm9yZzsNCj4gPiA+IGJoZWxnYWFzQGdvb2dsZS5jb207IGxpbnV4cHBjLSBkZXZAbGlzdHMub3ps
YWJzLm9yZzsNCj4gPiA+IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4gPiA+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggMC85IHYyXSB2ZmlvLXBjaTogYWRkIHN1cHBvcnQgZm9yIEZyZWVzY2Fs
ZQ0KPiA+ID4gSU9NTVUgKFBBTVUpDQo+ID4gPg0KPiA+ID4gT24gVGh1LCAyMDEzLTExLTIxIGF0
IDE0OjQ3IC0wNjAwLCBTY290dCBXb29kIHdyb3RlOg0KPiA+ID4gPiBPbiBUaHUsIDIwMTMtMTEt
MjEgYXQgMTM6NDMgLTA3MDAsIEFsZXggV2lsbGlhbXNvbiB3cm90ZToNCj4gPiA+ID4gPiBPbiBU
aHUsIDIwMTMtMTEtMjEgYXQgMTE6MjAgKzAwMDAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+
ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+
ID4gPiA+ID4gRnJvbTogQWxleCBXaWxsaWFtc29uIFttYWlsdG86YWxleC53aWxsaWFtc29uQHJl
ZGhhdC5jb21dDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyMSwgMjAx
MyAxMjoxNyBBTQ0KPiA+ID4gPiA+ID4gPiBUbzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4g
PiA+ID4gPiA+IENjOiBqb3JvQDhieXRlcy5vcmc7IGJoZWxnYWFzQGdvb2dsZS5jb207IGFncmFm
QHN1c2UuZGU7DQo+ID4gPiA+ID4gPiA+IFdvb2QgU2NvdHQtQjA3NDIxOyBZb2RlciBTdHVhcnQt
QjA4MjQ4Ow0KPiA+ID4gPiA+ID4gPiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsg
bGludXgtDQo+ID4gPiA+ID4gPiA+IHBjaUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBs
aXN0cy5vemxhYnMub3JnOyBsaW51eC0NCj4gPiA+ID4gPiA+ID4ga2VybmVsQHZnZXIua2VybmVs
Lm9yZzsgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBb
UEFUQ0ggMC85IHYyXSB2ZmlvLXBjaTogYWRkIHN1cHBvcnQgZm9yDQo+ID4gPiA+ID4gPiA+IEZy
ZWVzY2FsZSBJT01NVSAoUEFNVSkNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gSXMgVkZJ
T19JT01NVV9QQU1VX0dFVF9NU0lfQkFOS19DT1VOVCBwZXIgYXBlcnR1cmUgKGllLiBlYWNoDQo+
ID4gPiA+ID4gPiA+IHZmaW8gdXNlciBoYXMgJENPVU5UIHJlZ2lvbnMgYXQgdGhlaXIgZGlzcG9z
YWwgZXhjbHVzaXZlbHkpPw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE51bWJlciBvZiBtc2kt
YmFuayBjb3VudCBpcyBzeXN0ZW0gd2lkZSBhbmQgbm90IHBlciBhcGVydHVyZSwNCj4gPiA+ID4g
PiA+IEJ1dCB3aWxsIGJlDQo+ID4gPiBzZXR0aW5nIHdpbmRvd3MgZm9yIGJhbmtzIGluIHRoZSBk
ZXZpY2UgYXBlcnR1cmUuDQo+ID4gPiA+ID4gPiBTbyBzYXkgaWYgd2UgYXJlIGRpcmVjdCBhc3Np
Z25pbmcgMiBwY2kgZGV2aWNlIChib3RoIGhhdmUNCj4gPiA+ID4gPiA+IGRpZmZlcmVudCBpb21t
dQ0KPiA+ID4gZ3JvdXAsIHNvIDIgYXBlcnR1cmUgaW4gaW9tbXUpIHRvIFZNLg0KPiA+ID4gPiA+
ID4gTm93IHFlbXUgY2FuIG1ha2Ugb25seSBvbmUgY2FsbCB0byBrbm93IGhvdyBtYW55IG1zaS1i
YW5rcyBhcmUNCj4gPiA+ID4gPiA+IHRoZXJlIGJ1dA0KPiA+ID4gaXQgbXVzdCBzZXQgc3ViLXdp
bmRvd3MgZm9yIGFsbCBiYW5rcyBmb3IgYm90aCBwY2kgZGV2aWNlIGluIGl0cw0KPiA+ID4gcmVz
cGVjdGl2ZSBhcGVydHVyZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEknbSBzdGlsbCBjb25mdXNl
ZC4gIFdoYXQgSSB3YW50IHRvIG1ha2Ugc3VyZSBvZiBpcyB0aGF0IHRoZQ0KPiA+ID4gPiA+IGJh
bmtzIGFyZSBpbmRlcGVuZGVudCBwZXIgYXBlcnR1cmUuICBGb3IgaW5zdGFuY2UsIGlmIHdlIGhh
dmUNCj4gPiA+ID4gPiB0d28gc2VwYXJhdGUgdXNlcnNwYWNlIHByb2Nlc3NlcyBvcGVyYXRpbmcg
aW5kZXBlbmRlbnRseSBhbmQNCj4gPiA+ID4gPiB0aGV5IGJvdGggY2hvc2UgdG8gdXNlIG1zaSBi
YW5rIHplcm8gZm9yIHRoZWlyIGRldmljZSwgdGhhdCdzDQo+ID4gPiA+ID4gYmFuayB6ZXJvIHdp
dGhpbiBlYWNoIGFwZXJ0dXJlIGFuZCBkb2Vzbid0IGludGVyZmVyZS4gIE9yDQo+ID4gPiA+ID4g
YW5vdGhlciB3YXkgdG8gYXNrIGlzIGNhbiBhIG1hbGljaW91cyB1c2VyIGludGVyZmVyZSB3aXRo
IG90aGVyIHVzZXJzIGJ5DQo+IHVzaW5nIHRoZSB3cm9uZyBiYW5rLg0KPiA+ID4gPiA+IFRoYW5r
cywNCj4gPiA+ID4NCj4gPiA+ID4gVGhleSBjYW4gaW50ZXJmZXJlLg0KPiA+DQo+ID4gV2FudCB0
byBiZSBzdXJlIG9mIGhvdyB0aGV5IGNhbiBpbnRlcmZlcmU/DQo+IA0KPiBJZiBtb3JlIHRoYW4g
b25lIFZGSU8gdXNlciBzaGFyZXMgdGhlIHNhbWUgTVNJIGdyb3VwLCBvbmUgb2YgdGhlIHVzZXJz
IGNhbiBzZW5kDQo+IE1TSXMgdG8gYW5vdGhlciB1c2VyLCBieSB1c2luZyB0aGUgd3JvbmcgaW50
ZXJydXB0IHdpdGhpbiB0aGUgYmFuay4gIFVuZXhwZWN0ZWQNCj4gTVNJcyBjb3VsZCBjYXVzZSBt
aXNiZWhhdmlvciBvciBkZW5pYWwgb2Ygc2VydmljZS4NCj4gDQo+ID4gPj4gIFdpdGggdGhpcyBo
YXJkd2FyZSwgdGhlIG9ubHkgd2F5IHRvIHByZXZlbnQgdGhhdA0KPiA+ID4gPiBpcyB0byBtYWtl
IHN1cmUgdGhhdCBhIGJhbmsgaXMgbm90IHNoYXJlZCBieSBtdWx0aXBsZSBwcm90ZWN0aW9uIGNv
bnRleHRzLg0KPiA+ID4gPiBGb3Igc29tZSBvZiBvdXIgdXNlcnMsIHRob3VnaCwgSSBiZWxpZXZl
IHByZXZlbnRpbmcgdGhpcyBpcyBsZXNzDQo+ID4gPiA+IGltcG9ydGFudCB0aGFuIHRoZSBwZXJm
b3JtYW5jZSBiZW5lZml0Lg0KPiA+DQo+ID4gU28gc2hvdWxkIHdlIGxldCB0aGlzIHBhdGNoIHNl
cmllcyBpbiB3aXRob3V0IHByb3RlY3Rpb24/DQo+IA0KPiBObywgdGhlcmUgc2hvdWxkIGJlIHNv
bWUgc29ydCBvZiBvcHQtaW4gbWVjaGFuaXNtIHNpbWlsYXIgdG8gSU9NTVUtbGVzcyBWRklPIC0t
DQo+IGJ1dCBub3QgdGhlIHNhbWUgZXhhY3Qgb25lLCBzaW5jZSBvbmUgaXMgYSBtdWNoIG1vcmUg
c2VyaW91cyBsb3NzIG9mIGlzb2xhdGlvbg0KPiB0aGFuIHRoZSBvdGhlci4NCg0KQ2FuIHlvdSBw
bGVhc2UgZWxhYm9yYXRlICJvcHQtaW4gbWVjaGFuaXNtIj8NCg0KPiANCj4gPiA+IEkgdGhpbmsg
d2UgbmVlZCBzb21lIHNvcnQgb2Ygb3duZXJzaGlwIG1vZGVsIGFyb3VuZCB0aGUgbXNpIGJhbmtz
IHRoZW4uDQo+ID4gPiBPdGhlcndpc2UgdGhlcmUncyBub3RoaW5nIHByZXZlbnRpbmcgYW5vdGhl
ciB1c2Vyc3BhY2UgZnJvbQ0KPiA+ID4gYXR0ZW1wdGluZyBhbiBNU0kgYmFzZWQgYXR0YWNrIG9u
IG90aGVyIHVzZXJzLCBvciBwZXJoYXBzIGV2ZW4gb24NCj4gPiA+IHRoZSBob3N0LiAgVkZJTyBj
YW4ndCBhbGxvdyB0aGF0LiAgVGhhbmtzLA0KPiA+DQo+ID4gV2UgaGF2ZSB2ZXJ5IGZldyAoMyBN
U0kgYmFuayBvbiBtb3N0IG9mIGNoaXBzKSwgc28gd2UgY2FuIG5vdCBhc3NpZ24NCj4gPiBvbmUg
dG8gZWFjaCB1c2Vyc3BhY2UuDQo+IA0KPiBUaGF0IGRlcGVuZHMgb24gaG93IG1hbnkgdXNlcnMg
dGhlcmUgYXJlLg0KDQpXaGF0IEkgdGhpbmsgd2UgY2FuIGRvIGlzOg0KIC0gUmVzZXJ2ZSBvbmUg
TVNJIHJlZ2lvbiBmb3IgaG9zdC4gSG9zdCB3aWxsIG5vdCBzaGFyZSBNU0kgcmVnaW9uIHdpdGgg
R3Vlc3QuDQogLSBGb3IgdXB0byAyIEd1ZXN0IChNQVggbXNpIHdpdGggaG9zdCAtIDEpIGdpdmUg
dGhlbiBzZXBhcmF0ZSBNU0kgc3ViIHJlZ2lvbnMNCiAtIEFkZGl0aW9uYWwgR3Vlc3Qgd2lsbCBz
aGFyZSBNU0kgcmVnaW9uIHdpdGggb3RoZXIgZ3Vlc3QuDQoNCkFueSBiZXR0ZXIgc3VnZ2VzdGlv
biBhcmUgbW9zdCB3ZWxjb21lLg0KDQpUaGFua3MNCi1CaGFyYXQNCj4gDQo+IC1TY290dA0KPiAN
Cg0K
^ permalink raw reply
* RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Bharat Bhushan @ 2013-12-06 4:11 UTC (permalink / raw)
To: Scott Wood
Cc: linux-pci@vger.kernel.org, agraf@suse.de,
iommu@lists.linux-foundation.org, Stuart Yoder, Alex Williamson,
bhelgaas@google.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1386289316.7375.107.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNiwgMjAxMyA1OjUyIEFNDQo+IFRvOiBCaHVz
aGFuIEJoYXJhdC1SNjU3NzcNCj4gQ2M6IEFsZXggV2lsbGlhbXNvbjsgbGludXgtcGNpQHZnZXIu
a2VybmVsLm9yZzsgYWdyYWZAc3VzZS5kZTsgWW9kZXIgU3R1YXJ0LQ0KPiBCMDgyNDg7IGlvbW11
QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOyBiaGVsZ2Fhc0Bnb29nbGUuY29tOyBsaW51eHBw
Yy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcN
Cj4gU3ViamVjdDogUmU6IFtQQVRDSCAwLzkgdjJdIHZmaW8tcGNpOiBhZGQgc3VwcG9ydCBmb3Ig
RnJlZXNjYWxlIElPTU1VIChQQU1VKQ0KPiANCj4gT24gVGh1LCAyMDEzLTExLTI4IGF0IDAzOjE5
IC0wNjAwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiA+ID4gU2Vu
dDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMyA5OjM5IFBNDQo+ID4gPiBUbzogJ0FsZXgg
V2lsbGlhbXNvbicNCj4gPiA+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgbGludXgtcGNpQHZnZXIu
a2VybmVsLm9yZzsgYWdyYWZAc3VzZS5kZTsNCj4gPiA+IFlvZGVyIFN0dWFydC0gQjA4MjQ4OyBp
b21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsNCj4gPiA+IGJoZWxnYWFzQGdvb2dsZS5j
b207IGxpbnV4cHBjLSBkZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gPiA+IGxpbnV4LWtlcm5lbEB2
Z2VyLmtlcm5lbC5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggMC85IHYyXSB2ZmlvLXBj
aTogYWRkIHN1cHBvcnQgZm9yIEZyZWVzY2FsZQ0KPiA+ID4gSU9NTVUgKFBBTVUpDQo+ID4gPg0K
PiA+ID4NCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+
IEZyb206IEFsZXggV2lsbGlhbXNvbiBbbWFpbHRvOmFsZXgud2lsbGlhbXNvbkByZWRoYXQuY29t
XQ0KPiA+ID4gPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDI1LCAyMDEzIDEwOjA4IFBNDQo+ID4g
PiA+IFRvOiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4gPiA+ID4gQ2M6IFdvb2QgU2NvdHQtQjA3
NDIxOyBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOyBhZ3JhZkBzdXNlLmRlOw0KPiA+ID4gPiBZ
b2Rlcg0KPiA+ID4gPiBTdHVhcnQtIEIwODI0ODsgaW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlv
bi5vcmc7DQo+ID4gPiA+IGJoZWxnYWFzQGdvb2dsZS5jb207DQo+ID4gPiA+IGxpbnV4cHBjLSBk
ZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZw0KPiA+ID4g
PiBTdWJqZWN0OiBSZTogW1BBVENIIDAvOSB2Ml0gdmZpby1wY2k6IGFkZCBzdXBwb3J0IGZvciBG
cmVlc2NhbGUNCj4gPiA+ID4gSU9NTVUNCj4gPiA+ID4gKFBBTVUpDQo+ID4gPiA+DQo+ID4gPiA+
IE9uIE1vbiwgMjAxMy0xMS0yNSBhdCAwNTozMyArMDAwMCwgQmhhcmF0IEJodXNoYW4gd3JvdGU6
DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g
PiA+ID4gPiBGcm9tOiBBbGV4IFdpbGxpYW1zb24gW21haWx0bzphbGV4LndpbGxpYW1zb25AcmVk
aGF0LmNvbV0NCj4gPiA+ID4gPiA+IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjIsIDIwMTMgMjoz
MSBBTQ0KPiA+ID4gPiA+ID4gVG86IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gPiBDYzog
Qmh1c2hhbiBCaGFyYXQtUjY1Nzc3OyBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOw0KPiA+ID4g
PiA+ID4gYWdyYWZAc3VzZS5kZTsgWW9kZXIgU3R1YXJ0LUIwODI0ODsNCj4gPiA+ID4gPiA+IGlv
bW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOyBiaGVsZ2Fhc0Bnb29nbGUuY29tOw0KPiA+
ID4gPiA+ID4gbGludXhwcGMtIGRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC1rZXJuZWxAdmdl
ci5rZXJuZWwub3JnDQo+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDAvOSB2Ml0gdmZp
by1wY2k6IGFkZCBzdXBwb3J0IGZvcg0KPiA+ID4gPiA+ID4gRnJlZXNjYWxlIElPTU1VIChQQU1V
KQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE9uIFRodSwgMjAxMy0xMS0yMSBhdCAxNDo0NyAt
MDYwMCwgU2NvdHQgV29vZCB3cm90ZToNCj4gPiA+ID4gPiA+ID4gT24gVGh1LCAyMDEzLTExLTIx
IGF0IDEzOjQzIC0wNzAwLCBBbGV4IFdpbGxpYW1zb24gd3JvdGU6DQo+ID4gPiA+ID4gPiA+ID4g
T24gVGh1LCAyMDEzLTExLTIxIGF0IDExOjIwICswMDAwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToN
Cj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+ID4gPiA+ID4gPiA+ID4gPiA+IEZyb206IEFsZXggV2lsbGlhbXNvbg0KPiA+
ID4gPiA+ID4gPiA+ID4gPiBbbWFpbHRvOmFsZXgud2lsbGlhbXNvbkByZWRoYXQuY29tXQ0KPiA+
ID4gPiA+ID4gPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjEsIDIwMTMgMTI6MTcg
QU0NCj4gPiA+ID4gPiA+ID4gPiA+ID4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiA+ID4g
PiA+ID4gPiA+ID4gPiBDYzogam9yb0A4Ynl0ZXMub3JnOyBiaGVsZ2Fhc0Bnb29nbGUuY29tOw0K
PiA+ID4gPiA+ID4gPiA+ID4gPiBhZ3JhZkBzdXNlLmRlOyBXb29kIFNjb3R0LUIwNzQyMTsgWW9k
ZXIgU3R1YXJ0LUIwODI0ODsNCj4gPiA+ID4gPiA+ID4gPiA+ID4gaW9tbXVAbGlzdHMubGludXgt
Zm91bmRhdGlvbi5vcmc7IGxpbnV4LQ0KPiA+ID4gPiA+ID4gPiA+ID4gPiBwY2lAdmdlci5rZXJu
ZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gPiA+ID4gPiA+ID4gPiA+
ID4gbGludXgtIGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0K
PiA+ID4gPiA+ID4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDAvOSB2Ml0gdmZpby1wY2k6
IGFkZCBzdXBwb3J0IGZvcg0KPiA+ID4gPiA+ID4gPiA+ID4gPiBGcmVlc2NhbGUgSU9NTVUgKFBB
TVUpDQo+ID4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4gPiA+IElzIFZGSU9fSU9N
TVVfUEFNVV9HRVRfTVNJX0JBTktfQ09VTlQgcGVyIGFwZXJ0dXJlIChpZS4NCj4gPiA+ID4gPiA+
ID4gPiA+ID4gZWFjaCB2ZmlvIHVzZXIgaGFzICRDT1VOVCByZWdpb25zIGF0IHRoZWlyIGRpc3Bv
c2FsDQo+IGV4Y2x1c2l2ZWx5KT8NCj4gPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4g
PiBOdW1iZXIgb2YgbXNpLWJhbmsgY291bnQgaXMgc3lzdGVtIHdpZGUgYW5kIG5vdCBwZXINCj4g
PiA+ID4gPiA+ID4gPiA+IGFwZXJ0dXJlLCBCdXQgd2lsbCBiZQ0KPiA+ID4gPiA+ID4gc2V0dGlu
ZyB3aW5kb3dzIGZvciBiYW5rcyBpbiB0aGUgZGV2aWNlIGFwZXJ0dXJlLg0KPiA+ID4gPiA+ID4g
PiA+ID4gU28gc2F5IGlmIHdlIGFyZSBkaXJlY3QgYXNzaWduaW5nIDIgcGNpIGRldmljZSAoYm90
aA0KPiA+ID4gPiA+ID4gPiA+ID4gaGF2ZSBkaWZmZXJlbnQgaW9tbXUNCj4gPiA+ID4gPiA+IGdy
b3VwLCBzbyAyIGFwZXJ0dXJlIGluIGlvbW11KSB0byBWTS4NCj4gPiA+ID4gPiA+ID4gPiA+IE5v
dyBxZW11IGNhbiBtYWtlIG9ubHkgb25lIGNhbGwgdG8ga25vdyBob3cgbWFueQ0KPiA+ID4gPiA+
ID4gPiA+ID4gbXNpLWJhbmtzIGFyZSB0aGVyZSBidXQNCj4gPiA+ID4gPiA+IGl0IG11c3Qgc2V0
IHN1Yi13aW5kb3dzIGZvciBhbGwgYmFua3MgZm9yIGJvdGggcGNpIGRldmljZSBpbg0KPiA+ID4g
PiA+ID4gaXRzIHJlc3BlY3RpdmUgYXBlcnR1cmUuDQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g
PiA+ID4gPiBJJ20gc3RpbGwgY29uZnVzZWQuICBXaGF0IEkgd2FudCB0byBtYWtlIHN1cmUgb2Yg
aXMgdGhhdA0KPiA+ID4gPiA+ID4gPiA+IHRoZSBiYW5rcyBhcmUgaW5kZXBlbmRlbnQgcGVyIGFw
ZXJ0dXJlLiAgRm9yIGluc3RhbmNlLCBpZg0KPiA+ID4gPiA+ID4gPiA+IHdlIGhhdmUgdHdvIHNl
cGFyYXRlIHVzZXJzcGFjZSBwcm9jZXNzZXMgb3BlcmF0aW5nDQo+ID4gPiA+ID4gPiA+ID4gaW5k
ZXBlbmRlbnRseSBhbmQgdGhleSBib3RoIGNob3NlIHRvIHVzZSBtc2kgYmFuayB6ZXJvIGZvcg0K
PiA+ID4gPiA+ID4gPiA+IHRoZWlyIGRldmljZSwgdGhhdCdzIGJhbmsgemVybyB3aXRoaW4gZWFj
aCBhcGVydHVyZSBhbmQNCj4gPiA+ID4gPiA+ID4gPiBkb2Vzbid0IGludGVyZmVyZS4gIE9yIGFu
b3RoZXIgd2F5IHRvIGFzayBpcyBjYW4gYQ0KPiA+ID4gPiA+ID4gPiA+IG1hbGljaW91cyB1c2Vy
IGludGVyZmVyZSB3aXRoIG90aGVyIHVzZXJzIGJ5DQo+ID4gPiA+IHVzaW5nIHRoZSB3cm9uZyBi
YW5rLg0KPiA+ID4gPiA+ID4gPiA+IFRoYW5rcywNCj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+
ID4gVGhleSBjYW4gaW50ZXJmZXJlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2FudCB0byBiZSBz
dXJlIG9mIGhvdyB0aGV5IGNhbiBpbnRlcmZlcmU/DQo+ID4gPiA+DQo+ID4gPiA+IFdoYXQgaGFw
cGVucyBpZiBtb3JlIHRoYW4gb25lIHVzZXIgc2VsZWN0cyB0aGUgc2FtZSBNU0kgYmFuaz8NCj4g
PiA+ID4gTWluaW1hbGx5LCB3b3VsZG4ndCB0aGF0IHJlc3VsdCBpbiB0aGUgSU9NTVUgYmxvY2tp
bmcgdHJhbnNhY3Rpb25zDQo+ID4gPiA+IGZyb20gdGhlIHByZXZpb3VzIHVzZXIgb25jZSB0aGUg
bmV3IHVzZXIgYWN0aXZhdGVzIHRoZWlyIG1hcHBpbmc/DQo+ID4gPg0KPiA+ID4gWWVzIGFuZCBu
bzsgV2l0aCBjdXJyZW50IGltcGxlbWVudGF0aW9uIHllcyBidXQgd2l0aCBhIG1pbm9yIGNoYW5n
ZQ0KPiA+ID4gbm8uIExhdGVyIGluIHRoaXMgcmVzcG9uc2UgSSB3aWxsIGV4cGxhaW4gaG93Lg0K
PiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiA+PiAgV2l0aCB0aGlzIGhhcmR3YXJlLCB0aGUgb25s
eSB3YXkgdG8gcHJldmVudCB0aGF0DQo+ID4gPiA+ID4gPiA+IGlzIHRvIG1ha2Ugc3VyZSB0aGF0
IGEgYmFuayBpcyBub3Qgc2hhcmVkIGJ5IG11bHRpcGxlDQo+ID4gPiA+ID4gPiA+IHByb3RlY3Rp
b24NCj4gPiA+IGNvbnRleHRzLg0KPiA+ID4gPiA+ID4gPiBGb3Igc29tZSBvZiBvdXIgdXNlcnMs
IHRob3VnaCwgSSBiZWxpZXZlIHByZXZlbnRpbmcgdGhpcyBpcw0KPiA+ID4gPiA+ID4gPiBsZXNz
IGltcG9ydGFudCB0aGFuIHRoZSBwZXJmb3JtYW5jZSBiZW5lZml0Lg0KPiA+ID4gPiA+DQo+ID4g
PiA+ID4gU28gc2hvdWxkIHdlIGxldCB0aGlzIHBhdGNoIHNlcmllcyBpbiB3aXRob3V0IHByb3Rl
Y3Rpb24/DQo+ID4gPiA+DQo+ID4gPiA+IE5vLg0KPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+
ID4gPiA+IEkgdGhpbmsgd2UgbmVlZCBzb21lIHNvcnQgb2Ygb3duZXJzaGlwIG1vZGVsIGFyb3Vu
ZCB0aGUgbXNpIGJhbmtzDQo+IHRoZW4uDQo+ID4gPiA+ID4gPiBPdGhlcndpc2UgdGhlcmUncyBu
b3RoaW5nIHByZXZlbnRpbmcgYW5vdGhlciB1c2Vyc3BhY2UgZnJvbQ0KPiA+ID4gPiA+ID4gYXR0
ZW1wdGluZyBhbiBNU0kgYmFzZWQgYXR0YWNrIG9uIG90aGVyIHVzZXJzLCBvciBwZXJoYXBzIGV2
ZW4NCj4gPiA+ID4gPiA+IG9uIHRoZSBob3N0LiAgVkZJTyBjYW4ndCBhbGxvdyB0aGF0LiAgVGhh
bmtzLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2UgaGF2ZSB2ZXJ5IGZldyAoMyBNU0kgYmFuayBv
biBtb3N0IG9mIGNoaXBzKSwgc28gd2UgY2FuIG5vdA0KPiA+ID4gPiA+IGFzc2lnbiBvbmUgdG8g
ZWFjaCB1c2Vyc3BhY2UuIFdoYXQgd2UgY2FuIGRvIGlzIGhvc3QgYW5kDQo+ID4gPiA+ID4gdXNl
cnNwYWNlIGRvZXMgbm90IHNoYXJlIGEgTVNJIGJhbmsgd2hpbGUgdXNlcnNwYWNlIHdpbGwgc2hh
cmUgYSBNU0kNCj4gYmFuay4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlbiB5b3UgcHJvYmFibHkgbmVl
ZCBWRklPIHRvICJvd24iIHRoZSBNU0kgYmFuayBhbmQgcHJvZ3JhbQ0KPiA+ID4gPiBkZXZpY2Vz
IGludG8gaXQgcmF0aGVyIHRoYW4gZXhwb3NpbmcgdGhlIE1TSSBiYW5rcyB0byB1c2Vyc3BhY2Ug
dG8NCj4gPiA+ID4gbGV0IHRoZW0gaGF2ZQ0KPiA+ID4gZGlyZWN0IGFjY2Vzcy4NCj4gPiA+DQo+
ID4gPiBPdmVyYWxsIGlkZWEgb2YgZXhwb3NpbmcgdGhlIGRldGFpbHMgb2YgbXNpIHJlZ2lvbnMg
dG8gdXNlcnNwYWNlIGFyZQ0KPiA+ID4gIDEpIFVzZXIgc3BhY2UgY2FuIGRlZmluZSB0aGUgYXBl
cnR1cmUgc2l6ZSB0byBmaXQgTVNJIG1hcHBpbmcgaW4gSU9NTVUuDQo+ID4gPiAgMikgc2V0dXAg
aW92YSBmb3IgYSBNU0kgYmFua3M7IHdoaWNoIGlzIGp1c3QgYWZ0ZXIgZ3Vlc3QgbWVtb3J5Lg0K
PiA+ID4NCj4gPiA+IEJ1dCBjdXJyZW50bHkgd2UgZXhwb3NlIHRoZSAic2l6ZSIgYW5kICJhZGRy
ZXNzIiBvZiBNU0kgYmFua3MsDQo+ID4gPiBwYXNzaW5nIGFkZHJlc3MgaXMgb2Ygbm8gdXNlIGFu
ZCBjYW4gYmUgcHJvYmxlbWF0aWMuDQo+ID4NCj4gPiBJIGFtIHNvcnJ5LCBhYm92ZSBpbmZvcm1h
dGlvbiBpcyBub3QgY29ycmVjdC4gQ3VycmVudGx5IG5laXRoZXIgd2UgZXhwb3NlDQo+ICJhZGRy
ZXNzIiBub3IgInNpemUiIHRvIHVzZXIgc3BhY2UuIFdlIG9ubHkgZXhwb3NlIG51bWJlciBvZiBN
U0kgQkFOSyBjb3VudCBhbmQNCj4gdXNlcnNwYWNlIGFkZHMgb25lIHN1Yi13aW5kb3cgZm9yIGVh
Y2ggYmFuay4NCj4gPg0KPiA+ID4gSWYgd2UganVzdCBwcm92aWRlIHRoZSBzaXplIG9mIE1TSSBi
YW5rIHRvIHVzZXJzcGFjZSB0aGVuIHVzZXJzcGFjZQ0KPiA+ID4gY2Fubm90IGRvIGFueXRoaW5n
IHdyb25nLg0KPiA+DQo+ID4gU28gdXNlcnNwYWNlIGRvZXMgbm90IGtub3cgYWRkcmVzcywgc28g
aXQgY2Fubm90IG1tYXAgYW5kIGNhdXNlIGFueQ0KPiBpbnRlcmZlcmVuY2UgYnkgZGlyZWN0bHkg
cmVhZGluZy93cml0aW5nLg0KPiANCj4gVGhhdCdzIHNlY3VyaXR5IHRocm91Z2ggb2JzY3VyaXR5
Li4uICBDb3VsZG4ndCB0aGUgbWFsaWNpb3VzIHVzZXIgZmluZCBvdXQgdGhlDQo+IGFkZHJlc3Mg
dmlhIG90aGVyIG1lYW5zLCBzdWNoIGFzIGV4cGVyaW1lbnRhdGlvbiBvbiBhbm90aGVyIHN5c3Rl
bSBvdmVyIHdoaWNoDQo+IHRoZXkgaGF2ZSBmdWxsIGNvbnRyb2w/ICBXaGF0IHdvdWxkIGhhcHBl
biBpZiB0aGUgdXNlciByZWFkcyBmcm9tIHRoZWlyIGRldmljZSdzDQo+IFBDSSBjb25maWcgc3Bh
Y2U/ICBPciBnZXRzIHRoZSBpbmZvcm1hdGlvbiB2aWEgc29tZSBiYWNrIGRvb3IgaW4gdGhlIFBD
SSBkZXZpY2UNCj4gdGhleSBvd24/ICBPciBwb2tlcyB0aHJvdWdob3V0IHRoZSBhZGRyZXNzIHNw
YWNlIGxvb2tpbmcgZm9yIHNvbWV0aGluZyB0aGF0DQo+IGdlbmVyYXRlcyBhbiBpbnRlcnJ1cHQg
dG8gaXRzIG93biBkZXZpY2U/DQoNClNvIGhvdyB0byBzb2x2ZSB0aGlzIHByb2JsZW0sIEFueSBz
dWdnZXN0aW9uID8NCg0KV2UgaGF2ZSB0byBtYXAgb25lIHdpbmRvdyBpbiBQQU1VIGZvciBNU0lz
IGFuZCBhIG1hbGljaW91cyB1c2VyIGNhbiBhc2sgaXRzIGRldmljZSB0byBkbyBETUEgdG8gTVNJ
IHdpbmRvdyByZWdpb24gd2l0aCBhbnkgcGFpciBvZiBhZGRyZXNzIGFuZCBkYXRhLCB3aGljaCBj
YW4gbGVhZCB0byB1bmV4cGVjdGVkIE1TSXMgaW4gc3lzdGVtPw0KDQpUaGFua3MNCi1CaGFyYXQN
Cg0KPiANCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Scott Wood @ 2013-12-06 0:21 UTC (permalink / raw)
To: Bharat Bhushan
Cc: linux-pci@vger.kernel.org, agraf@suse.de,
iommu@lists.linux-foundation.org, Yoder Stuart-B08248,
Alex Williamson, bhelgaas@google.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0723624C@039-SN2MPN1-012.039d.mgd.msft.net>
On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote:
>
> > -----Original Message-----
> > From: Bhushan Bharat-R65777
> > Sent: Wednesday, November 27, 2013 9:39 PM
> > To: 'Alex Williamson'
> > Cc: Wood Scott-B07421; linux-pci@vger.kernel.org; agraf@suse.de; Yoder Stuart-
> > B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> >
> >
> >
> > > -----Original Message-----
> > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > Sent: Monday, November 25, 2013 10:08 PM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; linux-pci@vger.kernel.org; agraf@suse.de; Yoder
> > > Stuart- B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com;
> > > linuxppc- dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU
> > > (PAMU)
> > >
> > > On Mon, 2013-11-25 at 05:33 +0000, Bharat Bhushan wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > > > Sent: Friday, November 22, 2013 2:31 AM
> > > > > To: Wood Scott-B07421
> > > > > Cc: Bhushan Bharat-R65777; linux-pci@vger.kernel.org;
> > > > > agraf@suse.de; Yoder Stuart-B08248;
> > > > > iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > > > > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > > IOMMU (PAMU)
> > > > >
> > > > > On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote:
> > > > > > On Thu, 2013-11-21 at 13:43 -0700, Alex Williamson wrote:
> > > > > > > On Thu, 2013-11-21 at 11:20 +0000, Bharat Bhushan wrote:
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > > > > > > > Sent: Thursday, November 21, 2013 12:17 AM
> > > > > > > > > To: Bhushan Bharat-R65777
> > > > > > > > > Cc: joro@8bytes.org; bhelgaas@google.com; agraf@suse.de;
> > > > > > > > > Wood Scott-B07421; Yoder Stuart-B08248;
> > > > > > > > > iommu@lists.linux-foundation.org; linux-
> > > > > > > > > pci@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > > > > > > > > kernel@vger.kernel.org; Bhushan Bharat-R65777
> > > > > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for
> > > > > > > > > Freescale IOMMU (PAMU)
> > > > > > > > >
> > > > > > > > > Is VFIO_IOMMU_PAMU_GET_MSI_BANK_COUNT per aperture (ie.
> > > > > > > > > each vfio user has $COUNT regions at their disposal exclusively)?
> > > > > > > >
> > > > > > > > Number of msi-bank count is system wide and not per
> > > > > > > > aperture, But will be
> > > > > setting windows for banks in the device aperture.
> > > > > > > > So say if we are direct assigning 2 pci device (both have
> > > > > > > > different iommu
> > > > > group, so 2 aperture in iommu) to VM.
> > > > > > > > Now qemu can make only one call to know how many msi-banks
> > > > > > > > are there but
> > > > > it must set sub-windows for all banks for both pci device in its
> > > > > respective aperture.
> > > > > > >
> > > > > > > I'm still confused. What I want to make sure of is that the
> > > > > > > banks are independent per aperture. For instance, if we have
> > > > > > > two separate userspace processes operating independently and
> > > > > > > they both chose to use msi bank zero for their device, that's
> > > > > > > bank zero within each aperture and doesn't interfere. Or
> > > > > > > another way to ask is can a malicious user interfere with
> > > > > > > other users by
> > > using the wrong bank.
> > > > > > > Thanks,
> > > > > >
> > > > > > They can interfere.
> > > >
> > > > Want to be sure of how they can interfere?
> > >
> > > What happens if more than one user selects the same MSI bank?
> > > Minimally, wouldn't that result in the IOMMU blocking transactions
> > > from the previous user once the new user activates their mapping?
> >
> > Yes and no; With current implementation yes but with a minor change no. Later in
> > this response I will explain how.
> >
> > >
> > > > >> With this hardware, the only way to prevent that
> > > > > > is to make sure that a bank is not shared by multiple protection
> > contexts.
> > > > > > For some of our users, though, I believe preventing this is less
> > > > > > important than the performance benefit.
> > > >
> > > > So should we let this patch series in without protection?
> > >
> > > No.
> > >
> > > > >
> > > > > I think we need some sort of ownership model around the msi banks then.
> > > > > Otherwise there's nothing preventing another userspace from
> > > > > attempting an MSI based attack on other users, or perhaps even on
> > > > > the host. VFIO can't allow that. Thanks,
> > > >
> > > > We have very few (3 MSI bank on most of chips), so we can not assign
> > > > one to each userspace. What we can do is host and userspace does not
> > > > share a MSI bank while userspace will share a MSI bank.
> > >
> > > Then you probably need VFIO to "own" the MSI bank and program devices
> > > into it rather than exposing the MSI banks to userspace to let them have
> > direct access.
> >
> > Overall idea of exposing the details of msi regions to userspace are
> > 1) User space can define the aperture size to fit MSI mapping in IOMMU.
> > 2) setup iova for a MSI banks; which is just after guest memory.
> >
> > But currently we expose the "size" and "address" of MSI banks, passing address
> > is of no use and can be problematic.
>
> I am sorry, above information is not correct. Currently neither we expose "address" nor "size" to user space. We only expose number of MSI BANK count and userspace adds one sub-window for each bank.
>
> > If we just provide the size of MSI bank to userspace then userspace cannot do
> > anything wrong.
>
> So userspace does not know address, so it cannot mmap and cause any interference by directly reading/writing.
That's security through obscurity... Couldn't the malicious user find
out the address via other means, such as experimentation on another
system over which they have full control? What would happen if the user
reads from their device's PCI config space? Or gets the information via
some back door in the PCI device they own? Or pokes throughout the
address space looking for something that generates an interrupt to its
own device?
-Scott
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Scott Wood @ 2013-12-06 0:00 UTC (permalink / raw)
To: Bharat Bhushan
Cc: linux-pci@vger.kernel.org, agraf@suse.de,
iommu@lists.linux-foundation.org, Yoder Stuart-B08248,
Alex Williamson, bhelgaas@google.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0722C180@039-SN2MPN1-012.039d.mgd.msft.net>
On Sun, 2013-11-24 at 23:33 -0600, Bharat Bhushan wrote:
>
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Friday, November 22, 2013 2:31 AM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-R65777; linux-pci@vger.kernel.org; agraf@suse.de; Yoder
> > Stuart-B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> >
> > On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote:
> > > On Thu, 2013-11-21 at 13:43 -0700, Alex Williamson wrote:
> > > > On Thu, 2013-11-21 at 11:20 +0000, Bharat Bhushan wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > > > > Sent: Thursday, November 21, 2013 12:17 AM
> > > > > > To: Bhushan Bharat-R65777
> > > > > > Cc: joro@8bytes.org; bhelgaas@google.com; agraf@suse.de; Wood
> > > > > > Scott-B07421; Yoder Stuart-B08248;
> > > > > > iommu@lists.linux-foundation.org; linux- pci@vger.kernel.org;
> > > > > > linuxppc-dev@lists.ozlabs.org; linux- kernel@vger.kernel.org;
> > > > > > Bhushan Bharat-R65777
> > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > > > IOMMU (PAMU)
> > > > > >
> > > > > > Is VFIO_IOMMU_PAMU_GET_MSI_BANK_COUNT per aperture (ie. each
> > > > > > vfio user has $COUNT regions at their disposal exclusively)?
> > > > >
> > > > > Number of msi-bank count is system wide and not per aperture, But will be
> > setting windows for banks in the device aperture.
> > > > > So say if we are direct assigning 2 pci device (both have different iommu
> > group, so 2 aperture in iommu) to VM.
> > > > > Now qemu can make only one call to know how many msi-banks are there but
> > it must set sub-windows for all banks for both pci device in its respective
> > aperture.
> > > >
> > > > I'm still confused. What I want to make sure of is that the banks
> > > > are independent per aperture. For instance, if we have two separate
> > > > userspace processes operating independently and they both chose to
> > > > use msi bank zero for their device, that's bank zero within each
> > > > aperture and doesn't interfere. Or another way to ask is can a
> > > > malicious user interfere with other users by using the wrong bank.
> > > > Thanks,
> > >
> > > They can interfere.
>
> Want to be sure of how they can interfere?
If more than one VFIO user shares the same MSI group, one of the users
can send MSIs to another user, by using the wrong interrupt within the
bank. Unexpected MSIs could cause misbehavior or denial of service.
> >> With this hardware, the only way to prevent that
> > > is to make sure that a bank is not shared by multiple protection contexts.
> > > For some of our users, though, I believe preventing this is less
> > > important than the performance benefit.
>
> So should we let this patch series in without protection?
No, there should be some sort of opt-in mechanism similar to IOMMU-less
VFIO -- but not the same exact one, since one is a much more serious
loss of isolation than the other.
> > I think we need some sort of ownership model around the msi banks then.
> > Otherwise there's nothing preventing another userspace from attempting an MSI
> > based attack on other users, or perhaps even on the host. VFIO can't allow
> > that. Thanks,
>
> We have very few (3 MSI bank on most of chips), so we can not assign
> one to each userspace.
That depends on how many users there are.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/defconfig: Enable ath9k wireless card support
From: Scott Wood @ 2013-12-05 23:18 UTC (permalink / raw)
To: Chunhe Lan; +Cc: linuxppc-dev
In-Reply-To: <1386055940-20629-1-git-send-email-Chunhe.Lan@freescale.com>
On Tue, 2013-12-03 at 15:32 +0800, Chunhe Lan wrote:
> On the P1023RDB, when board leaves the factory, it has
> two Atheros wireless cards on the PCIe slot. So enable
> ath9k wireless driver support.
>
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> Cc: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/configs/85xx/p1023_defconfig | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/configs/85xx/p1023_defconfig b/arch/powerpc/configs/85xx/p1023_defconfig
> index b06d37d..a3fe941 100644
> --- a/arch/powerpc/configs/85xx/p1023_defconfig
> +++ b/arch/powerpc/configs/85xx/p1023_defconfig
> @@ -62,6 +62,9 @@ CONFIG_INET_ESP=y
> # CONFIG_INET_LRO is not set
> CONFIG_IPV6=y
> CONFIG_IP_SCTP=m
> +CONFIG_CFG80211=y
> +CONFIG_CFG80211_WEXT=y
> +CONFIG_MAC80211=y
> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> @@ -101,6 +104,8 @@ CONFIG_DAVICOM_PHY=y
> CONFIG_CICADA_PHY=y
> CONFIG_VITESSE_PHY=y
> CONFIG_FIXED_PHY=y
> +CONFIG_ATH_CARDS=y
> +CONFIG_ATH9K=y
> CONFIG_INPUT_FF_MEMLESS=m
> # CONFIG_INPUT_MOUSEDEV is not set
> # CONFIG_INPUT_KEYBOARD is not set
I thought we decided the p1023 defconfig was going away (to possibly
return if/when datapath is upstreamed and is deemed too large for the
main config)?
-Scott
^ permalink raw reply
* Re: [PATCH -V2 3/5] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Benjamin Herrenschmidt @ 2013-12-05 21:00 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm, linuxppc-dev, paulus, Aneesh Kumar K.V
In-Reply-To: <52A0B786.608@redhat.com>
On Thu, 2013-12-05 at 12:27 -0500, Rik van Riel wrote:
> However, it appears that since the code was #ifdefed
> like that, the called code was made generic enough,
> that change_prot_numa should actually work for
> everything.
>
> In other words:
>
> Reviewed-by: Rik van Riel <riel@redhat.com>
Ok thanks, that's what I needed. Do you have any objection of me merging
that change via the powerpc tree along with the corresponding powerpc
bits from Aneesh ?
The other option would be to have it in a topic branch that I pull from
you.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH -V3] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Rik van Riel @ 2013-12-05 20:25 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus, mgorman; +Cc: linux-mm, linuxppc-dev
In-Reply-To: <1386268702-30806-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 12/05/2013 01:38 PM, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> change_prot_numa should work even if _PAGE_NUMA != _PAGE_PROTNONE.
> On archs like ppc64 that don't use _PAGE_PROTNONE and also have
> a separate page table outside linux pagetable, we just need to
> make sure that when calling change_prot_numa we flush the
> hardware page table entry so that next page access result in a numa
> fault.
>
> We still need to make sure we use the numa faulting logic only
> when CONFIG_NUMA_BALANCING is set. This implies the migrate-on-fault
> (Lazy migration) via mbind will only work if CONFIG_NUMA_BALANCING
> is set.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH -V3] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Aneesh Kumar K.V @ 2013-12-05 18:38 UTC (permalink / raw)
To: benh, paulus, mgorman, riel; +Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
change_prot_numa should work even if _PAGE_NUMA != _PAGE_PROTNONE.
On archs like ppc64 that don't use _PAGE_PROTNONE and also have
a separate page table outside linux pagetable, we just need to
make sure that when calling change_prot_numa we flush the
hardware page table entry so that next page access result in a numa
fault.
We still need to make sure we use the numa faulting logic only
when CONFIG_NUMA_BALANCING is set. This implies the migrate-on-fault
(Lazy migration) via mbind will only work if CONFIG_NUMA_BALANCING
is set.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
Previous discussion around the patch can be found at
http://article.gmane.org/gmane.linux.kernel.mm/109305
changes from V2:
* Move the numa faulting definition within CONFIG_NUMA_BALANCING
include/linux/mm.h | 2 +-
mm/mempolicy.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1cedd000cf29..a7b4e310bf42 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1842,7 +1842,7 @@ static inline pgprot_t vm_get_page_prot(unsigned long vm_flags)
}
#endif
-#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE
+#ifdef CONFIG_NUMA_BALANCING
unsigned long change_prot_numa(struct vm_area_struct *vma,
unsigned long start, unsigned long end);
#endif
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index eca4a3129129..9f73b29d304d 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -613,7 +613,7 @@ static inline int queue_pages_pgd_range(struct vm_area_struct *vma,
return 0;
}
-#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE
+#ifdef CONFIG_NUMA_BALANCING
/*
* This is used to mark a range of virtual addresses to be inaccessible.
* These are later cleared by a NUMA hinting fault. Depending on these
@@ -627,7 +627,6 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
unsigned long addr, unsigned long end)
{
int nr_updated;
- BUILD_BUG_ON(_PAGE_NUMA != _PAGE_PROTNONE);
nr_updated = change_protection(vma, addr, end, vma->vm_page_prot, 0, 1);
if (nr_updated)
@@ -641,7 +640,7 @@ static unsigned long change_prot_numa(struct vm_area_struct *vma,
{
return 0;
}
-#endif /* CONFIG_ARCH_USES_NUMA_PROT_NONE */
+#endif /* CONFIG_NUMA_BALANCING */
/*
* Walk through page tables and collect pages to be migrated.
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH -V2 3/5] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Rik van Riel @ 2013-12-05 17:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Aneesh Kumar K.V
Cc: linux-mm, linuxppc-dev, paulus, Mel Gorman
In-Reply-To: <1386220835.21910.21.camel@pasglop>
On 12/05/2013 12:20 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-12-05 at 10:48 +0530, Aneesh Kumar K.V wrote:
>>
>> Ok, I can move the changes below #ifdef CONFIG_NUMA_BALANCING ? We call
>> change_prot_numa from task_numa_work and queue_pages_range(). The later
>> may be an issue. So doing the below will help ?
>>
>> -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE
>> +#ifdef CONFIG_NUMA_BALANCING
>
> I will defer to Mel and Rik (should we also CC Andrea ?)
It looks like manual numa binding can also use lazy
page migration, but I am not sure if that can happen
without CONFIG_NUMA_BALANCING, or if mbind always uses
MPOL_MF_STRICT...
^ permalink raw reply
* Re: [PATCH -V2 3/5] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Rik van Riel @ 2013-12-05 17:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Aneesh Kumar K.V; +Cc: linux-mm, paulus, linuxppc-dev
In-Reply-To: <1386126782.16703.137.camel@pasglop>
On 12/03/2013 10:13 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-11-18 at 14:58 +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> change_prot_numa should work even if _PAGE_NUMA != _PAGE_PROTNONE.
>> On archs like ppc64 that don't use _PAGE_PROTNONE and also have
>> a separate page table outside linux pagetable, we just need to
>> make sure that when calling change_prot_numa we flush the
>> hardware page table entry so that next page access result in a numa
>> fault.
>
> That patch doesn't look right...
At first glance, indeed...
> You are essentially making change_prot_numa() do whatever it does (which
> I don't completely understand) *for all architectures* now, whether they
> have CONFIG_ARCH_USES_NUMA_PROT_NONE or not ... So because you want that
> behaviour on powerpc book3s64, you change everybody.
However, it appears that since the code was #ifdefed
like that, the called code was made generic enough,
that change_prot_numa should actually work for
everything.
In other words:
Reviewed-by: Rik van Riel <riel@redhat.com>
^ permalink raw reply
* [PATCH] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
From: Hong H. Pham @ 2013-12-05 15:54 UTC (permalink / raw)
To: linux-rt-users, linuxppc-dev
Cc: Paul Mackerras, Hong H. Pham, Aneesh Kumar K.V, linux-stable
In pte_alloc_one(), pgtable_page_ctor() is passed an address that has
not been converted by page_address() to the newly allocated PTE page.
When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor()
with an address to the PTE page that has been converted by page_address().
The mismatch in the PTE's page address causes pgtable_page_dtor() to access
invalid memory, so resources for that PTE (such as the page lock) is not
properly cleaned up.
This bug was introduced by commit d614bb041209fd7cb5e4b35e11a7b2f6ee8f62b8
"powerpc: Move the pte free routines from common header".
On a preempt-rt kernel, a spinlock is dynamically allocated for each
PTE in pgtable_page_ctor(). When the PTE is freed, calling
pgtable_page_dtor() with a mismatched page address causes a memory leak,
as the pointer to the PTE's spinlock is bogus.
On mainline, there isn't any immediately obvious symptoms, but the
problem still exists here.
Fixes: d614bb041209fd7c "powerpc: Move the pte free routes from common header"
Cc: Paul Mackerras <paulus@samba.org>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-stable <stable@vger.kernel.org> # v3.10+
Signed-off-by: Hong H. Pham <hong.pham@windriver.com>
---
arch/powerpc/include/asm/pgalloc-32.h | 2 +-
arch/powerpc/include/asm/pgalloc-64.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pgalloc-32.h b/arch/powerpc/include/asm/pgalloc-32.h
index 27b2386..7ff24f0 100644
--- a/arch/powerpc/include/asm/pgalloc-32.h
+++ b/arch/powerpc/include/asm/pgalloc-32.h
@@ -87,7 +87,7 @@ static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
struct page *page = page_address(table);
tlb_flush_pgtable(tlb, address);
- pgtable_page_dtor(page);
+ pgtable_page_dtor(table);
pgtable_free_tlb(tlb, page, 0);
}
#endif /* _ASM_POWERPC_PGALLOC_32_H */
diff --git a/arch/powerpc/include/asm/pgalloc-64.h b/arch/powerpc/include/asm/pgalloc-64.h
index f65e27b..b187dc5 100644
--- a/arch/powerpc/include/asm/pgalloc-64.h
+++ b/arch/powerpc/include/asm/pgalloc-64.h
@@ -147,7 +147,7 @@ static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
struct page *page = page_address(table);
tlb_flush_pgtable(tlb, address);
- pgtable_page_dtor(page);
+ pgtable_page_dtor(table);
pgtable_free_tlb(tlb, page, 0);
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 3/3] powerpc: mm: optimize for the correctly placed page
From: Liu ping fan @ 2013-12-05 13:27 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <877gbjva24.fsf@linux.vnet.ibm.com>
On Thu, Dec 5, 2013 at 6:58 PM, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Liu Ping Fan <kernelfans@gmail.com> writes:
>
>> The period check of _PAGE_NUMA can probably trigger the check on
>> the correctly placed page. For this case, we can just insert hpte and
>> do fast exception return.
>
> I still don't understand why we need to handle numa faults in hash
> page ? Are you trying to optimize the code path ? If so can you explain
> the benefits ? Some numbers showing it is helping ?
>
When return from hash_page(), we will take fast_exc_return_irq, while
from do_page_fault(), we take ret_from_except.
As the "fast" implies that there are more complicated logic to sync
the interrupt states in ret_from_except, which cost much.
Do you think so?
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/mm/hash_utils_64.c | 34 +++++++++++++++++++++++++++++++++-
>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
>> index 9bf1195..735678c 100644
>> --- a/arch/powerpc/mm/hash_utils_64.c
>> +++ b/arch/powerpc/mm/hash_utils_64.c
>> @@ -965,6 +965,10 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
>> const struct cpumask *tmp;
>> int rc, user_region = 0, local = 0;
>> int psize, ssize;
>> + pte_t old, new;
>> + struct vm_area_struct *vma;
>> + int page_nid, target_nid;
>> + struct page *test_page;
>>
>> DBG_LOW("hash_page(ea=%016lx, access=%lx, trap=%lx\n",
>> ea, access, trap);
>> @@ -1033,12 +1037,40 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
>>
>> /* Get PTE and page size from page tables */
>> ptep = find_linux_pte_or_hugepte(pgdir, ea, &hugeshift);
>> - if (ptep == NULL || !pte_present(*ptep) || pte_numa(*ptep)) {
>> + if (ptep == NULL || !pte_present(*ptep)) {
>> DBG_LOW(" no PTE !\n");
>> rc = 1;
>> goto bail;
>> }
>>
>> + old = pte_val(*ptep);
>> + if (pte_numa(old)) {
>> + /* If fail to lock, let do_page_fault() to handle it */
>> + if (down_read_trylock(&mm->mmap_sem)) {
>
> hmm is that something we want to do in hash_page ?
>
Yes, the function has no relation with hash. But I think it depends on
whether it is worth to optimize or not.
Thanks and regards,
Pingfan
>> + vma = find_vma(mm, ea);
>> + up_read(&mm->mmap_sem);
>> + test_page = pte_page(old);
>> + page_nid = page_to_nid(test_page);
>> + target_nid = numa_migrate_prep(test_page, vma, ea,
>> + page_nid);
>> + if (target_nid < 0) {
>> + new = pte_mknonnuma(old);
>> + /* If ptep is modified under us,
>> + * just retry the access
>> + */
>> + if (unlikely(cmpxchg(ptep, old, new) != old)) {
>> + put_page(test_page);
>> + return 0;
>> + }
>> + put_page(test_page);
>> + }
>> + } else {
>> + put_page(test_page);
>> + rc = 1;
>> + goto bail;
>> + }
>> + }
>> +
>> /* Add _PAGE_PRESENT to the required access perm */
>> access |= _PAGE_PRESENT;
>>
>
> -aneesh
>
^ permalink raw reply
* [PATCH 6/9] powerpc/pci: Use dev_is_pci() to check whether it is pci device
From: Yijing Wang @ 2013-12-05 12:01 UTC (permalink / raw)
To: Bjorn Helgaas, Benjamin Herrenschmidt, Paul Mackerras
Cc: linux-pci, linux-kernel, Yijing Wang, Hanjun Guo, Scott Wood,
linuxppc-dev
Use PCI standard marco dev_is_pci() instead of directly compare
pci_bus_type to check whether it is pci device.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/powerpc/sysdev/fsl_pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4dfd61d..7066e52 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -122,7 +122,7 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
* address width of the SoC such that we can address any internal
* SoC address from across PCI if needed
*/
- if ((dev->bus == &pci_bus_type) &&
+ if ((dev_is_pci(dev)) &&
dma_mask >= DMA_BIT_MASK(MAX_PHYS_ADDR_BITS)) {
set_dma_ops(dev, &dma_direct_ops);
set_dma_offset(dev, pci64_dma_offset);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 3/3] powerpc: mm: optimize for the correctly placed page
From: Aneesh Kumar K.V @ 2013-12-05 10:58 UTC (permalink / raw)
To: Liu Ping Fan, linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <1386140348-7854-4-git-send-email-pingfank@linux.vnet.ibm.com>
Liu Ping Fan <kernelfans@gmail.com> writes:
> The period check of _PAGE_NUMA can probably trigger the check on
> the correctly placed page. For this case, we can just insert hpte and
> do fast exception return.
I still don't understand why we need to handle numa faults in hash
page ? Are you trying to optimize the code path ? If so can you explain
the benefits ? Some numbers showing it is helping ?
>
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/hash_utils_64.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 9bf1195..735678c 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -965,6 +965,10 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> const struct cpumask *tmp;
> int rc, user_region = 0, local = 0;
> int psize, ssize;
> + pte_t old, new;
> + struct vm_area_struct *vma;
> + int page_nid, target_nid;
> + struct page *test_page;
>
> DBG_LOW("hash_page(ea=%016lx, access=%lx, trap=%lx\n",
> ea, access, trap);
> @@ -1033,12 +1037,40 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
>
> /* Get PTE and page size from page tables */
> ptep = find_linux_pte_or_hugepte(pgdir, ea, &hugeshift);
> - if (ptep == NULL || !pte_present(*ptep) || pte_numa(*ptep)) {
> + if (ptep == NULL || !pte_present(*ptep)) {
> DBG_LOW(" no PTE !\n");
> rc = 1;
> goto bail;
> }
>
> + old = pte_val(*ptep);
> + if (pte_numa(old)) {
> + /* If fail to lock, let do_page_fault() to handle it */
> + if (down_read_trylock(&mm->mmap_sem)) {
hmm is that something we want to do in hash_page ?
> + vma = find_vma(mm, ea);
> + up_read(&mm->mmap_sem);
> + test_page = pte_page(old);
> + page_nid = page_to_nid(test_page);
> + target_nid = numa_migrate_prep(test_page, vma, ea,
> + page_nid);
> + if (target_nid < 0) {
> + new = pte_mknonnuma(old);
> + /* If ptep is modified under us,
> + * just retry the access
> + */
> + if (unlikely(cmpxchg(ptep, old, new) != old)) {
> + put_page(test_page);
> + return 0;
> + }
> + put_page(test_page);
> + }
> + } else {
> + put_page(test_page);
> + rc = 1;
> + goto bail;
> + }
> + }
> +
> /* Add _PAGE_PRESENT to the required access perm */
> access |= _PAGE_PRESENT;
>
-aneesh
^ permalink raw reply
* RE: Error in frreing hugepages with preemption enabled
From: Bharat Bhushan @ 2013-12-05 11:14 UTC (permalink / raw)
To: Andrea Arcangeli, Alexander Graf
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <20131203222121.GB18764@redhat.com>
> -----Original Message-----
> From: Andrea Arcangeli [mailto:aarcange@redhat.com]
> Sent: Wednesday, December 04, 2013 3:51 AM
> To: Alexander Graf
> Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; kvm-
> ppc@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Ben Herrensc=
hmidt
> Subject: Re: Error in frreing hugepages with preemption enabled
>=20
> Hi everyone,
>=20
> On Fri, Nov 29, 2013 at 12:13:03PM +0100, Alexander Graf wrote:
> >
> > On 29.11.2013, at 05:38, Bharat Bhushan <Bharat.Bhushan@freescale.com> =
wrote:
> >
> > > Hi Alex,
> > >
> > > I am running KVM guest with host kernel having CONFIG_PREEMPT enabled=
. With
> allocated pages things seems to work fine but I uses hugepages for guest =
I see
> below prints when "quit" from qemu.
> > >
> > > (qemu) QEMU waiting for connection on: telnet:0.0.0.0:4444,server
> > > qemu-system-ppc64: pci_add_option_rom: failed to find romfile "efi-
> virtio.rom"
> > > q
> > > debug_smp_processor_id: 15 callbacks suppressed
> > > BUG: using smp_processor_id() in preemptible [00000000] code:
> > > qemu-system-ppc/2504 caller is .free_hugepd_range+0xb0/0x21c
> > > CPU: 1 PID: 2504 Comm: qemu-system-ppc Not tainted
> > > 3.12.0-rc3-07733-gabf4907 #175 Call Trace:
> > > [c0000000fb433400] [c000000000007d38] .show_stack+0x7c/0x1cc
> > > (unreliable) [c0000000fb4334d0] [c0000000005e8ce0]
> > > .dump_stack+0x9c/0xf4 [c0000000fb433560] [c0000000002de5ec]
> > > .debug_smp_processor_id+0x108/0x11c
> > > [c0000000fb4335f0] [c000000000025e10] .free_hugepd_range+0xb0/0x21c
> > > [c0000000fb433680] [c0000000000265bc]
> > > .hugetlb_free_pgd_range+0x2c8/0x3b0
> > > [c0000000fb4337a0] [c0000000000e428c] .free_pgtables+0x14c/0x158
> > > [c0000000fb433840] [c0000000000ef320] .exit_mmap+0xec/0x194
> > > [c0000000fb433960] [c00000000004d780] .mmput+0x64/0x124
> > > [c0000000fb4339e0] [c000000000051f40] .do_exit+0x29c/0x9c8
> > > [c0000000fb433ae0] [c0000000000527c8] .do_group_exit+0x50/0xc4
> > > [c0000000fb433b70] [c0000000000606a0]
> > > .get_signal_to_deliver+0x21c/0x5d8
> > > [c0000000fb433c70] [c000000000009b08] .do_signal+0x54/0x278
> > > [c0000000fb433db0] [c000000000009e50] .do_notify_resume+0x64/0x78
> > > [c0000000fb433e30] [c000000000000b44]
> > > .ret_from_except_lite+0x70/0x74
> > >
> > >
> > > This mean that free_hugepd_range() must be called with preemption ena=
bled.
> >
> > with preemption disabled.
> >
> > > I tried below change and this seems to work fine (I am not having
> > > expertise in this area so not sure this is correct way)
> >
> > Not sure - the scope looks odd to me. Let's ask Andrea - I'm sure he kn=
ows
> what to do :).
>=20
> :) So I had a look at the top of this function (0xb0) in the upstream ker=
nel and
> no smp_processor_id() call is apparent, is this stock git or a ppc tree? =
The
> first few calls seem not to call it but I may have overlooked something. =
It's
> just quicker if somebody with vmlinux finds the location of it.
>=20
> static void free_hugepd_range(struct mmu_gather *tlb, hugepd_t *hpdp, int
> pdshift,
> unsigned long start, unsigned long end,
> unsigned long floor, unsigned long ceiling) {
> pte_t *hugepte =3D hugepd_page(*hpdp);
> int i;
>=20
> unsigned long pdmask =3D ~((1UL << pdshift) - 1);
> unsigned int num_hugepd =3D 1;
>=20
> #ifdef CONFIG_PPC_FSL_BOOK3E
> /* Note: On fsl the hpdp may be the first of several */
> num_hugepd =3D (1 << (hugepd_shift(*hpdp) - pdshift)); #else
> unsigned int shift =3D hugepd_shift(*hpdp); #endif
>=20
> start &=3D pdmask;
> if (start < floor)
> return;
> if (ceiling) {
> ceiling &=3D pdmask;
> if (! ceiling)
> return;
> }
> if (end - 1 > ceiling - 1)
> return;
>=20
> for (i =3D 0; i < num_hugepd; i++, hpdp++)
> hpdp->pd =3D 0;
>=20
> tlb->need_flush =3D 1;
>=20
> #ifdef CONFIG_PPC_FSL_BOOK3E
> hugepd_free(tlb, hugepte);
> #else
> pgtable_free_tlb(tlb, hugepte, pdshift - shift); #endif }
>=20
> Generally smp_processor_id should never be used, exactly to avoid problem=
s like
> above with preempion enabled in .config.
>=20
> Instead it should be replaced with a get_cpu()/put_cpu() pair that is exa=
ctly
> meant to fix bugs like this and define proper critical sections around th=
e per-
> cpu variables.
>=20
> #define get_cpu() ({ preempt_disable(); smp_processor_id(); })
> #define put_cpu() preempt_enable()
>=20
> After you find where that smp_processor_id() is located, you should simpl=
y
> replace it with a get_cpu() and then you should insert a put_cpu immediat=
ely
> after the "cpu" info is not used anymore. That will define a proper and s=
trict
> critical section around the use of the per-cpu variables.
>=20
> With a ppc vmlinux it should be immediate to find the location of
> smp_processor_id but I don't have the ppc vmlinux here.
Thanks Andrea for the details description. It is really helpful
I will look into this.
Thanks
-Bharat
>=20
> Thanks!
> Andrea
>=20
> >
> >
> > Alex
> >
> > >
> > > diff --git a/arch/powerpc/mm/hugetlbpage.c
> > > b/arch/powerpc/mm/hugetlbpage.c index d67db4b..6bf8459 100644
> > > --- a/arch/powerpc/mm/hugetlbpage.c
> > > +++ b/arch/powerpc/mm/hugetlbpage.c
> > > @@ -563,8 +563,10 @@ static void hugetlb_free_pmd_range(struct mmu_ga=
ther
> *tlb, pud_t *pud,
> > > */
> > > next =3D addr + (1 << hugepd_shift(*(hugepd_t *)pmd));
> > > #endif
> > > + preempt_disable();
> > > free_hugepd_range(tlb, (hugepd_t *)pmd, PMD_SHIFT,
> > > addr, next, floor, ceiling);
> > > + preempt_enable();
> > > } while (addr =3D next, addr !=3D end);
> > >
> > > start &=3D PUD_MASK;
> > >
> > >
> > > Thanks
> > > -Bharat
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe kvm-ppc"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: mm: make _PAGE_NUMA take effect
From: Aneesh Kumar K.V @ 2013-12-05 10:53 UTC (permalink / raw)
To: Liu Ping Fan, linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <1386140348-7854-2-git-send-email-pingfank@linux.vnet.ibm.com>
Liu Ping Fan <kernelfans@gmail.com> writes:
> To enable the do_numa_page(), we should not fix _PAGE_NUMA in
> hash_page(), so bail out for the case of pte_numa().
>
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/hash_utils_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index fb176e9..9bf1195 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1033,7 +1033,7 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
>
> /* Get PTE and page size from page tables */
> ptep = find_linux_pte_or_hugepte(pgdir, ea, &hugeshift);
> - if (ptep == NULL || !pte_present(*ptep)) {
> + if (ptep == NULL || !pte_present(*ptep) || pte_numa(*ptep)) {
> DBG_LOW(" no PTE !\n");
> rc = 1;
> goto bail;
why ? , All the hash routines do check for _PAGE_PRESENT via access
variable.
-aneesh
^ permalink raw reply
* Re: [PATCH] powerpc: fix xmon disassembler for little-endian
From: Philippe Bergheaud @ 2013-12-05 8:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Tom Musta, linuxppc-dev
In-Reply-To: <1386218366.21910.16.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2013-12-04 at 14:45 +0100, Philippe Bergheaud wrote:
>
>
>>>>+#ifdef __LITTLE_ENDIAN__
>>>>+#define GETWORD(v) (((v)[3] << 24) + ((v)[2] << 16) + ((v)[1] << 8) + (v)[0])
>>>>+#else
>>>>#define GETWORD(v) (((v)[0] << 24) + ((v)[1] << 16) + ((v)[2] << 8) + (v)[3])
>>>>+#endif
>>>>
>>>>#define isxdigit(c) (('0' <= (c) && (c) <= '9') \
>>>> || ('a' <= (c) && (c) <= 'f') \
>>>>
>>>
>>>
>>>Philippe: Wouldn't it be better to just do a 32-bit load and let the endianness be worked out
>>>by the hardware? i.e.
>>>
>>>#define GETWORD(v) (*(u32 *)v)
>>
>>Yes, your alternative is better.
>>Wouldn't it narrow the scope of the macro to aligned words on POWER7?
>>I think that all references to GETWORD operate on aligned words anyway.
>
>
> Well, xmon has to be robust ... as long as you are *certain* that even
> with crap entry state it won't try to access unaligned boundaries then
> go for it but we aren't looking at performance here.
Thank you Tom and Ben. We are definitely not looking at performance here.
I prefer to stay on the safe side, and leave the original patch untouched.
Philippe
^ permalink raw reply
* [PATCH] powerpc/p1010rdb-pa: modify phy interrupt.
From: Zhao Qiang @ 2013-12-05 6:00 UTC (permalink / raw)
To: bcousson, tony, devicetree; +Cc: Zhao Qiang, linuxppc-dev
It is not correct according to p1010rdb-pa user guide.
So modify it.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
arch/powerpc/boot/dts/p1010rdb-pa.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa.dtsi b/arch/powerpc/boot/dts/p1010rdb-pa.dtsi
index 3d275e0..0cf6c34 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pa.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb-pa.dtsi
@@ -39,7 +39,7 @@
};
&phy0 {
- interrupts = <3 1 0 0>;
+ interrupts = <1 1 0 0>;
};
&phy1 {
@@ -47,5 +47,5 @@
};
&phy2 {
- interrupts = <2 1 0 0>;
+ interrupts = <4 1 0 0>;
};
--
1.8.4
^ permalink raw reply related
* Re: [PATCH -V2 3/5] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Benjamin Herrenschmidt @ 2013-12-05 5:20 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linux-mm, Rik van Riel, linuxppc-dev, paulus, Mel Gorman
In-Reply-To: <87a9gfri3u.fsf@linux.vnet.ibm.com>
On Thu, 2013-12-05 at 10:48 +0530, Aneesh Kumar K.V wrote:
>
> Ok, I can move the changes below #ifdef CONFIG_NUMA_BALANCING ? We call
> change_prot_numa from task_numa_work and queue_pages_range(). The later
> may be an issue. So doing the below will help ?
>
> -#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE
> +#ifdef CONFIG_NUMA_BALANCING
I will defer to Mel and Rik (should we also CC Andrea ?)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH -V2 3/5] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Aneesh Kumar K.V @ 2013-12-05 5:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Mel Gorman, Rik van Riel
Cc: linux-mm, paulus, linuxppc-dev
In-Reply-To: <1386126782.16703.137.camel@pasglop>
Adding Mel and Rik to cc:
Benjamin Herrenschmidt <benh@au1.ibm.com> writes:
> On Mon, 2013-11-18 at 14:58 +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> change_prot_numa should work even if _PAGE_NUMA != _PAGE_PROTNONE.
>> On archs like ppc64 that don't use _PAGE_PROTNONE and also have
>> a separate page table outside linux pagetable, we just need to
>> make sure that when calling change_prot_numa we flush the
>> hardware page table entry so that next page access result in a numa
>> fault.
>
> That patch doesn't look right...
>
> You are essentially making change_prot_numa() do whatever it does (which
> I don't completely understand) *for all architectures* now, whether they
> have CONFIG_ARCH_USES_NUMA_PROT_NONE or not ... So because you want that
> behaviour on powerpc book3s64, you change everybody.
>
> Is that correct ?
Yes.
>
> Also what exactly is that doing, can you explain ? From what I can see,
> it calls back into the core of mprotect to change the protection to
> vma->vm_page_prot, which I would have expected is already the protection
> there, with the added "prot_numa" flag passed down.
it set the _PAGE_NUMA bit. Now we also want to make sure that when
we set _PAGE_NUMA, we would get a pagefault on that so that we can track
that fault as a numa fault. To ensure that, we had the below BUILD_BUG
BUILD_BUG_ON(_PAGE_NUMA != _PAGE_PROTNONE);
But other than that the function doesn't really have any dependency on
_PAGE_PROTNONE. The only requirement is when we set _PAGE_NUMA, the
architecture should do enough to ensure that we get a page fault. Now on
ppc64 we does that by clearlying hpte entry and also clearing
_PAGE_PRESENT. Since we have _PAGE_PRESENT cleared hash_page will return
1 and we get to page fault handler.
>
> Your changeset comment says "On archs like ppc64 [...] we just need to
> make sure that when calling change_prot_numa we flush the
> hardware page table entry so that next page access result in a numa
> fault."
>
> But change_prot_numa() does a lot more than that ... it does
> pte_mknuma(), do we need it ? I assume we do or we wouldn't have added
> that PTE bit to begin with...
>
> Now it *might* be allright and it might be that no other architecture
> cares anyway etc... but I need at least some mm folks to ack on that
> patch before I can take it because it *will* change behaviour of other
> architectures.
>
Ok, I can move the changes below #ifdef CONFIG_NUMA_BALANCING ? We call
change_prot_numa from task_numa_work and queue_pages_range(). The later
may be an issue. So doing the below will help ?
-#ifdef CONFIG_ARCH_USES_NUMA_PROT_NONE
+#ifdef CONFIG_NUMA_BALANCING
-aneesh
^ permalink raw reply
* Re: [PATCH 3/8] IBM Akebono: Add support for a new PHY interface to the IBM emac driver
From: Benjamin Herrenschmidt @ 2013-12-05 4:49 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1385086116-10972-3-git-send-email-alistair@popple.id.au>
On Fri, 2013-11-22 at 13:08 +1100, Alistair Popple wrote:
> The IBM PPC476GTR SoC that is used on the Akebono board uses a
> different ethernet PHY interface that has wake on lan (WOL) support
> with the IBM emac. This patch adds support to the IBM emac driver for
> this new PHY interface.
>
> At this stage the wake on lan functionality has not been implemented.
>
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH V4 00/10] perf: New conditional branch filter
From: Michael Ellerman @ 2013-12-05 4:47 UTC (permalink / raw)
To: acme
Cc: mikey, ak, linux-kernel, eranian, linuxppc-dev, sukadev, mingo,
Anshuman Khandual
In-Reply-To: <1386153162-11225-1-git-send-email-khandual@linux.vnet.ibm.com>
On Wed, 2013-12-04 at 16:02 +0530, Anshuman Khandual wrote:
> This patchset is the re-spin of the original branch stack sampling
> patchset which introduced new PERF_SAMPLE_BRANCH_COND branch filter. This patchset
> also enables SW based branch filtering support for book3s powerpc platforms which
> have PMU HW backed branch stack sampling support.
>
> Summary of code changes in this patchset:
>
> (1) Introduces a new PERF_SAMPLE_BRANCH_COND branch filter
> (2) Add the "cond" branch filter options in the "perf record" tool
> (3) Enable PERF_SAMPLE_BRANCH_COND in X86 platforms
> (4) Enable PERF_SAMPLE_BRANCH_COND in POWER8 platform
> (5) Update the documentation regarding "perf record" tool
Hi Arnaldo,
Can you please take just patches 1-5 into the perf tree? And do you mind
putting them in a topic branch so Benh can merge that.
The remaining patches are powerpc specific and still need some more review.
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox