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 Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6203C433F5 for ; Thu, 17 Feb 2022 04:59:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 405A3410AD; Wed, 16 Feb 2022 23:59:52 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com 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 cx-kZL5Hl9J4; Wed, 16 Feb 2022 23:59:51 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 043C4411D2; Wed, 16 Feb 2022 23:59:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B586C410AD for ; Wed, 16 Feb 2022 23:59:49 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu 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 1y6knjFNyaul for ; Wed, 16 Feb 2022 23:59:48 -0500 (EST) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id A78F0407EB for ; Wed, 16 Feb 2022 23:59:48 -0500 (EST) Received: by mail-io1-f53.google.com with SMTP id h16so2306707iol.11 for ; Wed, 16 Feb 2022 20:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=F7h05wJLlkd5cKPCrzT5cmv+Gs51c7pMwjtMHfEasy8=; b=JeRwhXto1AsObhVRUTqwhjiMHOtxzAZCvjPiDir8xsxC01QcimY1dXl70Z5Wao8BVy NIaFrKXr6LoAR8WwPkaseSWuc0MTYkFRvLt6jqD7jLAG5wjWFKHaHJZvSqYEXXX4TN/X wLstHHhAZIb41vrH4vf4MioIctOJQvHjp8JkOvT6UhVEVUhoTcBhskhQsCmR1gpEXkP6 JGFDDh115Bov9D32ORFPDVhqfVJdbcaF5U8ptNt2RneMpFE7y4a5egZfR/eepqECcGTK tYjMcmuaTg0TkM3iqvWtY6+j9AK3TTbtYnh4EuyLjRt8RcRxXTgBBYW0U168NMCbM0eu 1ktA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=F7h05wJLlkd5cKPCrzT5cmv+Gs51c7pMwjtMHfEasy8=; b=dS/FlLXJ9DaQB4M8qZ3h+ATXTOpQIeDQhvlfyW+6FJZ8TroivJYYHR5DRtCmfunF/l sF8FtJnHZe7+29n8sEIc5W/lg9FatjHoXx2PJDhjAnnhGpEGRFfvgBUQoS6a0Ig23KnP g5ZuGl25AW7nuldHHdXiigesj4FKQP94SkO+vh4OrMmIKoyriyDUFH4vgaT4Dofdfe58 LkymoDDslUr3cntIJbcO/VAiDWzDfgUeJfz3iSCNH0cXI7N8ZjN+kv8el2fhH8UUp5kl OecKL1Atj3l0pOBR0+IsKHtSrVDV43hjAD5WbQxlr+XAl31LWmbnLx0Rr88QZmLJydrd u4jw== X-Gm-Message-State: AOAM532D8Swb77rsN2Fl+vB20YjJEm1ZwJPVxU4dj2LMFSCqLvyKhLFx e0U4QK0kSjsjPc4BtZ0gn51e7w== X-Google-Smtp-Source: ABdhPJx2e0ngpL2dFp+kkfoL+F8ZeH+ZJbcUKIqGmyMNbZeBoGfK83hrgWHAGj8Qc1/3NWtu4Ct5Wg== X-Received: by 2002:a05:6638:1315:b0:314:85c1:f99b with SMTP id r21-20020a056638131500b0031485c1f99bmr760926jad.269.1645073987780; Wed, 16 Feb 2022 20:59:47 -0800 (PST) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id k2sm1418207iow.7.2022.02.16.20.59.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 20:59:47 -0800 (PST) Date: Thu, 17 Feb 2022 04:59:43 +0000 From: Oliver Upton To: Reiji Watanabe Subject: Re: [PATCH v5 10/27] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest Message-ID: References: <20220214065746.1230608-1-reijiw@google.com> <20220214065746.1230608-11-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Will Deacon , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, Linux ARM X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Tue, Feb 15, 2022 at 06:52:27PM -0800, Reiji Watanabe wrote: > Hi Oliver, > > Thank you for the review! > > On Tue, Feb 15, 2022 at 10:57 AM Oliver Upton wrote: > > > > Hi Reiji, > > > > On Sun, Feb 13, 2022 at 10:57:29PM -0800, Reiji Watanabe wrote: > > > When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf, which > > > means IMPLEMENTATION DEFINED PMU supported, KVM unconditionally > > > expose the value for the guest as it is. Since KVM doesn't support > > > IMPLEMENTATION DEFINED PMU for the guest, in that case KVM should > > > expose 0x0 (PMU is not implemented) instead. > > > > > > Change cpuid_feature_cap_perfmon_field() to update the field value > > > to 0x0 when it is 0xf. > > > > Definitely agree with the change in this patch. Do we need to tolerate > > writes of 0xf for ABI compatibility (even if it is nonsensical)? > > Otherwise a guest with IMP_DEF PMU cannot be migrated to a newer kernel. > > Hmm, yes, I think KVM should tolerate writes of 0xf so that we can > avoid the migration failure. I will make this change in v6. > > Since ID registers are immutable with the current KVM, I think a live > migration failure to a newer kernel happens when the newer kernel/KVM > supports more CPU features (or when an ID register field is newly > masked or capped by KVM, etc). So, I would assume such migration > breakage on KVM/ARM has been introduced from time to time though. > Indeed it has, but IMO migration breakage should really be avoided at all costs. End of the day, its ABI breakage. Unless folks feel otherwise, I would be in favor of just ignoring the IMP_DEF write and setting the field value to NI instead. Allows VMs to migrate onto newer kernels and fixes the KVM bug at the same time. -- Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B9720C433F5 for ; Thu, 17 Feb 2022 05:01:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=x5fdzwWt0FqCusImKXl8dB2T0kE5WRHXAvhkdtgGYGw=; b=nf+Zfx673wmlmQ 9keMnQ1bT+Y8SpE5oB5yYWOIR8tM2NCiE80B5XnWYTr9QB81uiZcVQsdJiTdG16lyj+6uOzcvfv9h PQB38gN3Bs8oFwIsKxrbBXOdG57UaFN95AUL+JDp0/Iol/QB3AtgiQmKrfjJbjn8zHb991tlvsB9G AOAaErYyD3G5U1Q9v7BkD6iVLGsh3TLn8TzYvcEaBEUFC2/+kQOfvWtGPVlGe9sK+4CzgYPGeZiIA Kl3YAHs9Mqq5fUz3F+KWjIVSYpFu9WMdvJ5O2p5h5WhfuzrK1XCER6J77CpB/ccI75TiqSvqkogGl uD5YIjKWnmrqnknTO2ow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKYtV-008yjm-BC; Thu, 17 Feb 2022 04:59:53 +0000 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKYtR-008yis-7U for linux-arm-kernel@lists.infradead.org; Thu, 17 Feb 2022 04:59:50 +0000 Received: by mail-io1-xd2c.google.com with SMTP id y20so2360556iod.1 for ; Wed, 16 Feb 2022 20:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=F7h05wJLlkd5cKPCrzT5cmv+Gs51c7pMwjtMHfEasy8=; b=JeRwhXto1AsObhVRUTqwhjiMHOtxzAZCvjPiDir8xsxC01QcimY1dXl70Z5Wao8BVy NIaFrKXr6LoAR8WwPkaseSWuc0MTYkFRvLt6jqD7jLAG5wjWFKHaHJZvSqYEXXX4TN/X wLstHHhAZIb41vrH4vf4MioIctOJQvHjp8JkOvT6UhVEVUhoTcBhskhQsCmR1gpEXkP6 JGFDDh115Bov9D32ORFPDVhqfVJdbcaF5U8ptNt2RneMpFE7y4a5egZfR/eepqECcGTK tYjMcmuaTg0TkM3iqvWtY6+j9AK3TTbtYnh4EuyLjRt8RcRxXTgBBYW0U168NMCbM0eu 1ktA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=F7h05wJLlkd5cKPCrzT5cmv+Gs51c7pMwjtMHfEasy8=; b=KTv5+C4PjbNoBqFqRBGKBbJFEFnuc3kAMOA0C1OeVX0f4kGXPBRmWGiJ7pTfuHMu9B /3QDd0X8yYU2ZmEjkFsIn1ZbHTS2JcbhOy6IUeeWoh7rhAL4apYzLUr9u12Io7Uul/Ei 2T5sF4fVRTrtt/VLOcqsmcOKkfQmHdDOrxFHy0Nvt52m0P3720d/7kr6uh9dbQ9w2KzS 32TGKqn8hKvfGCN6IFkzvfPJk5dGARa3pAaonEbzPUFCinkMMZLOlNm4v7MayIptNtkK Dh3zLvxnRWkCM100NErLyf1RaN0YCUe2sp7Q/Ty9Za9M5jfAR3uy3mwnph0uG1bdzzv/ 4hBA== X-Gm-Message-State: AOAM530RWPmd8As/BDpc3N3go6tHGbmr0rIQxOWOVPz/2J00z38GWB5s Ia4CrdYQhxuulGHLIL86Bv89LA== X-Google-Smtp-Source: ABdhPJx2e0ngpL2dFp+kkfoL+F8ZeH+ZJbcUKIqGmyMNbZeBoGfK83hrgWHAGj8Qc1/3NWtu4Ct5Wg== X-Received: by 2002:a05:6638:1315:b0:314:85c1:f99b with SMTP id r21-20020a056638131500b0031485c1f99bmr760926jad.269.1645073987780; Wed, 16 Feb 2022 20:59:47 -0800 (PST) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id k2sm1418207iow.7.2022.02.16.20.59.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 20:59:47 -0800 (PST) Date: Thu, 17 Feb 2022 04:59:43 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Fuad Tabba , Peng Liang , Peter Shier , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v5 10/27] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest Message-ID: References: <20220214065746.1230608-1-reijiw@google.com> <20220214065746.1230608-11-reijiw@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220216_205949_294322_E90413E2 X-CRM114-Status: GOOD ( 25.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 15, 2022 at 06:52:27PM -0800, Reiji Watanabe wrote: > Hi Oliver, > > Thank you for the review! > > On Tue, Feb 15, 2022 at 10:57 AM Oliver Upton wrote: > > > > Hi Reiji, > > > > On Sun, Feb 13, 2022 at 10:57:29PM -0800, Reiji Watanabe wrote: > > > When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf, which > > > means IMPLEMENTATION DEFINED PMU supported, KVM unconditionally > > > expose the value for the guest as it is. Since KVM doesn't support > > > IMPLEMENTATION DEFINED PMU for the guest, in that case KVM should > > > expose 0x0 (PMU is not implemented) instead. > > > > > > Change cpuid_feature_cap_perfmon_field() to update the field value > > > to 0x0 when it is 0xf. > > > > Definitely agree with the change in this patch. Do we need to tolerate > > writes of 0xf for ABI compatibility (even if it is nonsensical)? > > Otherwise a guest with IMP_DEF PMU cannot be migrated to a newer kernel. > > Hmm, yes, I think KVM should tolerate writes of 0xf so that we can > avoid the migration failure. I will make this change in v6. > > Since ID registers are immutable with the current KVM, I think a live > migration failure to a newer kernel happens when the newer kernel/KVM > supports more CPU features (or when an ID register field is newly > masked or capped by KVM, etc). So, I would assume such migration > breakage on KVM/ARM has been introduced from time to time though. > Indeed it has, but IMO migration breakage should really be avoided at all costs. End of the day, its ABI breakage. Unless folks feel otherwise, I would be in favor of just ignoring the IMP_DEF write and setting the field value to NI instead. Allows VMs to migrate onto newer kernels and fixes the KVM bug at the same time. -- Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67C83C433EF for ; Thu, 17 Feb 2022 04:59:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229843AbiBQFAE (ORCPT ); Thu, 17 Feb 2022 00:00:04 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbiBQFAD (ORCPT ); Thu, 17 Feb 2022 00:00:03 -0500 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACBA82A5237 for ; Wed, 16 Feb 2022 20:59:48 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id e79so2306196iof.13 for ; Wed, 16 Feb 2022 20:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=F7h05wJLlkd5cKPCrzT5cmv+Gs51c7pMwjtMHfEasy8=; b=JeRwhXto1AsObhVRUTqwhjiMHOtxzAZCvjPiDir8xsxC01QcimY1dXl70Z5Wao8BVy NIaFrKXr6LoAR8WwPkaseSWuc0MTYkFRvLt6jqD7jLAG5wjWFKHaHJZvSqYEXXX4TN/X wLstHHhAZIb41vrH4vf4MioIctOJQvHjp8JkOvT6UhVEVUhoTcBhskhQsCmR1gpEXkP6 JGFDDh115Bov9D32ORFPDVhqfVJdbcaF5U8ptNt2RneMpFE7y4a5egZfR/eepqECcGTK tYjMcmuaTg0TkM3iqvWtY6+j9AK3TTbtYnh4EuyLjRt8RcRxXTgBBYW0U168NMCbM0eu 1ktA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=F7h05wJLlkd5cKPCrzT5cmv+Gs51c7pMwjtMHfEasy8=; b=AxC9Kk5bQcjdNSvyFr5wCvSoctTkKVy8MFqjRCMqqs56okLyYmc6PUdXUEN5FOiu31 6xeWvKmG2UtSqv8JFLTYjgN5oK2B/LzmJE3nMe2XAaR3etY4p3kcKipfuKlVIMw9DaSF DE4syNCGkvY12j1LIhvuBO41COnS5D6YFpg3BQU0G8Uz9XEv+aUc2tgxaxGkihYqkglR Kh5tlYVBRne4Wt6owvQYKeZdibzfSzj1GpHUgmjk0aCKAHet24JA0Zge1vUUV0rSu3I4 m73PS1QvZ+nBfX5oiCVhX4lVD0C8ii8TAIKwwgahxQ+ML4Nmvu7AAYF+H8G/JejQ+CB4 wbuA== X-Gm-Message-State: AOAM531rwS/Au+iVXKgVXJSKirPb23S6BSNyyKOZT9v5S5iDSdfHUGsk EndZSuIEmQVz4VPgpXTYsMHCKg== X-Google-Smtp-Source: ABdhPJx2e0ngpL2dFp+kkfoL+F8ZeH+ZJbcUKIqGmyMNbZeBoGfK83hrgWHAGj8Qc1/3NWtu4Ct5Wg== X-Received: by 2002:a05:6638:1315:b0:314:85c1:f99b with SMTP id r21-20020a056638131500b0031485c1f99bmr760926jad.269.1645073987780; Wed, 16 Feb 2022 20:59:47 -0800 (PST) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id k2sm1418207iow.7.2022.02.16.20.59.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 20:59:47 -0800 (PST) Date: Thu, 17 Feb 2022 04:59:43 +0000 From: Oliver Upton To: Reiji Watanabe Cc: Marc Zyngier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Will Deacon , Andrew Jones , Fuad Tabba , Peng Liang , Peter Shier , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata Subject: Re: [PATCH v5 10/27] KVM: arm64: Hide IMPLEMENTATION DEFINED PMU support for the guest Message-ID: References: <20220214065746.1230608-1-reijiw@google.com> <20220214065746.1230608-11-reijiw@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Feb 15, 2022 at 06:52:27PM -0800, Reiji Watanabe wrote: > Hi Oliver, > > Thank you for the review! > > On Tue, Feb 15, 2022 at 10:57 AM Oliver Upton wrote: > > > > Hi Reiji, > > > > On Sun, Feb 13, 2022 at 10:57:29PM -0800, Reiji Watanabe wrote: > > > When ID_AA64DFR0_EL1.PMUVER or ID_DFR0_EL1.PERFMON is 0xf, which > > > means IMPLEMENTATION DEFINED PMU supported, KVM unconditionally > > > expose the value for the guest as it is. Since KVM doesn't support > > > IMPLEMENTATION DEFINED PMU for the guest, in that case KVM should > > > expose 0x0 (PMU is not implemented) instead. > > > > > > Change cpuid_feature_cap_perfmon_field() to update the field value > > > to 0x0 when it is 0xf. > > > > Definitely agree with the change in this patch. Do we need to tolerate > > writes of 0xf for ABI compatibility (even if it is nonsensical)? > > Otherwise a guest with IMP_DEF PMU cannot be migrated to a newer kernel. > > Hmm, yes, I think KVM should tolerate writes of 0xf so that we can > avoid the migration failure. I will make this change in v6. > > Since ID registers are immutable with the current KVM, I think a live > migration failure to a newer kernel happens when the newer kernel/KVM > supports more CPU features (or when an ID register field is newly > masked or capped by KVM, etc). So, I would assume such migration > breakage on KVM/ARM has been introduced from time to time though. > Indeed it has, but IMO migration breakage should really be avoided at all costs. End of the day, its ABI breakage. Unless folks feel otherwise, I would be in favor of just ignoring the IMP_DEF write and setting the field value to NI instead. Allows VMs to migrate onto newer kernels and fixes the KVM bug at the same time. -- Oliver