From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH] arm64/kvm: Add generic v8 KVM target Date: Fri, 03 Jul 2015 09:08:14 +0100 Message-ID: <559642EE.1050605@arm.com> References: <1434531646-4873-1-git-send-email-suzuki.poulose@arm.com> <558A6A84.5020603@arm.com> <20150624085128.GA22785@cbox> <558A7936.7020109@arm.com> <20150625123034.GE28244@cbox> <558BF6C9.3000009@arm.com> <558C05A9.8080201@arm.com> <20150626095318.GG28244@cbox> <559180CA.3050905@arm.com> <559185D4.7060308@arm.com> <85D36B67-643B-407F-944F-D18D54FF9909@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Christoffer Dall , kvm-devel , "timur@codeaurora.org" , "vgandhi@codeaurora.org" , "kvmarm@lists.cs.columbia.edu" , arm-mail-list To: "Chalamarla, Tirumalesh" Return-path: Received: from foss.arm.com ([217.140.101.70]:52113 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754878AbbGCIIR (ORCPT ); Fri, 3 Jul 2015 04:08:17 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 02/07/15 21:29, Chalamarla, Tirumalesh wrote: > is there a chance that this get merged in to 4.2? if not is it possible > to accept the other patches like adding implementations explicitly(like > Thunder). We first need to reach a conclusion on this. Until then, I don't plan to get anything in. As for 4.2, it feels way too late (the merge window is almost closed now). Thanks, M. > > Thanks, > Tirumalesh. >> On Jun 29, 2015, at 11:39 AM, Chalamarla, Tirumalesh >> > > wrote: >> >>> >>> On Jun 29, 2015, at 10:52 AM, Marc Zyngier >> > wrote: >>> >>> On 29/06/15 18:38, Peter Maydell wrote: >>>> On 29 June 2015 at 18:30, Marc Zyngier >>> > wrote: >>>>> On 29/06/15 18:13, Chalamarla, Tirumalesh wrote: >>>>>> Will this also prevents migrating between same implementations, >>>>>> if no how is this identified. >>>>> >>>>> This shouldn't. It is pretty easy to look at the incoming guest's MIDR, >>>>> and verify that it matches the default MIDR on the receiving >>>>> system. Any >>>>> difference, and the migration should abort. >>>> >>>> Do you really want to forbid migration between (say) >>>> Cortex-A57 r3p0 and Cortex-A57 r3p1 ? >>>> >>>> That seems pretty harsh. >>> >>> I think we may need to allow for some flexibility (same major version >>> only, or +/- 1 minor version...). The idea I'm trying to convey is that >>> with "generic CPI", migration is not guaranteed unless we're on >>> extremely similar hardware. >>> >> yes, this is the point i am trying to make, we need some flexibility. >> so that it works with same chips with different passes may be. >> if we are allowing this, then we are not putting emulation as a >> requirement. >> >> Thanks, >> Tirumalesh. >> >>> M. >>> -- >>> Jazz is not dead. It just smells funny... > -- Jazz is not dead. It just smells funny...