From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH] KVM: ARM: updtae the VMID generation logic Date: Thu, 29 Mar 2018 17:48:19 +0100 Message-ID: <861sg2su98.wl-marc.zyngier@arm.com> References: <1522335624-24332-1-git-send-email-zhaoshenglong@huawei.com> <20180329152758.za6ppojjiw6ea52u@lakrids.cambridge.arm.com> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1506B49EB8 for ; Thu, 29 Mar 2018 12:40:33 -0400 (EDT) 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 vWclgTtzZdBU for ; Thu, 29 Mar 2018 12:40:11 -0400 (EDT) Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7619449EA2 for ; Thu, 29 Mar 2018 12:40:11 -0400 (EDT) In-Reply-To: <20180329152758.za6ppojjiw6ea52u@lakrids.cambridge.arm.com> 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 To: Mark Rutland , Shannon Zhao Cc: kvmarm@lists.cs.columbia.edu List-Id: kvmarm@lists.cs.columbia.edu On Thu, 29 Mar 2018 16:27:58 +0100, Mark Rutland wrote: > > On Thu, Mar 29, 2018 at 11:00:24PM +0800, Shannon Zhao wrote: > > From: zhaoshenglong > > > > Currently the VMID for some VM is allocated during VCPU entry/exit > > context and will be updated when kvm_next_vmid inversion. So this will > > cause the existing VMs exiting from guest and flush the tlb and icache. > > > > Also, while a platform with 8 bit VMID supports 255 VMs, it can create > > more than 255 VMs and if we create e.g. 256 VMs, some VMs will occur > > page fault since at some moment two VMs have same VMID. > > Have you seen this happen? > > I beleive that update_vttbr() should prevent this. We intialize > kvm_vmid_gen to 1, and when we init a VM, we set its vmid_gen to 0. So > the first time a VM is scheduled, update_vttbr() will allocate a VMID, > and by construction we shouldn't be able to allocate the same VMID to > multiple active VMs, regardless of whether we overflow several > times. I remember testing that exact scenario when we implemented the VMID rollover a (long) while back. Maybe we've introduced a regression, but we're supposed to support 255 VMs running at the same time (which is not the same as having 255 VMs in total). Shannon: if you have observed such regression, please let us know. > > > This patch uses the bitmap to record which VMID used and available. > > Initialize the VMID and vttbr during creating the VM instead of VCPU > > entry/exit context. Also it will return error to user space if it wants > > to create VMs more than the supporting number. > > This creates a functional regression for anyone creating a large number > of VMs. Indeed, and I'm not buys that approach at all. As I said above, the intent is that we can have up to 2^VMID_SIZE-1 VMs running at the same time, and *any* number of VMs in the system. > If VMID overflow is a real bottleneck, it would be vastly better to > improve the VMID allocator along the lines of the arm64 ASID allocator, > so that upon overflow we reserve the set of active VMIDs (and therefore > avoid expensive TLB + icache maintenance). That does not require a > global limit on the number of VMs. +1. Thanks, M. -- Jazz is not dead, it just smell funny.