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 7625BC433EF for ; Tue, 5 Apr 2022 01:46:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DCF904B1C7; Mon, 4 Apr 2022 21:46:55 -0400 (EDT) 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 Q-L57SbVDCKy; Mon, 4 Apr 2022 21:46:54 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D68D74B0D0; Mon, 4 Apr 2022 21:46:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B2C134B0BD for ; Mon, 4 Apr 2022 21:46:53 -0400 (EDT) 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 D1nZVu81jeJT for ; Mon, 4 Apr 2022 21:46:52 -0400 (EDT) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id A66F84B0B6 for ; Mon, 4 Apr 2022 21:46:52 -0400 (EDT) Received: by mail-pj1-f54.google.com with SMTP id ku13-20020a17090b218d00b001ca8fcd3adeso1076212pjb.2 for ; Mon, 04 Apr 2022 18:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5/ENKPwEE0XsowuVbAwYwEQbZbBA4Wrsv1B56cUOhLw=; b=nsiMnTnbPhcHABw79aFqyBZ52gouWySQb6b1zd/6RuyHX6qu73aXxT51uGKKKoUFCq j0Ntp5j3lq7wl3WQLkxUzU4TP7IL1XWp62PZglt+kE30WJI06gMGKc3zXkHK4pUvQhX5 FeNlAj47ZRvz7WWAzc21LhNTm/3Of2xMjtdLDhYJ0a7+Kg4y3UAZuxhLbCioOhPCCIDk ve6CW64McuhYSy5w9e1MKsGtIntlS2YUZmSSgvEjW5lrERmRgcXps9QhsQqCUzNp2TBB X2O+F7cDoZ4QCAf9UpkfOXMlxzobrkpcdzd2kwwZdkCGR57Ob40eopdLwj65gtU4QehD SNTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5/ENKPwEE0XsowuVbAwYwEQbZbBA4Wrsv1B56cUOhLw=; b=x9RU2+p08rSx8EROUqbF0miLQUWfW4V12UStvOWYn0E98iZ7dnQQpjuimFySR+MPQJ gX2+ghLYKCk2MonaB5M31vNDRCyZb6gJkYlwheVB8e3r6D22+KiVlPqcHkxRWgdbZa7K EpE0j45hZy8+qHrDUpJBEYpM0uLogZ9I90F9i+5RmI41PieydfRji6kZtG87v0xAsMF0 oJLt5PUWk5snEnpiiIrYzSSZdOGokY70AbxiYQZ+p+8x1U6ZpUUBkXPXvhpkiN41GFqP HzD/Kh2i/LssZFtd0gDj6ee7AjI5sNtb2PMa8A39pR2X/kOpN6opUuticaImhkBcd3hP 10Ew== X-Gm-Message-State: AOAM5308Wvsi3O8Nm2KJeabbbQJCgFzR7mro5LmCmfP6zCYMaPkRs2rc RuM66G4C47mzM4zbFPf8zQFUSbuHzMs9ESdGyZ0c8Q== X-Google-Smtp-Source: ABdhPJwZdAVxNvvwelmoX0UfJB9QP/f71rA9aZ2+c9FFogDIIiR3+0GsySURpnJyc8i+/2rzWVAUXFRGTR5VQN4zqG8= X-Received: by 2002:a17:90a:b903:b0:1ca:be37:1d41 with SMTP id p3-20020a17090ab90300b001cabe371d41mr1258623pjr.9.1649123211375; Mon, 04 Apr 2022 18:46:51 -0700 (PDT) MIME-Version: 1.0 References: <20220401010832.3425787-1-oupton@google.com> <20220401010832.3425787-3-oupton@google.com> In-Reply-To: From: Reiji Watanabe Date: Mon, 4 Apr 2022 18:46:35 -0700 Message-ID: Subject: Re: [PATCH v2 2/3] KVM: arm64: Plumb cp10 ID traps through the AArch64 sysreg handler To: Oliver Upton Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , 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 Hi Oliver, On Mon, Apr 4, 2022 at 4:19 PM Oliver Upton wrote: > > On Mon, Apr 04, 2022 at 05:28:33AM +0000, Oliver Upton wrote: > > Hi Reiji, > > > > On Sun, Apr 03, 2022 at 08:57:47PM -0700, Reiji Watanabe wrote: > > > > +int kvm_handle_cp10_id(struct kvm_vcpu *vcpu) > > > > +{ > > > > + int Rt = kvm_vcpu_sys_get_rt(vcpu); > > > > + u32 esr = kvm_vcpu_get_esr(vcpu); > > > > + struct sys_reg_params params; > > > > + int ret; > > > > + > > > > + /* UNDEF on any unhandled register or an attempted write */ > > > > + if (!kvm_esr_cp10_id_to_sys64(esr, ¶ms) || params.is_write) { > > > > + kvm_inject_undefined(vcpu); > > > > > > Nit: For debugging, it might be more useful to use unhandled_cp_access() > > > (, which needs to be changed to support ESR_ELx_EC_CP10_ID though) > > > rather than directly calling kvm_inject_undefined(). > > > > A very worthy nit, you spotted my laziness in shunting straight to > > kvm_inject_undefined() :) > > > > Thinking about this a bit more deeply, this code should be dead. The > > only time either of these conditions would happen is on a broken > > implementation. Probably should still handle it gracefully in case the > > CP10 handling in KVM becomes (or is in my own patch!) busted. > > Actually, on second thought: any objections to leaving this as-is? > kvm_esr_cp10_id_to_sys64() spits out sys_reg_params that point at the > MRS alias for the VMRS register. Even if that call succeeds, the params > that get printed out by unhandled_cp_access() do not match the actual > register the guest was accessing. And if the call fails, ->Op2 is > uninitialized. I understand a few additional changes are needed for this. Or simply use WARN_ON_ONCE ? (since this cannot be created by the guest but by a KVM or CPU problem) I'm fine with the current code as-is though:) Thanks, Reiji _______________________________________________ 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 BBAB2C433F5 for ; Tue, 5 Apr 2022 01:48: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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=x3sQB0xu8mPclNANY94vXCCThGCJNq862vpTCtx/JEU=; b=u48/AwUM6cCubd jw/bDRfG5oKbeAVIdru/Pa5wfmxcP6En8dXVwn4uNVJXsr36E62DavJUtK2Ac1z14bN0PR4XhoD+O coAZ5XwpWMFYggZ5wqCKLc1hmZUIVlxdM7P/Fv/vUZ3Bj//xMP0FVRRtqdPmrTXhUaGG3jXksStb2 D6nVaM73rr/42hAaLDkmg2X4+g91vhw2L+RjIUQ4+nx6ZinWmhZHv0nGutFiip1ZNMREIpASFyUQe eJRWjMCXD4/jRVQ8Po2Oi3ev9QCC9WefBFOnr6agNzdO1wBXYJcZu5OHsIetAlnhfG+Phb69yBx/l mzg3zao7H7yAVhZEv7PA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbYHY-00Gopm-Jh; Tue, 05 Apr 2022 01:46:56 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbYHV-00GopJ-Ig for linux-arm-kernel@lists.infradead.org; Tue, 05 Apr 2022 01:46:54 +0000 Received: by mail-pj1-x102f.google.com with SMTP id m12-20020a17090b068c00b001cabe30a98dso1053032pjz.4 for ; Mon, 04 Apr 2022 18:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5/ENKPwEE0XsowuVbAwYwEQbZbBA4Wrsv1B56cUOhLw=; b=nsiMnTnbPhcHABw79aFqyBZ52gouWySQb6b1zd/6RuyHX6qu73aXxT51uGKKKoUFCq j0Ntp5j3lq7wl3WQLkxUzU4TP7IL1XWp62PZglt+kE30WJI06gMGKc3zXkHK4pUvQhX5 FeNlAj47ZRvz7WWAzc21LhNTm/3Of2xMjtdLDhYJ0a7+Kg4y3UAZuxhLbCioOhPCCIDk ve6CW64McuhYSy5w9e1MKsGtIntlS2YUZmSSgvEjW5lrERmRgcXps9QhsQqCUzNp2TBB X2O+F7cDoZ4QCAf9UpkfOXMlxzobrkpcdzd2kwwZdkCGR57Ob40eopdLwj65gtU4QehD SNTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5/ENKPwEE0XsowuVbAwYwEQbZbBA4Wrsv1B56cUOhLw=; b=U7BNtpFqXIQQ5q6wCxFCS956K0rm9FxP8nBkGe9cohOIitT9T1ji7vWXZzyWY40Gkw hJw2nqS/5WX6vzct/rw+jnAieHr5PiWd7XICx/G9hZUgXPwYTCAkzloRaDDFeLbVQaol IXFJtrQ+CN4bKnwRbOosdRB5hOr11Wf5hXgHpVl/EsoN6Jtni/4BIBt9Ntq7DOPlWz0J Q88gJp/HGidrebU97xnF/kCWz3NGcmn7pTXsbdMs1fGukUDoA+xZCMlIO6ENp40IKtFN BxiSw5nvuTUaFpwSeho2kOdgruG6HhqEXRmy029axSk2dN2cdSzNgCtDw0tuQo/YOyW3 wDlA== X-Gm-Message-State: AOAM530Pc40DTbISubx5P9JlN3k+44WHUGq9tVQTHfRmhWkGeB8T03dK rFwDTj7aQmrJDz+6gm9GlqQBdM0sFi1KCQp1FXCTJA== X-Google-Smtp-Source: ABdhPJwZdAVxNvvwelmoX0UfJB9QP/f71rA9aZ2+c9FFogDIIiR3+0GsySURpnJyc8i+/2rzWVAUXFRGTR5VQN4zqG8= X-Received: by 2002:a17:90a:b903:b0:1ca:be37:1d41 with SMTP id p3-20020a17090ab90300b001cabe371d41mr1258623pjr.9.1649123211375; Mon, 04 Apr 2022 18:46:51 -0700 (PDT) MIME-Version: 1.0 References: <20220401010832.3425787-1-oupton@google.com> <20220401010832.3425787-3-oupton@google.com> In-Reply-To: From: Reiji Watanabe Date: Mon, 4 Apr 2022 18:46:35 -0700 Message-ID: Subject: Re: [PATCH v2 2/3] KVM: arm64: Plumb cp10 ID traps through the AArch64 sysreg handler To: Oliver Upton Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Linux ARM , Peter Shier , Ricardo Koller X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220404_184653_655822_9E13BAB0 X-CRM114-Status: GOOD ( 24.42 ) 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 Hi Oliver, On Mon, Apr 4, 2022 at 4:19 PM Oliver Upton wrote: > > On Mon, Apr 04, 2022 at 05:28:33AM +0000, Oliver Upton wrote: > > Hi Reiji, > > > > On Sun, Apr 03, 2022 at 08:57:47PM -0700, Reiji Watanabe wrote: > > > > +int kvm_handle_cp10_id(struct kvm_vcpu *vcpu) > > > > +{ > > > > + int Rt = kvm_vcpu_sys_get_rt(vcpu); > > > > + u32 esr = kvm_vcpu_get_esr(vcpu); > > > > + struct sys_reg_params params; > > > > + int ret; > > > > + > > > > + /* UNDEF on any unhandled register or an attempted write */ > > > > + if (!kvm_esr_cp10_id_to_sys64(esr, ¶ms) || params.is_write) { > > > > + kvm_inject_undefined(vcpu); > > > > > > Nit: For debugging, it might be more useful to use unhandled_cp_access() > > > (, which needs to be changed to support ESR_ELx_EC_CP10_ID though) > > > rather than directly calling kvm_inject_undefined(). > > > > A very worthy nit, you spotted my laziness in shunting straight to > > kvm_inject_undefined() :) > > > > Thinking about this a bit more deeply, this code should be dead. The > > only time either of these conditions would happen is on a broken > > implementation. Probably should still handle it gracefully in case the > > CP10 handling in KVM becomes (or is in my own patch!) busted. > > Actually, on second thought: any objections to leaving this as-is? > kvm_esr_cp10_id_to_sys64() spits out sys_reg_params that point at the > MRS alias for the VMRS register. Even if that call succeeds, the params > that get printed out by unhandled_cp_access() do not match the actual > register the guest was accessing. And if the call fails, ->Op2 is > uninitialized. I understand a few additional changes are needed for this. Or simply use WARN_ON_ONCE ? (since this cannot be created by the guest but by a KVM or CPU problem) I'm fine with the current code as-is though:) Thanks, Reiji _______________________________________________ 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 33400C433F5 for ; Tue, 5 Apr 2022 02:39:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229964AbiDEClu (ORCPT ); Mon, 4 Apr 2022 22:41:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229987AbiDECln (ORCPT ); Mon, 4 Apr 2022 22:41:43 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FF87C9B7C for ; Mon, 4 Apr 2022 18:46:52 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id n18so9651234plg.5 for ; Mon, 04 Apr 2022 18:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5/ENKPwEE0XsowuVbAwYwEQbZbBA4Wrsv1B56cUOhLw=; b=nsiMnTnbPhcHABw79aFqyBZ52gouWySQb6b1zd/6RuyHX6qu73aXxT51uGKKKoUFCq j0Ntp5j3lq7wl3WQLkxUzU4TP7IL1XWp62PZglt+kE30WJI06gMGKc3zXkHK4pUvQhX5 FeNlAj47ZRvz7WWAzc21LhNTm/3Of2xMjtdLDhYJ0a7+Kg4y3UAZuxhLbCioOhPCCIDk ve6CW64McuhYSy5w9e1MKsGtIntlS2YUZmSSgvEjW5lrERmRgcXps9QhsQqCUzNp2TBB X2O+F7cDoZ4QCAf9UpkfOXMlxzobrkpcdzd2kwwZdkCGR57Ob40eopdLwj65gtU4QehD SNTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5/ENKPwEE0XsowuVbAwYwEQbZbBA4Wrsv1B56cUOhLw=; b=iegfdDmUG7HzkNQwbB5X1cNxLBkEyR67h5ZXUkHkRQ/acUFeZA9zt4Cj5YM3cuLCJ7 vH/NJ4ph1FtQGxRg8JSgHxup1b06jJDJAlaJQ2/31gwn7hhRtil+olZbYHRq8y/EjlxA id/x5OmG06fc1gxGXlQ/od3Gd3dZ2f+OVqlQa1CRGbctjY9wbV6HdoLU8wPJcWlABMCO BwITGqXgouvlDA2GQ6Oeh2QFQVtPZzXl2zDaJBNb7moBjMgx4TI2Nj3YZShfYLrzArcJ 2U4EzbyLZl26Qh4nQr5i2LivXvHyjYYRuWrngur5QFY4JCZF6eAmX9/cdc1MEG7LGeGc UfAg== X-Gm-Message-State: AOAM5309ljbQm7ytMpsXe4AE2Q1XMK/ke9dM/lEshByLyCeoeK8fm3g1 9ChvYFijwk0YLFcj8faR0swe6RqzghmwHPlqNf3cdQ== X-Google-Smtp-Source: ABdhPJwZdAVxNvvwelmoX0UfJB9QP/f71rA9aZ2+c9FFogDIIiR3+0GsySURpnJyc8i+/2rzWVAUXFRGTR5VQN4zqG8= X-Received: by 2002:a17:90a:b903:b0:1ca:be37:1d41 with SMTP id p3-20020a17090ab90300b001cabe371d41mr1258623pjr.9.1649123211375; Mon, 04 Apr 2022 18:46:51 -0700 (PDT) MIME-Version: 1.0 References: <20220401010832.3425787-1-oupton@google.com> <20220401010832.3425787-3-oupton@google.com> In-Reply-To: From: Reiji Watanabe Date: Mon, 4 Apr 2022 18:46:35 -0700 Message-ID: Subject: Re: [PATCH v2 2/3] KVM: arm64: Plumb cp10 ID traps through the AArch64 sysreg handler To: Oliver Upton Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Linux ARM , Peter Shier , Ricardo Koller Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Oliver, On Mon, Apr 4, 2022 at 4:19 PM Oliver Upton wrote: > > On Mon, Apr 04, 2022 at 05:28:33AM +0000, Oliver Upton wrote: > > Hi Reiji, > > > > On Sun, Apr 03, 2022 at 08:57:47PM -0700, Reiji Watanabe wrote: > > > > +int kvm_handle_cp10_id(struct kvm_vcpu *vcpu) > > > > +{ > > > > + int Rt = kvm_vcpu_sys_get_rt(vcpu); > > > > + u32 esr = kvm_vcpu_get_esr(vcpu); > > > > + struct sys_reg_params params; > > > > + int ret; > > > > + > > > > + /* UNDEF on any unhandled register or an attempted write */ > > > > + if (!kvm_esr_cp10_id_to_sys64(esr, ¶ms) || params.is_write) { > > > > + kvm_inject_undefined(vcpu); > > > > > > Nit: For debugging, it might be more useful to use unhandled_cp_access() > > > (, which needs to be changed to support ESR_ELx_EC_CP10_ID though) > > > rather than directly calling kvm_inject_undefined(). > > > > A very worthy nit, you spotted my laziness in shunting straight to > > kvm_inject_undefined() :) > > > > Thinking about this a bit more deeply, this code should be dead. The > > only time either of these conditions would happen is on a broken > > implementation. Probably should still handle it gracefully in case the > > CP10 handling in KVM becomes (or is in my own patch!) busted. > > Actually, on second thought: any objections to leaving this as-is? > kvm_esr_cp10_id_to_sys64() spits out sys_reg_params that point at the > MRS alias for the VMRS register. Even if that call succeeds, the params > that get printed out by unhandled_cp_access() do not match the actual > register the guest was accessing. And if the call fails, ->Op2 is > uninitialized. I understand a few additional changes are needed for this. Or simply use WARN_ON_ONCE ? (since this cannot be created by the guest but by a KVM or CPU problem) I'm fine with the current code as-is though:) Thanks, Reiji