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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6AC6C433EF for ; Mon, 4 Apr 2022 05:46:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242592AbiDDFsk (ORCPT ); Mon, 4 Apr 2022 01:48:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232158AbiDDFsj (ORCPT ); Mon, 4 Apr 2022 01:48:39 -0400 Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09E5832042 for ; Sun, 3 Apr 2022 22:46:44 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id e13so2350026ils.8 for ; Sun, 03 Apr 2022 22:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=PxHyTiTYyZKrMuWxWAtFUKNTUBv0DkB5ESh3olcmowfb91vjP4mIB7ltmXbb2EO4Ie Hn0GeRK0D5M7MuTpjuO0c0ZlZ8iZQ/XmZtXmlP99/R0r96jXGsRC9Rg2Z7tyOjohujoK Exx+VXoicxCd8wiN4wdqkV57XoUl5gQK7+e9WVsQlGV/2nNKh7iP2ODGiWqdf17NlQWw O6YzGl8E4RjpQY1S3mcUEN4b2S/wkpOiqXJVrRFQGo55cLTpbOF4Kvj+c74BP58sbdSr CVSYMWo6Z1criwdhMT2FOZSupAaTY8VHQ4PyFm6dsg4GnoiusW8Ooh80FsqNa2CLMHh9 04qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=6+A0KK/ANb5KhAyQlt3irIjA9EJTRrQ+5DaXieKHUT5Tw3amTwK60sjCrHBeBAZrQk x9AbLQV0fF83HNL6PhsBK4V/zEB5xJ4fBKQ4wfksOgh5VTdQP9CUlUHpihhSPGXLk7g8 ++lAyNSuXha4jssmEdfLzfKfplDVSXoGHts33gCZ7lv9FnZ5t7kxU2acCSjGPTnDN5He sr6bI8IBimlrFA0aTkpvmPyRO8nK1D5kRBvFiuaAEeRvy1NVPKF3jzVAyh4gqW4C6jS2 54EBupUdmdJpbmgZ8aDX3vyN3WMX0QHM9x8iJw/p76T5BtIciQwG9ltYI1Z8jJK2HkkT /ycQ== X-Gm-Message-State: AOAM530LBys2hT/MVEqrxMkbxVHVHQxRKPZdgs3+YVqsgX4+g1LGCDGV 6gQJF5YQbQ92sdStOcLO7Nt+Yw== X-Google-Smtp-Source: ABdhPJwk+57GkB2Zn+ajUSVOFh+5njhU0KQCOdF0/4uXoez1/cNjCep9/bJs6lDeVvXeVItIol/I2g== X-Received: by 2002:a05:6e02:20c4:b0:2c9:a514:6a99 with SMTP id 4-20020a056e0220c400b002c9a5146a99mr5023931ilq.50.1649051203223; Sun, 03 Apr 2022 22:46:43 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id h24-20020a6bfb18000000b006497692016bsm5828288iog.15.2022.04.03.22.46.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Apr 2022 22:46:42 -0700 (PDT) Date: Mon, 4 Apr 2022 05:46:39 +0000 From: Oliver Upton To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Linux ARM , Peter Shier , Ricardo Koller Subject: Re: [PATCH v2 3/3] KVM: arm64: Start trapping ID registers for 32 bit guests Message-ID: References: <20220401010832.3425787-1-oupton@google.com> <20220401010832.3425787-4-oupton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Reiji, On Sun, Apr 03, 2022 at 09:45:15PM -0700, Reiji Watanabe wrote: > On Thu, Mar 31, 2022 at 6:08 PM Oliver Upton wrote: > > > > To date KVM has not trapped ID register accesses from AArch32, meaning > > that guests get an unconstrained view of what hardware supports. This > > can be a serious problem because we try to base the guest's feature > > registers on values that are safe system-wide. Furthermore, KVM does not > > implement the latest ISA in the PMU and Debug architecture, so we > > constrain these fields to supported values. > > > > Since KVM now correctly handles CP15 and CP10 register traps, we no > > longer need to clear HCR_EL2.TID3 for 32 bit guests and will instead > > emulate reads with their safe values. > > > > Signed-off-by: Oliver Upton > > Reviewed-by: Reiji Watanabe > > BTW, due to this, on a system that supports PMUv3, ID_DFR0_E1 value will > become 0 for the aarch32 guest without PMUv3. This is the correct behavior, > but it affects migration. I'm not sure how much we should care about > migration of the aarch32 guest though (and it will be resolved once ID > registers become configurable anyway). I believe userspace has been accessing the sanitised values of these feature registers the entire time, so we should be OK on the UAPI side. >From the guest's perspective, I don't believe there is a meaningful change. Even if the guest were to believe the value it sees in ID_DFR0.PerfMon, it'll crash and burn on the first attempt to poke a PMU register as we synthesize an UNDEF, right? At least now we cover our tracks and ensure the vCPU correctly identifies itself to the guest. This is, of course, unless I missed something painfully obvious :) -- Thanks, Oliver 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 8E10BC433FE for ; Mon, 4 Apr 2022 05:46:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B626A4B0CE; Mon, 4 Apr 2022 01:46:47 -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 XIxMgAfSK957; Mon, 4 Apr 2022 01:46:46 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 82D724B0F1; Mon, 4 Apr 2022 01:46:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2E0CD4B0CE for ; Mon, 4 Apr 2022 01:46:45 -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 GTucZcD4YNf2 for ; Mon, 4 Apr 2022 01:46:44 -0400 (EDT) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 133274A193 for ; Mon, 4 Apr 2022 01:46:43 -0400 (EDT) Received: by mail-il1-f171.google.com with SMTP id k15so1459700ils.0 for ; Sun, 03 Apr 2022 22:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=PxHyTiTYyZKrMuWxWAtFUKNTUBv0DkB5ESh3olcmowfb91vjP4mIB7ltmXbb2EO4Ie Hn0GeRK0D5M7MuTpjuO0c0ZlZ8iZQ/XmZtXmlP99/R0r96jXGsRC9Rg2Z7tyOjohujoK Exx+VXoicxCd8wiN4wdqkV57XoUl5gQK7+e9WVsQlGV/2nNKh7iP2ODGiWqdf17NlQWw O6YzGl8E4RjpQY1S3mcUEN4b2S/wkpOiqXJVrRFQGo55cLTpbOF4Kvj+c74BP58sbdSr CVSYMWo6Z1criwdhMT2FOZSupAaTY8VHQ4PyFm6dsg4GnoiusW8Ooh80FsqNa2CLMHh9 04qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=S4ohqO/O2jtaZSrT+jt8SqTrQzCok6WofDQP61Aezb7Y2HUkJI75FwbRZg3ZWKlKd3 Ebg5Zb7Q/56tpB3obJk6s34u47/NKL0mjqE7stzVwrCQPRRUfH8eNm+crEco6zFFwr7Z tKnPFr2/H4143pZccd9fePD1oCP3Abesh+n1TyipaUuSeVlXwtRv0u+SoCwLnQAeJbmq iDCON16P5FJ9ob/dI4MyYYb7BdvJ+CDWcbrLh5sey+/VYHiF2sWpBzk+2udPPY5l47lJ +e8lqszhwvwVWOufe2MaNfgOuP7RuhnDBH8kHeXsLkHJeR9N+JYp/CsWw5dN/bS23+R+ hCAg== X-Gm-Message-State: AOAM5315Wm5EmBj54ntujZd9m8pwsIfQEys7XmE71FopQ4BdmpRBYwO+ qalPV7ccWPyVx4FKfqn8a5NlMw== X-Google-Smtp-Source: ABdhPJwk+57GkB2Zn+ajUSVOFh+5njhU0KQCOdF0/4uXoez1/cNjCep9/bJs6lDeVvXeVItIol/I2g== X-Received: by 2002:a05:6e02:20c4:b0:2c9:a514:6a99 with SMTP id 4-20020a056e0220c400b002c9a5146a99mr5023931ilq.50.1649051203223; Sun, 03 Apr 2022 22:46:43 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id h24-20020a6bfb18000000b006497692016bsm5828288iog.15.2022.04.03.22.46.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Apr 2022 22:46:42 -0700 (PDT) Date: Mon, 4 Apr 2022 05:46:39 +0000 From: Oliver Upton To: Reiji Watanabe Subject: Re: [PATCH v2 3/3] KVM: arm64: Start trapping ID registers for 32 bit guests Message-ID: References: <20220401010832.3425787-1-oupton@google.com> <20220401010832.3425787-4-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , kvmarm@lists.cs.columbia.edu, Linux ARM 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 Hi Reiji, On Sun, Apr 03, 2022 at 09:45:15PM -0700, Reiji Watanabe wrote: > On Thu, Mar 31, 2022 at 6:08 PM Oliver Upton wrote: > > > > To date KVM has not trapped ID register accesses from AArch32, meaning > > that guests get an unconstrained view of what hardware supports. This > > can be a serious problem because we try to base the guest's feature > > registers on values that are safe system-wide. Furthermore, KVM does not > > implement the latest ISA in the PMU and Debug architecture, so we > > constrain these fields to supported values. > > > > Since KVM now correctly handles CP15 and CP10 register traps, we no > > longer need to clear HCR_EL2.TID3 for 32 bit guests and will instead > > emulate reads with their safe values. > > > > Signed-off-by: Oliver Upton > > Reviewed-by: Reiji Watanabe > > BTW, due to this, on a system that supports PMUv3, ID_DFR0_E1 value will > become 0 for the aarch32 guest without PMUv3. This is the correct behavior, > but it affects migration. I'm not sure how much we should care about > migration of the aarch32 guest though (and it will be resolved once ID > registers become configurable anyway). I believe userspace has been accessing the sanitised values of these feature registers the entire time, so we should be OK on the UAPI side. >From the guest's perspective, I don't believe there is a meaningful change. Even if the guest were to believe the value it sees in ID_DFR0.PerfMon, it'll crash and burn on the first attempt to poke a PMU register as we synthesize an UNDEF, right? At least now we cover our tracks and ensure the vCPU correctly identifies itself to the guest. This is, of course, unless I missed something painfully obvious :) -- Thanks, Oliver _______________________________________________ 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 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 85234C433EF for ; Mon, 4 Apr 2022 05:47:50 +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: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=u7qDpAbLvq4+RnssWqoBo8JGX+tORMDYePh6fV1w3l8=; b=m06KLLnbniF2B5 ZjmY8Idf3IJv4J+H03sVha7ueA4cuIE4tw+4GMn4nENtwclI1z4uBY1DxlpQTzT8gzxkAr5Ve7fo9 1sloExTEtBO7ACkVpsrsI8MsaghuZERjtbnllcoERfZO34baiYlWWBsLp2DN2nh1H2VwfF+BNrdkB mFMwQGTGX1aWOxzXerpCBubf+5f0dk1OzO/UgeyX22oUUaZ8fBZ0ZchfKWGaXGUY+rOoAyZx7nWDy HW+CNeaaSxLTOz77J7Uabu6lYDw8r2QMNaPV2/d5+CFV3q7uMWTYFYhq5Q5Ilo1nnQm7O5ryBkXPo XdGlBbjLD+6uobRp5l2g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbFY9-00DLm0-2H; Mon, 04 Apr 2022 05:46:49 +0000 Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbFY5-00DLlD-Me for linux-arm-kernel@lists.infradead.org; Mon, 04 Apr 2022 05:46:47 +0000 Received: by mail-il1-x12c.google.com with SMTP id y16so6117584ilc.7 for ; Sun, 03 Apr 2022 22:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=PxHyTiTYyZKrMuWxWAtFUKNTUBv0DkB5ESh3olcmowfb91vjP4mIB7ltmXbb2EO4Ie Hn0GeRK0D5M7MuTpjuO0c0ZlZ8iZQ/XmZtXmlP99/R0r96jXGsRC9Rg2Z7tyOjohujoK Exx+VXoicxCd8wiN4wdqkV57XoUl5gQK7+e9WVsQlGV/2nNKh7iP2ODGiWqdf17NlQWw O6YzGl8E4RjpQY1S3mcUEN4b2S/wkpOiqXJVrRFQGo55cLTpbOF4Kvj+c74BP58sbdSr CVSYMWo6Z1criwdhMT2FOZSupAaTY8VHQ4PyFm6dsg4GnoiusW8Ooh80FsqNa2CLMHh9 04qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=Ex3nzBVpOPGN8JMVQPxdC+7Fva/yASnXQpoQIIdV6NTMZ1vF1S7RQltVl4vzXvZyMO ePFwwNfkIpLXXtokXFKF8+/Cag2mM2aR/GLy7+F4wSJj75q2/N1pg8LGM5+vpDT4GLEP ASMEjS1h+TKK0DpdDCjKYDwS5JyMAUEuU2nGvU+O7h0iMHpy1WbxusFZi/ohIeX2uaW7 EpcbxlzX1XaUjsLxFzg3dtOD56q4+iuW8j7OrN6tC51onjVsaUF9ga4C2VpRaX+3TBvh AK9GaiO0KirrVibVF45rVrWvq4aS5Fd0UmWBzZJUM92klaPO3Vu2qkvbPqX51ZjvL2KY 6ehw== X-Gm-Message-State: AOAM531YryWggJlVnxJ4udr56z0p1IoZ4dUVz64erm7RkYNZ79184QJa Vhq9rz0zCBDjrAC1TF16AYHn043+nQfVfw== X-Google-Smtp-Source: ABdhPJwk+57GkB2Zn+ajUSVOFh+5njhU0KQCOdF0/4uXoez1/cNjCep9/bJs6lDeVvXeVItIol/I2g== X-Received: by 2002:a05:6e02:20c4:b0:2c9:a514:6a99 with SMTP id 4-20020a056e0220c400b002c9a5146a99mr5023931ilq.50.1649051203223; Sun, 03 Apr 2022 22:46:43 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id h24-20020a6bfb18000000b006497692016bsm5828288iog.15.2022.04.03.22.46.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Apr 2022 22:46:42 -0700 (PDT) Date: Mon, 4 Apr 2022 05:46:39 +0000 From: Oliver Upton To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Linux ARM , Peter Shier , Ricardo Koller Subject: Re: [PATCH v2 3/3] KVM: arm64: Start trapping ID registers for 32 bit guests Message-ID: References: <20220401010832.3425787-1-oupton@google.com> <20220401010832.3425787-4-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220403_224645_790636_9DD3E333 X-CRM114-Status: GOOD ( 20.79 ) 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 Hi Reiji, On Sun, Apr 03, 2022 at 09:45:15PM -0700, Reiji Watanabe wrote: > On Thu, Mar 31, 2022 at 6:08 PM Oliver Upton wrote: > > > > To date KVM has not trapped ID register accesses from AArch32, meaning > > that guests get an unconstrained view of what hardware supports. This > > can be a serious problem because we try to base the guest's feature > > registers on values that are safe system-wide. Furthermore, KVM does not > > implement the latest ISA in the PMU and Debug architecture, so we > > constrain these fields to supported values. > > > > Since KVM now correctly handles CP15 and CP10 register traps, we no > > longer need to clear HCR_EL2.TID3 for 32 bit guests and will instead > > emulate reads with their safe values. > > > > Signed-off-by: Oliver Upton > > Reviewed-by: Reiji Watanabe > > BTW, due to this, on a system that supports PMUv3, ID_DFR0_E1 value will > become 0 for the aarch32 guest without PMUv3. This is the correct behavior, > but it affects migration. I'm not sure how much we should care about > migration of the aarch32 guest though (and it will be resolved once ID > registers become configurable anyway). I believe userspace has been accessing the sanitised values of these feature registers the entire time, so we should be OK on the UAPI side. >From the guest's perspective, I don't believe there is a meaningful change. Even if the guest were to believe the value it sees in ID_DFR0.PerfMon, it'll crash and burn on the first attempt to poke a PMU register as we synthesize an UNDEF, right? At least now we cover our tracks and ensure the vCPU correctly identifies itself to the guest. This is, of course, unless I missed something painfully obvious :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel