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 BEC3BC6778C for ; Fri, 6 Jul 2018 15:09:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8351922CB2 for ; Fri, 6 Jul 2018 15:09:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8351922CB2 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 S1754066AbeGFPJn (ORCPT ); Fri, 6 Jul 2018 11:09:43 -0400 Received: from foss.arm.com ([217.140.101.70]:38586 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932635AbeGFPJk (ORCPT ); Fri, 6 Jul 2018 11:09:40 -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 44941ED1; Fri, 6 Jul 2018 08:09:40 -0700 (PDT) Received: from [10.1.206.75] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6D6A63F2EA; Fri, 6 Jul 2018 08:09:36 -0700 (PDT) Subject: Re: [PATCH v3 15/20] kvm: arm/arm64: Allow tuning the physical address size for VM To: Suzuki K Poulose , 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, 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: Marc Zyngier Organization: ARM Ltd Message-ID: <9f1af26e-2913-2b0b-1352-63160096f78f@arm.com> Date: Fri, 6 Jul 2018 16:09:35 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/07/18 14:49, Suzuki K Poulose wrote: > 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 ? I'd be very wary of using that 4th bit to do something that is not in the architecture. We have only a single value left to be used (0b111), and then your scheme clashes with the architecture definition. I'd rather encode things in a way that is independent from the architecture, and be done with it. You can map 0 to 40bits, and we have the ability to express all values the architecture has (just in a different order). Thanks, M. -- Jazz is not dead. It just smells funny...