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 179D0C4167B for ; Tue, 29 Nov 2022 16:37:38 +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:In-Reply-To:From: References:Cc:To:Subject:Date:Message-ID:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=9lANDLrua3Ad/MvmwB4rLpWyTxYh3o7i94LCKQYTr6U=; b=opl43FphZpI+BuIWEnDw1K6oDY 8nkIzbgelxxKOi3kp7XjNsnAic13sVjtNm0KStt5eYGqe0AeSP9FNH7Z/WmH5UqbQz9bPgYRxX9// cN4C/WuP20WmQMp5onXzwpeo9uTrl5V2cCVxfb6Z+PYZTjpicR8zf0ubiAd+DBVwHH5UflwKe3Ljl PwW/HeheVUsaADsfsTWUG7bM4QFFu0c3/RcDLKZUTTB+O6cZ30XXFkh2LpbYqegvT3y2Ty+EM5wLZ r/sZviIIFouPP7UjmZxCPpCRguWMtokyrMjeE2ZXJ7j7BI3TVHY+HVOUnwnAKirrwb9yqWVrHcWze 8M3WzzxA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p03ar-00AAPz-J6; Tue, 29 Nov 2022 16:36:25 +0000 Received: from mail-he1eur04on0605.outbound.protection.outlook.com ([2a01:111:f400:fe0d::605] helo=EUR04-HE1-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p03am-00AANR-WC for linux-arm-kernel@lists.infradead.org; Tue, 29 Nov 2022 16:36:23 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z6a2gNLF0TXZhR02ToBluoscqSAjISQVqbJY9P0rWlaseAMdJU0vvNr4yljR7atYxNadNznZtkGfeCxf8Ay4XkbV3vJL/ltKw1pYX3M4YZClIV8aY70Eykhklju2cbRFxrJeMOhCiI13bypfE6Ceb/AAj8vTwWSpwsW5a7/jCCgjarDG7f/csSO+hseLM3MI4VMm1niax7airPurVv2ZRQ3aQuaTshmEv3/nrob+bRhgPWp2llWs4CZguyvQO9zwScoHqmclts7lQ88hHY5ItE5hM0iOMCg7AX0dgSx7hYoNowEpAMPGs0RVkGqfxz2bsHjIAd3fS/vVXipv1xWV2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s8mt87+UBpMgItEMw7KrK+slvfYNns1l7Lq3aMjJHmU=; b=fgJTkXBGBfUqRa6yzwK1QBhEyJKIb3btwf4ZpmMfmmWAF6unBWZvZO8PHAMgocUOTEg66LRA+VYGAoOSyEqYb/LOE/j2wrBbVbuat07v4N63E36wSxKtO4mkoupnZZ3oJBCT/Eagufcvy6R+VyZlayEETPZqMEE3uU1twovT+mDAJdIl8VuZGzCI6yselJDDhLp6KecyDokABjTAGklmLzfRcuwgJkWV6LRb0oiXdVuxCYKCGZrlzSkxXnWjaMFVU9Qw6uVs+qU2TPlmsjoMUiqMSWm4VXqMw4IYSMsUDV7D6rdLw4pn6eNdji9xgLdNFRAIySPAv4DK/tTkrF0i5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s8mt87+UBpMgItEMw7KrK+slvfYNns1l7Lq3aMjJHmU=; b=CVVIn+wM2mUOcmun1OimSR+EjPtt1ApoBpo0aDhwFQS1IvFW5Er4li7O6TU3gd9tn4EYMALKYpK+NWDHkbU4hsvBnubj9ywlt+u83gABrvWgaEpyevFgs+khGjJ9+SqPWpsSHAr/uxx6V9C88KwVUsvFQe7DWf3+mUGmYoan/hE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from AS8PR08MB6995.eurprd08.prod.outlook.com (2603:10a6:20b:34d::13) by DB9PR08MB7675.eurprd08.prod.outlook.com (2603:10a6:10:37e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.8; Tue, 29 Nov 2022 16:36:16 +0000 Received: from AS8PR08MB6995.eurprd08.prod.outlook.com ([fe80::e825:ff01:1f8:4c1f]) by AS8PR08MB6995.eurprd08.prod.outlook.com ([fe80::e825:ff01:1f8:4c1f%4]) with mapi id 15.20.5880.008; Tue, 29 Nov 2022 16:36:15 +0000 Message-ID: <498f586c-49f4-3fd9-06c5-a32b7773e516@arm.com> Date: Tue, 29 Nov 2022 16:35:42 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v2 00/19] arm64: Enable LPA2 support for 4k and 16k pages Content-Language: en-US To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, Marc Zyngier , Will Deacon , Mark Rutland , Kees Cook , Catalin Marinas , Mark Brown , Anshuman Khandual , Richard Henderson References: <20221124123932.2648991-1-ardb@kernel.org> <053a9129-2424-e1fe-0e7d-b410984b7bfa@arm.com> From: Ryan Roberts In-Reply-To: X-ClientProxiedBy: LO4P265CA0140.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c4::13) To AS8PR08MB6995.eurprd08.prod.outlook.com (2603:10a6:20b:34d::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR08MB6995:EE_|DB9PR08MB7675:EE_ X-MS-Office365-Filtering-Correlation-Id: 8de082c7-4dfd-4280-f64a-08dad227c34f NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f3Ft1ZoCRz0EWlBXMTa4/UCPn5+/U0Qx2DLMsUZTdvx8kYvR6YtPNvy6GvZxZCIc5Np0uCssYvgvcJUlNZelR+h8JGN50GsW/7QhL0tarDdzrooMRkzpbwPEuhV1cu8Ne4ptfo288uc28eWT/+XMGLEonFNRY7dGHl3NA2S2XTfjgSKHd1CeUVXF671kmhmOexPnIoBfxRP+1nC9XuMDJl1XUaqCsf/U/E2Ea2YhyHpzIHed44ckAkEpIKzxsaV48ewEP8VDGslpMUMviYwA96R9rUY78JJqgOaxbuNg+N/5zn2aVn6PUbwTDXlev9OEqqv/RFma8TpnxbB5u6tUxizZxxFBUIFFk4+KqwXESumt6EjSqkA5vWni9yajbcL1imPfs74WqkoNoVzeTk9Qm6r+E8yeb3FB0HyLuETdBhPHhlJpM6NMOdlKdW7QZcPWvL5uOe0ejgh6FHkXkEOLsmJnkLKndTDGLe6hG6St3zj6tJ5r8SEk1vYW8q8uHnq7ZSJVYJhC7yCreb5SxYSMpLTSVj0XJpr8V8apzhmoDjnn3FfbPb7yu+GW4rE6ZKOZw6nonweU4xI2MGkqZc4FF07IrBBEd+WQpkH46RQTCPOj23DjfawMYPnz7D3m+2Z8/QcGzhsovwwzncPeJ6RJZl/7LPUbwQnA/EsKScXBBEQM3r7SUnrC339L43crQ+7cQ6Pi+AR+8iL61/DzNNLuyP/K2jzOi0D49xp9Ns1/gcM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR08MB6995.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(396003)(346002)(39850400004)(136003)(366004)(376002)(451199015)(66899015)(83380400001)(31686004)(31696002)(53546011)(6506007)(6486002)(36756003)(86362001)(38100700002)(186003)(2616005)(54906003)(5660300002)(44832011)(6666004)(478600001)(6512007)(26005)(66556008)(6916009)(8676002)(316002)(66946007)(66476007)(41300700001)(2906002)(4326008)(8936002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?blVIUm9Uc3JKenp4b3EzSll0eENjM3phOVYxZ3prUUhwWHJRRHhzODZ1cXI2?= =?utf-8?B?ZEgvVWJ2VGNNQVpoalNvdVRwNUswOWtrSUovK2gwSjJrcGR2M0dUdExJQ0pl?= =?utf-8?B?d1U5ZmgwWDBReUEvMkpLZ1MzOEwxVGFSUktETHptS2E3dThKb2w0YUZUYWtM?= =?utf-8?B?b08raXEvbzB2WVBFTnpqOUYrb0JDNFhEcC9GWUFrelNUZU5NYUJaNVF0Q1M5?= =?utf-8?B?NG5NUWtnb0pVYXJMTlBORkQzbUNIa1dmU3A4Y1p0VXNGWjM2S2UrSXk2K2ZY?= =?utf-8?B?WGJwK2d4Q2RoakRDN1VURnhaQkw3SzZQWkFIc1lpenY2OEp5NDVoRXdGdkxR?= =?utf-8?B?VVU2Z2VCN0d2YTlJQ2NLL3FrMFROUzBpUDRicVRHb1U2YzVSWWpHUDRGZi9K?= =?utf-8?B?TGFibFFpcVVEaVBNaTNnaEdrejRxZVlSc1JHWCtESFFiZnYyeXdWeUYzRytL?= =?utf-8?B?dXhLRnR0czhmejdLRUxUOXJyQWgya29lVnF6RFpsYVZuQkliMEdjcUQwSGly?= =?utf-8?B?bHpabktodTJXcU4yQW9ZNi9TNDhURlhCMTVzbUw1T0VzdW1HdVlPR2JxdUZR?= =?utf-8?B?R0VmWi9oV0dvWG1jdmpncjE1R083STJacE9INUMzcXF5alZydmx4TStoVXEw?= =?utf-8?B?OEdCRzZ2S0haNW54U2RjU2Rva1hxMGtiNy85czVXclI5bGd6N3Jldi9CcHY1?= =?utf-8?B?MXZENVNBcCtaN3pMdTRvQXlma0gzRDF3OUNoNnROck96b0FDRDVVUHREWVJm?= =?utf-8?B?bnJVTUJ5dmVyREE2VmZCbWxNUWNxakZVbEhMYTBaMFpkbWdCeEYvb1ZOTDEr?= =?utf-8?B?ZGZEOXhIaE5tMkRvVEU1dmJKRU5Day8yRVVWclJkUUpyMnlJaFB3NFVGalRS?= =?utf-8?B?cmRKZTR1QmVLaWFZR3FSOGJvaFRJWGZRQ2l6dzhiODIzYkNDOGVOaUdDSENk?= =?utf-8?B?c2JxaExlaGxJVno4czRGQTluejlLcGY2OWlPZkRDb3hkY0pMZkNEYm9BN3FD?= =?utf-8?B?SnBrT2RqRGhOWC8zeS9HNndpQVBFTGRpN3IvWVFCc1hXQ1Y2dVJLTTdkVlJS?= =?utf-8?B?blF5SnFGSHM0RHo1Z1BiZVMxdmRLRytKaDNRQVNaMnh3b05qb3U5bFNFRitY?= =?utf-8?B?UWRTQmF0OWErekkxQk1uSFh4V1hDdkw3akpTc2RiZW43TElhbFRkT1ZSMFc2?= =?utf-8?B?b243T3lWQXJrTjIwa243Szk1djN4bGUyVUJwMHhzNktPNnZ2ZjRqN2hXbEEz?= =?utf-8?B?YURHNlRJTEZzdTA2OEV3c1RYZ3JKTVJadnpmTU5OdjdHWnNtMUpmbXVvTTNC?= =?utf-8?B?U3BDaU5xRkRqK0FEa1M3WTZ4Rkt0YUhreHVuMHVhMVpPM1RTZzBpSTdUUjVN?= =?utf-8?B?NEx5VGs4RHFxeWRXNGt1VmQzcHJqZE1ENUw1aWpwRXZoS2JjbkFsWit5ODVs?= =?utf-8?B?dWpsQXV1NmRmYytGbkxxSGQvcGIrOVROc3d3eTVtcFJFY0haMXZ0b25ISHNJ?= =?utf-8?B?VmxYWXgxY0JKYjhkNHBQSkY0VWZSTnExZ3Q4VUpvRUNTaGNJOE10bWxhdUJR?= =?utf-8?B?MWdiWmE1Q2dndkEraU41S21TR1U5ZzRuRzZxdk9iR0FaZHh2enZ6dVZCWVQz?= =?utf-8?B?dlcrTDVlTlFOcS9jUjEzdHU4SlJjbkVWNWJSN0h3ZHY3S2dsMU5ZNllmTWxh?= =?utf-8?B?WU82aXBQcWhzb2ErcDNzVkZ5SzlHQTB0cUNtWFg5VVltWnM3a1J4MCtCcGdC?= =?utf-8?B?OURzZWcrQ2d4cHdsV3JScVZHaTF5WS9pMU5GRGF1YlpKdEFwVVFHOVpYZFdu?= =?utf-8?B?VmkxUjUzY3lteHhIcWVJM2o0WkhkQmtnNHhJQ1NVcVVBM0ZkMElDNm1mTGRy?= =?utf-8?B?amQ3VXkxLzlham04Z1llNFdPa2tiUzRJamVweEloNDVmYk9QNDVvN3lxcGZB?= =?utf-8?B?NVNXbkw0KzhvcFNUK1JqV3J1MnpJOUwrUFRVU2Jjc202cHo1em1FM3BQUkhR?= =?utf-8?B?VE1PaTFiSjUxSnl2OGVaZTNtWHdYaGR1cnpGRW9pV0gzelQ5ejRydFEwZTQ5?= =?utf-8?B?SE4rSDJCRHJHV0tJOXRDZExzOWl0bjlFWGl1NzZ3enVTUTROdzBIRlU4M1Rh?= =?utf-8?Q?MxTRhmcS161iAlUDxvR5Luc97?= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8de082c7-4dfd-4280-f64a-08dad227c34f X-MS-Exchange-CrossTenant-AuthSource: AS8PR08MB6995.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2022 16:36:15.3865 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DyxKRJNZWJFr8Tfs3YfYgeha8meD44+j8at93fWcz0XOO66ElyQul87wGmDyIGVlke7uL50w8vp9Epa9+JuOhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7675 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221129_083621_460080_506FDBE7 X-CRM114-Status: GOOD ( 49.93 ) 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 29/11/2022 15:47, Ard Biesheuvel wrote: > On Tue, 29 Nov 2022 at 16:31, Ryan Roberts wrote: >> >> Hi Ard, >> >> As promised, I ran your patch set through my test set up and have noticed a few >> issues. Sorry it turned into rather a long email... >> > > No worries, and thanks a lot for going through the trouble. > >> First, a quick explanation of the test suite: For all valid combinations of the >> below parameters, boot the host kernel on the FVP, then boot the guest kernel in >> a VM, check that booting succeeds all the way to the guest shell then poweroff >> guest followed by host can check shutdown is clean. >> >> Parameters: >> - hw_pa: [48, lpa, lpa2] >> - hw_va: [48, 52] >> - kvm_mode: [vhe, nvhe, protected] >> - host_page_size: [4KB, 16KB, 64KB] >> - host_pa: [48, 52] >> - host_va: [48, 52] >> - host_load_addr: [low, high] >> - guest_page_size: [64KB] >> - guest_pa: [52] >> - guest_va: [52] >> - guest_load_addr: [low, high] >> >> When *_load_addr is 'low', that means the RAM is below 48 bits in (I)PA space. >> 'high' means the RAM starts at 2048TB for the guest (52 bit PA), and it means >> there are 2 regions for the host; one at 0x880000000000 (48 bit PA) sized to >> hold the kernel image only and another at 0x8800000000000 (52 bit PA) sized at >> 4GB. The FVP only allows RAM at certain locations and having a contiguous region >> cross the 48 bit boundary is not an option. So I chose these values to ensure >> that the linear map size is within 51 bits, which is a requirement for >> nhve/protected mode kvm. >> >> In all cases, I preload TF-A bl31, kernel, dt and initrd into RAM and run the >> FVP. This sidesteps problems with EFI needing low memory, and with the FVP's >> block devices needing DMA memory below 44 bits PA. bl31 and dt are appropriately >> fixed up for the 2 different memory layouts. >> >> Given this was designed to test my KVM changes, I was previously running these >> without the host_load_addr=high option for the 4k and 16k host kernels (since >> this requires your patch set). In this situation there are 132 valid configs and >> all of them pass. >> >> I then rebased my changes on top of yours and added in the host_load_addr=high >> option. Now there are 186 valid configs, 64 of which fail. (some of these >> failures are regressions). From a quick initial triage, there are 3 failure modes: >> >> >> 1) 18 FAILING TESTS: Host kernel never outputs anything to console >> >> TF-A runs successfully, says it is jumping to the kernel, then nothing further >> is seen. I'm pretty confident that the blobs are loaded into memory correctly >> because the same framework is working for the other configs (including 64k >> kernel loaded into high memory). This affects all configs where a host kernel >> with 4k or 16k pages built with LPA2 support is loaded into high memory. >> > > Not sure how to interpret this in combination with your explanation > above, but if 'loaded high' means that the kernel itself is not in > 48-bit addressable physical memory, this failure is expected. Sorry - my wording was confusing. host_load_addr=high means what I said at the top; the kernel image is loaded at 0x880000000000 in a block of memory sized to hold the kernel image only (actually its forward aligned to 2MB). The dtb and initrd are loaded into a 4GB region at 0x8800000000000. The reason I'm doing this is to ensure that when I create a VM, the memory used for it (at least the vast majority) is coming from the region at 52 bits. I want to do this to prove that the stage2 implementation is correctly handling the 52 OA case. > > Given that we have no way of informing the bootloader or firmware > whether or not a certain kernel image supports running from such a > high offset, it must currently assume it cannot. We've just queued up > a documentation fix to clarify this in the boot protocol, i.e., that > the kernel must be loaded in 48-bit addressable physical memory. OK, but I think what I'm doing complies with this. Unless the DTB also has to be below 48 bits? > > The fact that you had to doctor your boot environment to get around > this kind of proves my point, and unless someone is silly enough to > ship a SoC that cannot function without this, I don't think we should > add this support. > > I understand how this is an interesting case for completeness from a > validation pov, but the reality is that adding support for this would > mean introducing changes amounting to dead code to fragile boot > sequence code that is already hard to maintain. I'm not disagreeing. But I think what I'm doing should conform with the requirements? (Previously I had the tests set up to just have a single region of memory above 52 bits and the kernel image was placed there. That works/worked for the 64KB kernel. But I brought the kernel image to below 48 bits to align with the requirements of this patch set. If you see an easier way for me to validate 52 bit OAs in the stage 2 (and ideally hyp stage 1), then I'm all ears! > >> >> 2) 4 FAILING TESTS: Host kernel gets stuck initializing KVM >> >> During kernel boot, last console log is "kvm [1]: vgic interrupt IRQ9". All >> failing tests are configured for protected KVM, and are build with LPA2 >> support, running on non-LPA2 HW. >> > > I will try to reproduce this locally. > >> >> 3) 42 FAILING TESTS: Guest kernel never outputs anything to console >> >> Host kernel boots fine, and we attempt to launch a guest kernel using kvmtool. >> There is no error reported, but the guest never outputs anything. Haven't >> worked out which config options are common to all failures yet. >> > > This goes a bit beyond what I am currently set up for in terms of > testing, but I'm happy to help narrow this down. > >> >> Finally, I removed my code, and ran with your patch set as provided. For this I >> hacked up my test suite to boot the host, and ignore booting a guest. I also >> didn't bother to vary the KVM mode and just left it in VHE mode. There were 46 >> valid configs here, of which 4 failed. They were all the same failure mode as >> (1) above. Failing configs were: >> >> id hw_pa hw_va host_page_size host_pa host_va host_load_addr >> ------------------------------------------------------------------ >> 40 lpa 52 4k 52 52 high >> 45 lpa 52 16k 52 52 high >> 55 lpa2 52 4k 52 52 high >> 60 lpa2 52 16k 52 52 high >> > > Same point as above then, I guess. > >> >> So on the balance of probabilities, I think failure mode (1) is very likely to >> be due to a bug in your code. (2) and (3) could be my issue or your issue: I >> propose to dig into those a bit further and will get back to you on them. I >> don't plan to look any further into (1). >> > > Thanks again. (1) is expected, and (2) is something I will investigate further. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel