From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA1E2C4332F for ; Thu, 15 Dec 2022 09:35:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7A6E84B99E; Thu, 15 Dec 2022 04:35:53 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXFphIv2jBK2; Thu, 15 Dec 2022 04:35:52 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 22C7A4B8EC; Thu, 15 Dec 2022 04:35:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BAD284B8D5 for ; Thu, 15 Dec 2022 04:35:51 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvnRciQ8Qrf8 for ; Thu, 15 Dec 2022 04:35:50 -0500 (EST) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 512AF4B8D1 for ; Thu, 15 Dec 2022 04:35:50 -0500 (EST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 940F6B8169B; Thu, 15 Dec 2022 09:35:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37E7CC433EF; Thu, 15 Dec 2022 09:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671096947; bh=rLFesypilBrGnzbTCpHcHD3EFyvffkyej22PhZqXN2g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iEt1o047x3244dDOObFe5Q9vnB/j2CjEWFFT9jp1G2G7MGAqLlQnbHBVfsVwRrlqI Mof2r+180bPGwjZwvaGQlKcTcwoSbLNaO6rC69UjNCzD7QnrDqhXOi7miqnanfxX98 reTiiT/9aqjPBGLGysryw4rdzH3zBxZUyOXiYN2A/zxf0BwdxVrzUffemLdu2wrxe3 3k7u+yDUv7SjspMaST26q/MgRRmW5IYEyuLYrOvktgFIVTiGIUGlmxsizriR/PDj1e fIODM7uky1QuQfgnG85BfQZNXf25pPO09H0mQNf0DKVfjXhZiV8BqK2X6DKpophDls 9wNh2l2MeYBsQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p5keW-00Co8M-OZ; Thu, 15 Dec 2022 09:35:44 +0000 Date: Thu, 15 Dec 2022 09:35:44 +0000 Message-ID: <86zgbpovpr.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Subject: Re: [PATCH v1 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 In-Reply-To: References: <20221206135930.3277585-1-ryan.roberts@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, ardb@kernel.org, suzuki.poulose@arm.com, anshuman.khandual@arm.com, james.morse@arm.com, alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Anshuman Khandual , Catalin Marinas , kvmarm@lists.cs.columbia.edu, kvmarm@lists.linux.dev, Will Deacon , linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 15 Dec 2022 00:52:28 +0000, Oliver Upton wrote: > > On Tue, Dec 06, 2022 at 01:59:18PM +0000, Ryan Roberts wrote: > > (appologies, I'm resending this series as I managed to send the cover letter to > > all but the following patches only to myself on first attempt). > > > > This is my first upstream feature submission so please go easy ;-) > > Welcome :) > > > Support 52-bit Output Addresses: FEAT_LPA2 changes the format of > > the PTEs. The HW advertises support for LPA2 independently for > > stage 1 and stage 2, and therefore its possible to have it for one > > and not the other. I've assumed that there is a valid case for > > this if stage 1 is not supported but stage 2 is, KVM could still > > then use LPA2 at stage 2 to create a 52 bit IPA space (which could > > then be consumed by a 64KB page guest kernel with the help of > > FEAT_LPA). Because of this independence and the fact that the kvm > > pgtable library is used for both stage 1 and stage 2 tables, this > > means the library now has to remember the in-use format on a > > per-page-table basis. To do this, I had to rework some functions > > to take a `struct kvm_pgtable *` parameter, and as a result, there > > is a noisy patch to add this parameter. > > Mismatch between the translation stages is an interesting problem... > > Given that userspace is responsible for setting up the IPA space, I > can't really think of a strong use case for 52 bit IPAs with a 48 bit > VA. Sure, the VMM could construct a sparse IPA space or remap the same > HVA at multiple IPAs to artificially saturate the address space, but > neither seems terribly compelling. > > Nonetheless, AFAICT we already allow this sort of mismatch on LPA && > !LVA systems. A 48 bit userspace could construct a 52 bit IPA space for > its guest. > > Marc, is there any real reason for this or is it just a byproduct of how > LPA support was added to KVM? My recollection is hazy, but LPA came first, and LVA only landed much later (because the two features were made independent in the architecture, something that was later abandoned for LPA2, which implies large VAs as well). So yes, the VMM can place memory wherever it wants in the 52bit IPA space, even if its own VA space is limited to 48 bits. And it doesn't have to be memory, by the way. You could place all the emulated MMIO above the 48bit limit, for example, and that doesn't require any trick other than the HW supporting 52bit PAs, and VTCR_EL2 being correctly configured. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B6D728E7 for ; Thu, 15 Dec 2022 09:35:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37E7CC433EF; Thu, 15 Dec 2022 09:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671096947; bh=rLFesypilBrGnzbTCpHcHD3EFyvffkyej22PhZqXN2g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iEt1o047x3244dDOObFe5Q9vnB/j2CjEWFFT9jp1G2G7MGAqLlQnbHBVfsVwRrlqI Mof2r+180bPGwjZwvaGQlKcTcwoSbLNaO6rC69UjNCzD7QnrDqhXOi7miqnanfxX98 reTiiT/9aqjPBGLGysryw4rdzH3zBxZUyOXiYN2A/zxf0BwdxVrzUffemLdu2wrxe3 3k7u+yDUv7SjspMaST26q/MgRRmW5IYEyuLYrOvktgFIVTiGIUGlmxsizriR/PDj1e fIODM7uky1QuQfgnG85BfQZNXf25pPO09H0mQNf0DKVfjXhZiV8BqK2X6DKpophDls 9wNh2l2MeYBsQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p5keW-00Co8M-OZ; Thu, 15 Dec 2022 09:35:44 +0000 Date: Thu, 15 Dec 2022 09:35:44 +0000 Message-ID: <86zgbpovpr.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Ryan Roberts , Catalin Marinas , Will Deacon , Ard Biesheuvel , Suzuki K Poulose , Anshuman Khandual , James Morse , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v1 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 In-Reply-To: References: <20221206135930.3277585-1-ryan.roberts@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, ardb@kernel.org, suzuki.poulose@arm.com, anshuman.khandual@arm.com, james.morse@arm.com, alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Message-ID: <20221215093544.XKgSXicqMPOFbz-vzH4fY_pofTEdnlqO1QqlT9FfCOE@z> On Thu, 15 Dec 2022 00:52:28 +0000, Oliver Upton wrote: > > On Tue, Dec 06, 2022 at 01:59:18PM +0000, Ryan Roberts wrote: > > (appologies, I'm resending this series as I managed to send the cover letter to > > all but the following patches only to myself on first attempt). > > > > This is my first upstream feature submission so please go easy ;-) > > Welcome :) > > > Support 52-bit Output Addresses: FEAT_LPA2 changes the format of > > the PTEs. The HW advertises support for LPA2 independently for > > stage 1 and stage 2, and therefore its possible to have it for one > > and not the other. I've assumed that there is a valid case for > > this if stage 1 is not supported but stage 2 is, KVM could still > > then use LPA2 at stage 2 to create a 52 bit IPA space (which could > > then be consumed by a 64KB page guest kernel with the help of > > FEAT_LPA). Because of this independence and the fact that the kvm > > pgtable library is used for both stage 1 and stage 2 tables, this > > means the library now has to remember the in-use format on a > > per-page-table basis. To do this, I had to rework some functions > > to take a `struct kvm_pgtable *` parameter, and as a result, there > > is a noisy patch to add this parameter. > > Mismatch between the translation stages is an interesting problem... > > Given that userspace is responsible for setting up the IPA space, I > can't really think of a strong use case for 52 bit IPAs with a 48 bit > VA. Sure, the VMM could construct a sparse IPA space or remap the same > HVA at multiple IPAs to artificially saturate the address space, but > neither seems terribly compelling. > > Nonetheless, AFAICT we already allow this sort of mismatch on LPA && > !LVA systems. A 48 bit userspace could construct a 52 bit IPA space for > its guest. > > Marc, is there any real reason for this or is it just a byproduct of how > LPA support was added to KVM? My recollection is hazy, but LPA came first, and LVA only landed much later (because the two features were made independent in the architecture, something that was later abandoned for LPA2, which implies large VAs as well). So yes, the VMM can place memory wherever it wants in the 52bit IPA space, even if its own VA space is limited to 48 bits. And it doesn't have to be memory, by the way. You could place all the emulated MMIO above the 48bit limit, for example, and that doesn't require any trick other than the HW supporting 52bit PAs, and VTCR_EL2 being correctly configured. Thanks, M. -- Without deviation from the norm, progress is not possible. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3DE77C4332F for ; Thu, 15 Dec 2022 09:36:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pmWC/TFy3Ayv3EpLakInM4Fp88BsCLEAeUFWIl3x+/4=; b=2CRTp6/hljAs8Z uEr6NLGZtVtaSDBr5IM4LnghZpJVC/pVOHkRl17Uja1OYc8ikTnAbipnHDptn5p7GBc/xfTQx8x+y phP6EqiL5LLBrrBA3mTzgB9B3GQ1UjoEaFtnK7Kzeq+y5AQlReNXdaABzTouHO4YwBgoWi8yFZues gj2BRg8vPnmbEruuW3DGh3ko8oyW8sgxrsbVHsjSZnb/S7VTJrsE5DsFfByl7y/GIDNy2QzGJNXeS Jy+JBVVj9DZI2siwzcmoC6dUHqD7CF+3VNIdYk0+IiQa6AMk1PltqEZCv6If3484Ck/XYSD0G4BaP wskZeoYMCJdvCCWUWROQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5keg-008M3Y-6P; Thu, 15 Dec 2022 09:35:54 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5kec-008LzB-CM for linux-arm-kernel@lists.infradead.org; Thu, 15 Dec 2022 09:35:52 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 940F6B8169B; Thu, 15 Dec 2022 09:35:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37E7CC433EF; Thu, 15 Dec 2022 09:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671096947; bh=rLFesypilBrGnzbTCpHcHD3EFyvffkyej22PhZqXN2g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iEt1o047x3244dDOObFe5Q9vnB/j2CjEWFFT9jp1G2G7MGAqLlQnbHBVfsVwRrlqI Mof2r+180bPGwjZwvaGQlKcTcwoSbLNaO6rC69UjNCzD7QnrDqhXOi7miqnanfxX98 reTiiT/9aqjPBGLGysryw4rdzH3zBxZUyOXiYN2A/zxf0BwdxVrzUffemLdu2wrxe3 3k7u+yDUv7SjspMaST26q/MgRRmW5IYEyuLYrOvktgFIVTiGIUGlmxsizriR/PDj1e fIODM7uky1QuQfgnG85BfQZNXf25pPO09H0mQNf0DKVfjXhZiV8BqK2X6DKpophDls 9wNh2l2MeYBsQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p5keW-00Co8M-OZ; Thu, 15 Dec 2022 09:35:44 +0000 Date: Thu, 15 Dec 2022 09:35:44 +0000 Message-ID: <86zgbpovpr.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Ryan Roberts , Catalin Marinas , Will Deacon , Ard Biesheuvel , Suzuki K Poulose , Anshuman Khandual , James Morse , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v1 00/12] KVM: arm64: Support FEAT_LPA2 at hyp s1 and vm s2 In-Reply-To: References: <20221206135930.3277585-1-ryan.roberts@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, ardb@kernel.org, suzuki.poulose@arm.com, anshuman.khandual@arm.com, james.morse@arm.com, alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221215_013550_737033_0E5B792C X-CRM114-Status: GOOD ( 35.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 15 Dec 2022 00:52:28 +0000, Oliver Upton wrote: > > On Tue, Dec 06, 2022 at 01:59:18PM +0000, Ryan Roberts wrote: > > (appologies, I'm resending this series as I managed to send the cover letter to > > all but the following patches only to myself on first attempt). > > > > This is my first upstream feature submission so please go easy ;-) > > Welcome :) > > > Support 52-bit Output Addresses: FEAT_LPA2 changes the format of > > the PTEs. The HW advertises support for LPA2 independently for > > stage 1 and stage 2, and therefore its possible to have it for one > > and not the other. I've assumed that there is a valid case for > > this if stage 1 is not supported but stage 2 is, KVM could still > > then use LPA2 at stage 2 to create a 52 bit IPA space (which could > > then be consumed by a 64KB page guest kernel with the help of > > FEAT_LPA). Because of this independence and the fact that the kvm > > pgtable library is used for both stage 1 and stage 2 tables, this > > means the library now has to remember the in-use format on a > > per-page-table basis. To do this, I had to rework some functions > > to take a `struct kvm_pgtable *` parameter, and as a result, there > > is a noisy patch to add this parameter. > > Mismatch between the translation stages is an interesting problem... > > Given that userspace is responsible for setting up the IPA space, I > can't really think of a strong use case for 52 bit IPAs with a 48 bit > VA. Sure, the VMM could construct a sparse IPA space or remap the same > HVA at multiple IPAs to artificially saturate the address space, but > neither seems terribly compelling. > > Nonetheless, AFAICT we already allow this sort of mismatch on LPA && > !LVA systems. A 48 bit userspace could construct a 52 bit IPA space for > its guest. > > Marc, is there any real reason for this or is it just a byproduct of how > LPA support was added to KVM? My recollection is hazy, but LPA came first, and LVA only landed much later (because the two features were made independent in the architecture, something that was later abandoned for LPA2, which implies large VAs as well). So yes, the VMM can place memory wherever it wants in the 52bit IPA space, even if its own VA space is limited to 48 bits. And it doesn't have to be memory, by the way. You could place all the emulated MMIO above the 48bit limit, for example, and that doesn't require any trick other than the HW supporting 52bit PAs, and VTCR_EL2 being correctly configured. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel