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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 8D297C3279B for ; Fri, 6 Jul 2018 13:49:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4E0C123E08 for ; Fri, 6 Jul 2018 13:49:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E0C123E08 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754098AbeGFNtg (ORCPT ); Fri, 6 Jul 2018 09:49:36 -0400 Received: from foss.arm.com ([217.140.101.70]:37138 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753683AbeGFNtf (ORCPT ); Fri, 6 Jul 2018 09:49:35 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 91C83ED1; Fri, 6 Jul 2018 06:49:34 -0700 (PDT) Received: from [10.1.206.73] (en101.cambridge.arm.com [10.1.206.73]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0F4C93F5AD; Fri, 6 Jul 2018 06:49:31 -0700 (PDT) Subject: Re: [PATCH v3 15/20] kvm: arm/arm64: Allow tuning the physical address size for VM To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, marc.zyngier@arm.com, cdall@kernel.org, eric.auger@redhat.com, julien.grall@arm.com, catalin.marinas@arm.com, punit.agrawal@arm.com, qemu-devel@nongnu.org, Peter Maydel , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= References: <1530270944-11351-1-git-send-email-suzuki.poulose@arm.com> <1530270944-11351-16-git-send-email-suzuki.poulose@arm.com> <20180704155104.GN4828@arm.com> <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> From: Suzuki K Poulose Message-ID: Date: Fri, 6 Jul 2018 14:49:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/07/18 23:03, Suzuki K Poulose wrote: > On 07/04/2018 04:51 PM, Will Deacon wrote: >> Hi Suzuki, >> >> On Fri, Jun 29, 2018 at 12:15:35PM +0100, Suzuki K Poulose wrote: >>> Allow specifying the physical address size for a new VM via >>> the kvm_type argument for KVM_CREATE_VM ioctl. This allows >>> us to finalise the stage2 page table format as early as possible >>> and hence perform the right checks on the memory slots without >>> complication. The size is encoded as Log2(PA_Size) in the bits[7:0] >>> of the type field and can encode more information in the future if >>> required. The IPA size is still capped at 40bits. >>> >>> Cc: Marc Zyngier >>> Cc: Christoffer Dall >>> Cc: Peter Maydel >>> Cc: Paolo Bonzini >>> Cc: Radim Krčmář >>> Signed-off-by: Suzuki K Poulose >>> --- >>>   arch/arm/include/asm/kvm_mmu.h   |  2 ++ >>>   arch/arm64/include/asm/kvm_arm.h | 10 +++------- >>>   arch/arm64/include/asm/kvm_mmu.h |  2 ++ >>>   include/uapi/linux/kvm.h         | 10 ++++++++++ >>>   virt/kvm/arm/arm.c               | 24 ++++++++++++++++++++++-- >>>   5 files changed, 39 insertions(+), 9 deletions(-) >> >> [...] >> >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>> index 4df9bb6..fa4cab0 100644 >>> --- a/include/uapi/linux/kvm.h >>> +++ b/include/uapi/linux/kvm.h >>> @@ -751,6 +751,16 @@ struct kvm_ppc_resize_hpt { >>>   #define KVM_S390_SIE_PAGE_OFFSET 1 >>>   /* >>> + * On arm/arm64, machine type can be used to request the physical >>> + * address size for the VM. Bits [7-0] have been reserved for the >>> + * PA size shift (i.e, log2(PA_Size)). For backward compatibility, >>> + * value 0 implies the default IPA size, which is 40bits. >>> + */ >>> +#define KVM_VM_TYPE_ARM_PHYS_SHIFT_MASK    0xff >>> +#define KVM_VM_TYPE_ARM_PHYS_SHIFT(x)        \ >>> +    ((x) & KVM_VM_TYPE_ARM_PHYS_SHIFT_MASK) >> >> This seems like you're allocating quite a lot of bits in a non-extensible >> interface to a fairly esoteric parameter. Would it be better to add another >> ioctl, or condense the number of sizes you support instead? > > As I explained in the other thread, we need the size as soon as the VM > is created. The major challenge is keeping the backward compatibility by > mapping 0 to 40bits. I will give it a thought. Here is one option. We could re-use the {V}TCR_ELx.{I}PS field format, which occupies 3 bits and has the following definitions. (ID_AA64MMFR0_EL1:PARange also has the field definitions, except that the field is 4bits wide, but only 3bits are used) 000 32 bits, 4GB. 001 36 bits, 64GB. 010 40 bits, 1TB. 011 42 bits, 4TB. 100 44 bits, 16TB. 101 48 bits, 256TB. 110 52 bits, 4PB But we need to map 0 => 40bits IPA to make our ABI backward compatible. So we could use the additional one bit to indicate that IPA size is requested in the 3 bits. i.e, machine_type: Bit [2:0] - Requested IPA size. Values follow VTCR_EL2.PS format. Bit [3] - 1 => IPA Size bits (Bits[2:0]) requested. 0 => Not requested The only minor down side is restricting to the predefined values above, which is not a real issue for a VM. Thoughts ? Suzuki From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suzuki K Poulose Subject: Re: [PATCH v3 15/20] kvm: arm/arm64: Allow tuning the physical address size for VM Date: Fri, 6 Jul 2018 14:49:30 +0100 Message-ID: References: <1530270944-11351-1-git-send-email-suzuki.poulose@arm.com> <1530270944-11351-16-git-send-email-suzuki.poulose@arm.com> <20180704155104.GN4828@arm.com> <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Cc: cdall@kernel.org, kvm@vger.kernel.org, marc.zyngier@arm.com, catalin.marinas@arm.com, punit.agrawal@arm.com, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org To: Will Deacon Return-path: In-Reply-To: <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org T24gMDQvMDcvMTggMjM6MDMsIFN1enVraSBLIFBvdWxvc2Ugd3JvdGU6Cj4gT24gMDcvMDQvMjAx OCAwNDo1MSBQTSwgV2lsbCBEZWFjb24gd3JvdGU6Cj4+IEhpIFN1enVraSwKPj4KPj4gT24gRnJp LCBKdW4gMjksIDIwMTggYXQgMTI6MTU6MzVQTSArMDEwMCwgU3V6dWtpIEsgUG91bG9zZSB3cm90 ZToKPj4+IEFsbG93IHNwZWNpZnlpbmcgdGhlIHBoeXNpY2FsIGFkZHJlc3Mgc2l6ZSBmb3IgYSBu ZXcgVk0gdmlhCj4+PiB0aGUga3ZtX3R5cGUgYXJndW1lbnQgZm9yIEtWTV9DUkVBVEVfVk0gaW9j dGwuIFRoaXMgYWxsb3dzCj4+PiB1cyB0byBmaW5hbGlzZSB0aGUgc3RhZ2UyIHBhZ2UgdGFibGUg Zm9ybWF0IGFzIGVhcmx5IGFzIHBvc3NpYmxlCj4+PiBhbmQgaGVuY2UgcGVyZm9ybSB0aGUgcmln aHQgY2hlY2tzIG9uIHRoZSBtZW1vcnkgc2xvdHMgd2l0aG91dAo+Pj4gY29tcGxpY2F0aW9uLiBU aGUgc2l6ZSBpcyBlbmNvZGVkIGFzIExvZzIoUEFfU2l6ZSkgaW4gdGhlIGJpdHNbNzowXQo+Pj4g b2YgdGhlIHR5cGUgZmllbGQgYW5kIGNhbiBlbmNvZGUgbW9yZSBpbmZvcm1hdGlvbiBpbiB0aGUg ZnV0dXJlIGlmCj4+PiByZXF1aXJlZC4gVGhlIElQQSBzaXplIGlzIHN0aWxsIGNhcHBlZCBhdCA0 MGJpdHMuCj4+Pgo+Pj4gQ2M6IE1hcmMgWnluZ2llciA8bWFyYy56eW5naWVyQGFybS5jb20+Cj4+ PiBDYzogQ2hyaXN0b2ZmZXIgRGFsbCA8Y2RhbGxAa2VybmVsLm9yZz4KPj4+IENjOiBQZXRlciBN YXlkZWwgPHBldGVyLm1heWRlbGxAbGluYXJvLm9yZz4KPj4+IENjOiBQYW9sbyBCb256aW5pIDxw Ym9uemluaUByZWRoYXQuY29tPgo+Pj4gQ2M6IFJhZGltIEtyxI1tw6HFmSA8cmtyY21hckByZWRo YXQuY29tPgo+Pj4gU2lnbmVkLW9mZi1ieTogU3V6dWtpIEsgUG91bG9zZSA8c3V6dWtpLnBvdWxv c2VAYXJtLmNvbT4KPj4+IC0tLQo+Pj4gwqAgYXJjaC9hcm0vaW5jbHVkZS9hc20va3ZtX21tdS5o wqDCoCB8wqAgMiArKwo+Pj4gwqAgYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9rdm1fYXJtLmggfCAx MCArKystLS0tLS0tCj4+PiDCoCBhcmNoL2FybTY0L2luY2x1ZGUvYXNtL2t2bV9tbXUuaCB8wqAg MiArKwo+Pj4gwqAgaW5jbHVkZS91YXBpL2xpbnV4L2t2bS5owqDCoMKgwqDCoMKgwqDCoCB8IDEw ICsrKysrKysrKysKPj4+IMKgIHZpcnQva3ZtL2FybS9hcm0uY8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgfCAyNCArKysrKysrKysrKysrKysrKysrKysrLS0KPj4+IMKgIDUgZmlsZXMgY2hh bmdlZCwgMzkgaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkKPj4KPj4gWy4uLl0KPj4KPj4+ IGRpZmYgLS1naXQgYS9pbmNsdWRlL3VhcGkvbGludXgva3ZtLmggYi9pbmNsdWRlL3VhcGkvbGlu dXgva3ZtLmgKPj4+IGluZGV4IDRkZjliYjYuLmZhNGNhYjAgMTAwNjQ0Cj4+PiAtLS0gYS9pbmNs dWRlL3VhcGkvbGludXgva3ZtLmgKPj4+ICsrKyBiL2luY2x1ZGUvdWFwaS9saW51eC9rdm0uaAo+ Pj4gQEAgLTc1MSw2ICs3NTEsMTYgQEAgc3RydWN0IGt2bV9wcGNfcmVzaXplX2hwdCB7Cj4+PiDC oCAjZGVmaW5lIEtWTV9TMzkwX1NJRV9QQUdFX09GRlNFVCAxCj4+PiDCoCAvKgo+Pj4gKyAqIE9u IGFybS9hcm02NCwgbWFjaGluZSB0eXBlIGNhbiBiZSB1c2VkIHRvIHJlcXVlc3QgdGhlIHBoeXNp Y2FsCj4+PiArICogYWRkcmVzcyBzaXplIGZvciB0aGUgVk0uIEJpdHMgWzctMF0gaGF2ZSBiZWVu IHJlc2VydmVkIGZvciB0aGUKPj4+ICsgKiBQQSBzaXplIHNoaWZ0IChpLmUsIGxvZzIoUEFfU2l6 ZSkpLiBGb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwKPj4+ICsgKiB2YWx1ZSAwIGltcGxpZXMg dGhlIGRlZmF1bHQgSVBBIHNpemUsIHdoaWNoIGlzIDQwYml0cy4KPj4+ICsgKi8KPj4+ICsjZGVm aW5lIEtWTV9WTV9UWVBFX0FSTV9QSFlTX1NISUZUX01BU0vCoMKgwqAgMHhmZgo+Pj4gKyNkZWZp bmUgS1ZNX1ZNX1RZUEVfQVJNX1BIWVNfU0hJRlQoeCnCoMKgwqDCoMKgwqDCoCBcCj4+PiArwqDC oMKgICgoeCkgJiBLVk1fVk1fVFlQRV9BUk1fUEhZU19TSElGVF9NQVNLKQo+Pgo+PiBUaGlzIHNl ZW1zIGxpa2UgeW91J3JlIGFsbG9jYXRpbmcgcXVpdGUgYSBsb3Qgb2YgYml0cyBpbiBhIG5vbi1l eHRlbnNpYmxlCj4+IGludGVyZmFjZSB0byBhIGZhaXJseSBlc290ZXJpYyBwYXJhbWV0ZXIuIFdv dWxkIGl0IGJlIGJldHRlciB0byBhZGQgYW5vdGhlcgo+PiBpb2N0bCwgb3IgY29uZGVuc2UgdGhl IG51bWJlciBvZiBzaXplcyB5b3Ugc3VwcG9ydCBpbnN0ZWFkPwo+IAo+IEFzIEkgZXhwbGFpbmVk IGluIHRoZSBvdGhlciB0aHJlYWQsIHdlIG5lZWQgdGhlIHNpemUgYXMgc29vbiBhcyB0aGUgVk0K PiBpcyBjcmVhdGVkLiBUaGUgbWFqb3IgY2hhbGxlbmdlIGlzIGtlZXBpbmcgdGhlIGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgYnkKPiBtYXBwaW5nIDAgdG8gNDBiaXRzLiBJIHdpbGwgZ2l2ZSBpdCBh IHRob3VnaHQuCgpIZXJlIGlzIG9uZSBvcHRpb24uIFdlIGNvdWxkIHJlLXVzZSB0aGUge1Z9VENS X0VMeC57SX1QUyBmaWVsZCBmb3JtYXQsIHdoaWNoCm9jY3VwaWVzIDMgYml0cyBhbmQgaGFzIHRo ZSBmb2xsb3dpbmcgZGVmaW5pdGlvbnMuIChJRF9BQTY0TU1GUjBfRUwxOlBBUmFuZ2UKYWxzbyBo YXMgdGhlIGZpZWxkIGRlZmluaXRpb25zLCBleGNlcHQgdGhhdCB0aGUgZmllbGQgaXMgNGJpdHMg d2lkZSwgYnV0Cm9ubHkgM2JpdHMgYXJlIHVzZWQpCgowMDAgMzIgYml0cywgNEdCLgowMDEgMzYg Yml0cywgNjRHQi4KMDEwIDQwIGJpdHMsIDFUQi4KMDExIDQyIGJpdHMsIDRUQi4KMTAwIDQ0IGJp dHMsIDE2VEIuCjEwMSA0OCBiaXRzLCAyNTZUQi4KMTEwIDUyIGJpdHMsIDRQQgoKQnV0IHdlIG5l ZWQgdG8gbWFwIDAgPT4gNDBiaXRzIElQQSB0byBtYWtlIG91ciBBQkkgYmFja3dhcmQgY29tcGF0 aWJsZS4gU28Kd2UgY291bGQgdXNlIHRoZSBhZGRpdGlvbmFsIG9uZSBiaXQgdG8gaW5kaWNhdGUg dGhhdCBJUEEgc2l6ZSBpcyByZXF1ZXN0ZWQKaW4gdGhlIDMgYml0cy4KCmkuZSwKCm1hY2hpbmVf dHlwZToKCkJpdCBbMjowXQktIFJlcXVlc3RlZCBJUEEgc2l6ZS4gVmFsdWVzIGZvbGxvdyBWVENS X0VMMi5QUyBmb3JtYXQuCgpCaXQgWzNdCQktIDEgPT4gSVBBIFNpemUgYml0cyAoQml0c1syOjBd KSByZXF1ZXN0ZWQuCgkJMCA9PiBOb3QgcmVxdWVzdGVkCgpUaGUgb25seSBtaW5vciBkb3duIHNp ZGUgaXMgcmVzdHJpY3RpbmcgdG8gdGhlIHByZWRlZmluZWQgdmFsdWVzIGFib3ZlLAp3aGljaCBp cyBub3QgYSByZWFsIGlzc3VlIGZvciBhIFZNLgoKVGhvdWdodHMgPwoKU3V6dWtpCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmt2bWFybSBtYWlsaW5nIGxp c3QKa3ZtYXJtQGxpc3RzLmNzLmNvbHVtYmlhLmVkdQpodHRwczovL2xpc3RzLmNzLmNvbHVtYmlh LmVkdS9tYWlsbWFuL2xpc3RpbmZvL2t2bWFybQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbR7E-00018P-Db for qemu-devel@nongnu.org; Fri, 06 Jul 2018 09:49:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbR7A-00009m-G7 for qemu-devel@nongnu.org; Fri, 06 Jul 2018 09:49:40 -0400 Received: from foss.arm.com ([217.140.101.70]:44592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbR7A-00006v-7p for qemu-devel@nongnu.org; Fri, 06 Jul 2018 09:49:36 -0400 References: <1530270944-11351-1-git-send-email-suzuki.poulose@arm.com> <1530270944-11351-16-git-send-email-suzuki.poulose@arm.com> <20180704155104.GN4828@arm.com> <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> From: Suzuki K Poulose Message-ID: Date: Fri, 6 Jul 2018 14:49:30 +0100 MIME-Version: 1.0 In-Reply-To: <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 15/20] kvm: arm/arm64: Allow tuning the physical address size for VM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, marc.zyngier@arm.com, cdall@kernel.org, eric.auger@redhat.com, julien.grall@arm.com, catalin.marinas@arm.com, punit.agrawal@arm.com, qemu-devel@nongnu.org, Peter Maydel , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= On 04/07/18 23:03, Suzuki K Poulose wrote: > On 07/04/2018 04:51 PM, Will Deacon wrote: >> Hi Suzuki, >> >> On Fri, Jun 29, 2018 at 12:15:35PM +0100, Suzuki K Poulose wrote: >>> Allow specifying the physical address size for a new VM via >>> the kvm_type argument for KVM_CREATE_VM ioctl. This allows >>> us to finalise the stage2 page table format as early as possible >>> and hence perform the right checks on the memory slots without >>> complication. The size is encoded as Log2(PA_Size) in the bits[7:0] >>> of the type field and can encode more information in the future if >>> required. The IPA size is still capped at 40bits. >>> >>> Cc: Marc Zyngier >>> Cc: Christoffer Dall >>> Cc: Peter Maydel >>> Cc: Paolo Bonzini >>> Cc: Radim Kr=C4=8Dm=C3=A1=C5=99 >>> Signed-off-by: Suzuki K Poulose >>> --- >>> =C2=A0 arch/arm/include/asm/kvm_mmu.h=C2=A0=C2=A0 |=C2=A0 2 ++ >>> =C2=A0 arch/arm64/include/asm/kvm_arm.h | 10 +++------- >>> =C2=A0 arch/arm64/include/asm/kvm_mmu.h |=C2=A0 2 ++ >>> =C2=A0 include/uapi/linux/kvm.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | 10 ++++++++++ >>> =C2=A0 virt/kvm/arm/arm.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 24 ++++++++++++++++++++++-- >>> =C2=A0 5 files changed, 39 insertions(+), 9 deletions(-) >> >> [...] >> >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>> index 4df9bb6..fa4cab0 100644 >>> --- a/include/uapi/linux/kvm.h >>> +++ b/include/uapi/linux/kvm.h >>> @@ -751,6 +751,16 @@ struct kvm_ppc_resize_hpt { >>> =C2=A0 #define KVM_S390_SIE_PAGE_OFFSET 1 >>> =C2=A0 /* >>> + * On arm/arm64, machine type can be used to request the physical >>> + * address size for the VM. Bits [7-0] have been reserved for the >>> + * PA size shift (i.e, log2(PA_Size)). For backward compatibility, >>> + * value 0 implies the default IPA size, which is 40bits. >>> + */ >>> +#define KVM_VM_TYPE_ARM_PHYS_SHIFT_MASK=C2=A0=C2=A0=C2=A0 0xff >>> +#define KVM_VM_TYPE_ARM_PHYS_SHIFT(x)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 \ >>> +=C2=A0=C2=A0=C2=A0 ((x) & KVM_VM_TYPE_ARM_PHYS_SHIFT_MASK) >> >> This seems like you're allocating quite a lot of bits in a non-extensi= ble >> interface to a fairly esoteric parameter. Would it be better to add an= other >> ioctl, or condense the number of sizes you support instead? >=20 > As I explained in the other thread, we need the size as soon as the VM > is created. The major challenge is keeping the backward compatibility b= y > mapping 0 to 40bits. I will give it a thought. Here is one option. We could re-use the {V}TCR_ELx.{I}PS field format, wh= ich occupies 3 bits and has the following definitions. (ID_AA64MMFR0_EL1:PARa= nge also has the field definitions, except that the field is 4bits wide, but only 3bits are used) 000 32 bits, 4GB. 001 36 bits, 64GB. 010 40 bits, 1TB. 011 42 bits, 4TB. 100 44 bits, 16TB. 101 48 bits, 256TB. 110 52 bits, 4PB But we need to map 0 =3D> 40bits IPA to make our ABI backward compatible.= So we could use the additional one bit to indicate that IPA size is requeste= d in the 3 bits. i.e, machine_type: Bit [2:0] - Requested IPA size. Values follow VTCR_EL2.PS format. Bit [3] - 1 =3D> IPA Size bits (Bits[2:0]) requested. 0 =3D> Not requested The only minor down side is restricting to the predefined values above, which is not a real issue for a VM. Thoughts ? Suzuki From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suzuki.Poulose@arm.com (Suzuki K Poulose) Date: Fri, 6 Jul 2018 14:49:30 +0100 Subject: [PATCH v3 15/20] kvm: arm/arm64: Allow tuning the physical address size for VM In-Reply-To: <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> References: <1530270944-11351-1-git-send-email-suzuki.poulose@arm.com> <1530270944-11351-16-git-send-email-suzuki.poulose@arm.com> <20180704155104.GN4828@arm.com> <12d1832a-1a13-7dd4-662b-addf58400789@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/07/18 23:03, Suzuki K Poulose wrote: > On 07/04/2018 04:51 PM, Will Deacon wrote: >> Hi Suzuki, >> >> On Fri, Jun 29, 2018 at 12:15:35PM +0100, Suzuki K Poulose wrote: >>> Allow specifying the physical address size for a new VM via >>> the kvm_type argument for KVM_CREATE_VM ioctl. This allows >>> us to finalise the stage2 page table format as early as possible >>> and hence perform the right checks on the memory slots without >>> complication. The size is encoded as Log2(PA_Size) in the bits[7:0] >>> of the type field and can encode more information in the future if >>> required. The IPA size is still capped at 40bits. >>> >>> Cc: Marc Zyngier >>> Cc: Christoffer Dall >>> Cc: Peter Maydel >>> Cc: Paolo Bonzini >>> Cc: Radim Kr?m?? >>> Signed-off-by: Suzuki K Poulose >>> --- >>> ? arch/arm/include/asm/kvm_mmu.h?? |? 2 ++ >>> ? arch/arm64/include/asm/kvm_arm.h | 10 +++------- >>> ? arch/arm64/include/asm/kvm_mmu.h |? 2 ++ >>> ? include/uapi/linux/kvm.h???????? | 10 ++++++++++ >>> ? virt/kvm/arm/arm.c?????????????? | 24 ++++++++++++++++++++++-- >>> ? 5 files changed, 39 insertions(+), 9 deletions(-) >> >> [...] >> >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>> index 4df9bb6..fa4cab0 100644 >>> --- a/include/uapi/linux/kvm.h >>> +++ b/include/uapi/linux/kvm.h >>> @@ -751,6 +751,16 @@ struct kvm_ppc_resize_hpt { >>> ? #define KVM_S390_SIE_PAGE_OFFSET 1 >>> ? /* >>> + * On arm/arm64, machine type can be used to request the physical >>> + * address size for the VM. Bits [7-0] have been reserved for the >>> + * PA size shift (i.e, log2(PA_Size)). For backward compatibility, >>> + * value 0 implies the default IPA size, which is 40bits. >>> + */ >>> +#define KVM_VM_TYPE_ARM_PHYS_SHIFT_MASK??? 0xff >>> +#define KVM_VM_TYPE_ARM_PHYS_SHIFT(x)??????? \ >>> +??? ((x) & KVM_VM_TYPE_ARM_PHYS_SHIFT_MASK) >> >> This seems like you're allocating quite a lot of bits in a non-extensible >> interface to a fairly esoteric parameter. Would it be better to add another >> ioctl, or condense the number of sizes you support instead? > > As I explained in the other thread, we need the size as soon as the VM > is created. The major challenge is keeping the backward compatibility by > mapping 0 to 40bits. I will give it a thought. Here is one option. We could re-use the {V}TCR_ELx.{I}PS field format, which occupies 3 bits and has the following definitions. (ID_AA64MMFR0_EL1:PARange also has the field definitions, except that the field is 4bits wide, but only 3bits are used) 000 32 bits, 4GB. 001 36 bits, 64GB. 010 40 bits, 1TB. 011 42 bits, 4TB. 100 44 bits, 16TB. 101 48 bits, 256TB. 110 52 bits, 4PB But we need to map 0 => 40bits IPA to make our ABI backward compatible. So we could use the additional one bit to indicate that IPA size is requested in the 3 bits. i.e, machine_type: Bit [2:0] - Requested IPA size. Values follow VTCR_EL2.PS format. Bit [3] - 1 => IPA Size bits (Bits[2:0]) requested. 0 => Not requested The only minor down side is restricting to the predefined values above, which is not a real issue for a VM. Thoughts ? Suzuki