From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antonios Motakis Subject: Re: [Android-virt] [PATCH v5 04/13] ARM: KVM: Memory virtualization setup Date: Tue, 13 Dec 2011 18:10:16 +0100 Message-ID: <4EE786F8.3090702@virtualopensystems.com> References: <20111211102403.21693.6887.stgit@localhost> <20111211102442.21693.544.stgit@localhost> <4EE61245.1010100@redhat.com> <4EE61A7F.7030006@redhat.com> <4EE62292.8070709@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Christoffer Dall , Marc.Zyngier@arm.com, tech@virtualopensystems.com, android-virt@lists.cs.columbia.edu, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mail-lpp01m010-f46.google.com ([209.85.215.46]:59451 "EHLO mail-lpp01m010-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754080Ab1LMRKX (ORCPT ); Tue, 13 Dec 2011 12:10:23 -0500 Received: by lagp5 with SMTP id p5so2483934lag.19 for ; Tue, 13 Dec 2011 09:10:21 -0800 (PST) In-Reply-To: <4EE62292.8070709@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/12/2011 04:49 PM, Avi Kivity wrote: > On 12/12/2011 05:25 PM, Peter Maydell wrote: >> On 12 December 2011 15:15, Avi Kivity wrote: >>> We need to differentiate in how Linux-as-a-guest acts and how the cpu is >>> supposed to work. A guest operating system can theoretically assign the >>> ASID x to process A running on vcpu 0, and the same ASID x to process B >>> running on vcpu 1 >> That would be a guest bug. From the ARM ARM: >> "For a symmetric multiprocessor cluster where a single operating system >> is running on the set of processing elements, ARMv7 requires all ASID >> values to be assigned uniquely within any single Inner Shareable domain. >> In other words, each ASID value must have the same meaning to all >> processing elements in the system." > Thanks. So per-vm vmids should work. > We where playing with a VMID recycling patch based on the assumption of per-cpu VMIDs being possible, which would have the advantage of recycling VMIDs without much complicated locking (inspired by the KVM SVM implementation). However we killed it with fire and hot plasma when it became clear it violated the ARM spec... On the other hand, maybe we could do something with per vcpu VMIDs, but with proper synchronization accross physical CPUs in order to be compatible with the spec, but at the same time potentially allow a buggy guest to run? Since in practice a lot of CPUs will not share TLB (and instruction cache) structures, maybe it's possible that there is software out there that violates the spec, without having problems on the real hw. Anyway VMID reuse will be available soon, and the difference between a per vm and per vcpu implementation is a couple of trivial lines of code.