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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E870C433DB for ; Tue, 16 Mar 2021 14:24:51 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 6D5C965077 for ; Tue, 16 Mar 2021 14:24:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D5C965077 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D8F2F4B380; Tue, 16 Mar 2021 10:24:49 -0400 (EDT) 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=@google.com 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 OK5z2hw1YUi1; Tue, 16 Mar 2021 10:24:48 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D55D24B3C1; Tue, 16 Mar 2021 10:24:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D24EB4B3C1 for ; Tue, 16 Mar 2021 10:24:46 -0400 (EDT) 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 A2IPosUP0KqB for ; Tue, 16 Mar 2021 10:24:45 -0400 (EDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id D26404B380 for ; Tue, 16 Mar 2021 10:24:45 -0400 (EDT) Received: by mail-wr1-f46.google.com with SMTP id u16so10576600wrt.1 for ; Tue, 16 Mar 2021 07:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=U1myjpduufIFHbOjx3MC14gmPXuJUxpXkD0h1tMVdZk=; b=orKtTHYuQ/AxMaqkOv5uEGAjqkfhFo6g71B5d/6YVdr5R83v71IWcJwyPLMm9hGeez vPAl9OQU798cfL3MGn+dQEq1TCDdtuF+jKCWZQZF69gyNntgvJm564dsGpGFzL0voXxM OZBuwXc66wy3w1US4kMx3uOfkQImgIf2NxFAP0MUgPZPlpN8LS51Siw4CuHU1L9VbdBn uFlARkm1AzA0m/KPYnKnU33GxnqUqD5qUY07eSXRySqXptvV7Zb7NKSuw1MD0mC807nw j80tjsCLAZikF/SHzJ9QOq3r5jZxRXAB79Zvd2zleCjlece3JSaX9MHqTp8TaUGmWPBU da8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=U1myjpduufIFHbOjx3MC14gmPXuJUxpXkD0h1tMVdZk=; b=IbBZA2WcCvUKciOvZYxnphcxVF5luZoY7fjUM0Dts7Fhbj6R0P3vK6rJvb2NrKxj37 OsnVG2p4aU6xAt6Xhn318F9DFMB8A24wNWM9U3evUAgQvuGyWvHhlBufpFcnQQyHha7E KNDGHO2Wj5IQ/kDk39KS/m1HcI/MHkXY3swYrGtp6Mof4EQ07YRjxa11Zv4O1qz65j3Y Lob2QSnSr4VLjBREhO8dZlLq6+eK+KiyVnullEgfvtMjasGBQTHDXqblFVQ9mVGaLHOO D2+eYGbpTu4sxrr23vnITSdXPGQuUBO/RY4EdXA/Ozx/LISdTJBxjdNwM/BMQGYmiXgD +Ivw== X-Gm-Message-State: AOAM531cHUYQAWqBiu3MVY1FDmIfHKl3Qt8SCvWq5bh7+HcQNqwhHltz ZUfybTfH7bioj5UHq1o2rdadng== X-Google-Smtp-Source: ABdhPJyyMor4Qq/YcVIHZI9X70Br34uiGRVd4G+U5M+lj7mhFa3mulxofA2zCrgyj6FCxFn+sZd73A== X-Received: by 2002:a05:6000:1281:: with SMTP id f1mr5274571wrx.243.1615904684787; Tue, 16 Mar 2021 07:24:44 -0700 (PDT) Received: from google.com (216.131.76.34.bc.googleusercontent.com. [34.76.131.216]) by smtp.gmail.com with ESMTPSA id v9sm22615975wrn.86.2021.03.16.07.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 07:24:43 -0700 (PDT) Date: Tue, 16 Mar 2021 14:24:38 +0000 From: Andrew Scull To: Marc Zyngier Subject: Re: [PATCH 08/10] KVM: arm64: Add a nVHE-specific SVE VQ reset hypercall Message-ID: References: <20210316101312.102925-1-maz@kernel.org> <20210316101312.102925-9-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210316101312.102925-9-maz@kernel.org> Cc: kernel-team@android.com, kvm@vger.kernel.org, Catalin Marinas , kvmarm@lists.cs.columbia.edu, broonie@kernel.org, Will Deacon , dave.martin@arm.com, linux-arm-kernel@lists.infradead.org, daniel.kiss@arm.com 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 Tue, Mar 16, 2021 at 10:13:10AM +0000, Marc Zyngier wrote: > ZCR_EL2 controls the upper bound for ZCR_EL1, and is set to > a potentially lower limit when the guest uses SVE. > > In order to restore the SVE state on the EL1 host, we must first > reset ZCR_EL2 to its original value. > > Provide a hypervall that perform this reset. Is there a good reason to have an explicit hypercall vs trapping the host access to SVE and restoring in that event? It's quite easy to do trap handling at EL2 now and it could let things be even lazier, if that's any benefit in this case. Trapping seems to have had a bad rep in other conversations but I'm not sure the same reasoning applies to this as well, or not. _______________________________________________ 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 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3748AC4332B for ; Tue, 16 Mar 2021 14:25:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E50A465087 for ; Tue, 16 Mar 2021 14:25:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236222AbhCPOZU (ORCPT ); Tue, 16 Mar 2021 10:25:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236192AbhCPOYr (ORCPT ); Tue, 16 Mar 2021 10:24:47 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BEB9C06174A for ; Tue, 16 Mar 2021 07:24:46 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id v11so7537256wro.7 for ; Tue, 16 Mar 2021 07:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=U1myjpduufIFHbOjx3MC14gmPXuJUxpXkD0h1tMVdZk=; b=orKtTHYuQ/AxMaqkOv5uEGAjqkfhFo6g71B5d/6YVdr5R83v71IWcJwyPLMm9hGeez vPAl9OQU798cfL3MGn+dQEq1TCDdtuF+jKCWZQZF69gyNntgvJm564dsGpGFzL0voXxM OZBuwXc66wy3w1US4kMx3uOfkQImgIf2NxFAP0MUgPZPlpN8LS51Siw4CuHU1L9VbdBn uFlARkm1AzA0m/KPYnKnU33GxnqUqD5qUY07eSXRySqXptvV7Zb7NKSuw1MD0mC807nw j80tjsCLAZikF/SHzJ9QOq3r5jZxRXAB79Zvd2zleCjlece3JSaX9MHqTp8TaUGmWPBU da8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=U1myjpduufIFHbOjx3MC14gmPXuJUxpXkD0h1tMVdZk=; b=qpTRQkZrVctZ6jkYEdv4WAK/yDaTAcIMnDDVl5Q7hUgEFxA28QNhtoGzfruixO2wx5 DEZRBwPfizvU76/GR1L+cdFq70Zdi9O7O1eIkuqdagcP5GD2vhL+8l6rLc9aBcDXhnrL cB4+QtPnHfYEMyxL44kAGHiouZVgd/2PxyL0ocuU/97POGpTxbLxat/ROjWwmYMgLn8i +m39IuD5VDtK9P2BCl7ZSVT9EV+c50haPfNcAO/pem6zbKYfbkSan8csROicaebmEWp0 DPu2+uC57820YBYxq/dIarIPNgU8Kgp5ryUyw3RFZDKs7b9CKHUyRPJ9iiLaAF6xWRZ3 szBA== X-Gm-Message-State: AOAM531l/Nbxuud2q8wJ41flram0iHIaw6QJdBR+I656ZVbpBSqOKoq6 SR/D1hzZLQ7fvXtVoOTbjpBoqQ== X-Google-Smtp-Source: ABdhPJyyMor4Qq/YcVIHZI9X70Br34uiGRVd4G+U5M+lj7mhFa3mulxofA2zCrgyj6FCxFn+sZd73A== X-Received: by 2002:a05:6000:1281:: with SMTP id f1mr5274571wrx.243.1615904684787; Tue, 16 Mar 2021 07:24:44 -0700 (PDT) Received: from google.com (216.131.76.34.bc.googleusercontent.com. [34.76.131.216]) by smtp.gmail.com with ESMTPSA id v9sm22615975wrn.86.2021.03.16.07.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 07:24:43 -0700 (PDT) Date: Tue, 16 Mar 2021 14:24:38 +0000 From: Andrew Scull To: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, dave.martin@arm.com, daniel.kiss@arm.com, Will Deacon , Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , broonie@kernel.org, kernel-team@android.com Subject: Re: [PATCH 08/10] KVM: arm64: Add a nVHE-specific SVE VQ reset hypercall Message-ID: References: <20210316101312.102925-1-maz@kernel.org> <20210316101312.102925-9-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210316101312.102925-9-maz@kernel.org> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Mar 16, 2021 at 10:13:10AM +0000, Marc Zyngier wrote: > ZCR_EL2 controls the upper bound for ZCR_EL1, and is set to > a potentially lower limit when the guest uses SVE. > > In order to restore the SVE state on the EL1 host, we must first > reset ZCR_EL2 to its original value. > > Provide a hypervall that perform this reset. Is there a good reason to have an explicit hypercall vs trapping the host access to SVE and restoring in that event? It's quite easy to do trap handling at EL2 now and it could let things be even lazier, if that's any benefit in this case. Trapping seems to have had a bad rep in other conversations but I'm not sure the same reasoning applies to this as well, or not. 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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 564E5C433E0 for ; Tue, 16 Mar 2021 14:26:42 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CB1CE65026 for ; Tue, 16 Mar 2021 14:26:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB1CE65026 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ndSyJ8yZUuroTDJ4mbNYvtoY/FZ02EvGrQDpCd9ddnQ=; b=TWgvmqLeCWOsB3RApvEHcu5KU 5s9bqg1AvmJVPp1jGfFPqrXb4h6y+KO8sUxZialGsv3q/lHnALSkNXPswFNv2JvgY3U+1h8leUTGk KN9I0pvcvqRnEEGl8NZAXAhew5ERLpyFr3CJ90NDhShcVAqYok4SNhtfXM3bfl0Zmuu3ywcoR7L8s VT6TCfXTypnx0zJcHDwSAKHDUCzMVaB9lIndv7eAyCTM5rk7iQMvzLJCgwssE43dMTuJ84OTnJ5rY LRHfdNrzGcvWJJPEsjNpeBupL3HzYuFTMYMKp+nnsQ1wVyOZsZd4ESdeerSAcb5dA8DIY66u4GZnZ RPmyn7KJg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lMAcu-000wND-N4; Tue, 16 Mar 2021 14:24:52 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMAcp-000wMr-29 for linux-arm-kernel@lists.infradead.org; Tue, 16 Mar 2021 14:24:48 +0000 Received: by mail-wr1-x430.google.com with SMTP id y16so10584325wrw.3 for ; Tue, 16 Mar 2021 07:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=U1myjpduufIFHbOjx3MC14gmPXuJUxpXkD0h1tMVdZk=; b=orKtTHYuQ/AxMaqkOv5uEGAjqkfhFo6g71B5d/6YVdr5R83v71IWcJwyPLMm9hGeez vPAl9OQU798cfL3MGn+dQEq1TCDdtuF+jKCWZQZF69gyNntgvJm564dsGpGFzL0voXxM OZBuwXc66wy3w1US4kMx3uOfkQImgIf2NxFAP0MUgPZPlpN8LS51Siw4CuHU1L9VbdBn uFlARkm1AzA0m/KPYnKnU33GxnqUqD5qUY07eSXRySqXptvV7Zb7NKSuw1MD0mC807nw j80tjsCLAZikF/SHzJ9QOq3r5jZxRXAB79Zvd2zleCjlece3JSaX9MHqTp8TaUGmWPBU da8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=U1myjpduufIFHbOjx3MC14gmPXuJUxpXkD0h1tMVdZk=; b=NDYoGYvjLLjs6xek+Josuo3zwqNh8jWrNZh9wkHIaax/jz83X7Z9p9hyEfd+FcEYuK XideJ1EiinTKrmQSoQAN6qoeQ4DndiIsTHSSHNQyKWrn5gae5J9v3e2LV+gLkcN+DyCG QW+/IBxWcX63efi2IIEl0kgkcQA4duuorN7l3P2cljVBLABdQmLhXUOkNSM58sdlvXrR RxMcgoUUt98Vhf299RkuOqUooizWccmSBvHcRXmvYeRWFVtvRlMBZdMHKDBG0VHpSU7t Pri3c2aiun+GS0NDdoWzS9tkhEKx6MIXA4yZeN2XYvSJKgWB33xinWoEm9cYTu2NSb3s qNmA== X-Gm-Message-State: AOAM530WaKWbITUsH/BVdfsCCUa+oeu+lrwB9YFunW8rKBs1w0biQcLi oyhxIVPoiI9zSGGirtscyMoYOC2nq9jcDXDm X-Google-Smtp-Source: ABdhPJyyMor4Qq/YcVIHZI9X70Br34uiGRVd4G+U5M+lj7mhFa3mulxofA2zCrgyj6FCxFn+sZd73A== X-Received: by 2002:a05:6000:1281:: with SMTP id f1mr5274571wrx.243.1615904684787; Tue, 16 Mar 2021 07:24:44 -0700 (PDT) Received: from google.com (216.131.76.34.bc.googleusercontent.com. [34.76.131.216]) by smtp.gmail.com with ESMTPSA id v9sm22615975wrn.86.2021.03.16.07.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 07:24:43 -0700 (PDT) Date: Tue, 16 Mar 2021 14:24:38 +0000 From: Andrew Scull To: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, dave.martin@arm.com, daniel.kiss@arm.com, Will Deacon , Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , broonie@kernel.org, kernel-team@android.com Subject: Re: [PATCH 08/10] KVM: arm64: Add a nVHE-specific SVE VQ reset hypercall Message-ID: References: <20210316101312.102925-1-maz@kernel.org> <20210316101312.102925-9-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210316101312.102925-9-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210316_142447_225537_A38E57C4 X-CRM114-Status: GOOD ( 14.26 ) 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 Tue, Mar 16, 2021 at 10:13:10AM +0000, Marc Zyngier wrote: > ZCR_EL2 controls the upper bound for ZCR_EL1, and is set to > a potentially lower limit when the guest uses SVE. > > In order to restore the SVE state on the EL1 host, we must first > reset ZCR_EL2 to its original value. > > Provide a hypervall that perform this reset. Is there a good reason to have an explicit hypercall vs trapping the host access to SVE and restoring in that event? It's quite easy to do trap handling at EL2 now and it could let things be even lazier, if that's any benefit in this case. Trapping seems to have had a bad rep in other conversations but I'm not sure the same reasoning applies to this as well, or not. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel