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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EDD9C4BA0E for ; Thu, 27 Feb 2020 00:22:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D1F521D7E for ; Thu, 27 Feb 2020 00:22:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QwvsLqWM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728018AbgB0AWp (ORCPT ); Wed, 26 Feb 2020 19:22:45 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:36906 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727987AbgB0AWp (ORCPT ); Wed, 26 Feb 2020 19:22:45 -0500 Received: by mail-lj1-f194.google.com with SMTP id q23so1241419ljm.4 for ; Wed, 26 Feb 2020 16:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IyMTMGg9qSQuPJl52d443YEIDtTm0XZjcRQmq1/vbRA=; b=QwvsLqWMae8znfjZZJMBhS8m6ZCGFux9CEaI48MtozDXC0VwHJuuaofy6D+Hc11xvh Fz1AEn8bt7iCoxNiZDBAKLPCakpXQBMieL2zRfS74t9eYbe0ME7CIfcY8GLZufEiaNZU j2mF0vtEd8wiSSFQySq/09aZ/9PGK5SBGizd/n3j4kJwucxw/U9GOvoc7s75srHSrYZa GYbEZ+KBVQiBbjxh5VbA95/ykW69XNHRt5b7QoqT0cK08nP/dKEZpbDiCSbE84mc0ees heKi+wCn2OsbOp38S7FCGbodrS+ATU/tiapzeIthvfvXPERjxXboa7M9xjFU5h57/Vos Htmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IyMTMGg9qSQuPJl52d443YEIDtTm0XZjcRQmq1/vbRA=; b=rpG95MA/3IF/skVqTJOfbBqluygA2yFEvzbirgGFBw6xvPgyBVeGkIMHXhO1SXOWUb FJmpxfuWVhPTEEWl6LFDVt02j2BdRZooQhpYrqAh+xewIVPclzzQTjMTrVRRjiEN00tw YDFBU0L1Fjhqyg9sz76D+VR30eQUloOqom+2fPf5hRthz7c025is6Oon9f2TeqdF4V9/ vJS3NMsXcla5FDtgzelEaSGqI/CxmE0a1mt+yLpEuQ6/osAZUd3KHV5GrkXDm2GF4nk7 XD1SoDg/CkvYv1nNK/1Zi9jlp9lu2ivzQjoZQIkwWF9LIqdcD6zZ0thpnz37n2VpcArL OqIg== X-Gm-Message-State: ANhLgQ2lXzytvmWrNvC1T3WIKp2DBKc35ujF475p6UXn5Lue99zLvdaC lu9Zc25nK6xL/OrVJ4SCB4nA2HjTzaJQiMgcM2Fb3A== X-Google-Smtp-Source: ADFU+vvKha2nMpHbQ/3UrIlL2h8uvZNejW76k/ukKlnxhJDtEmiDks83eLjFtMxqWe9fAi3rXMq+bLvHzddjG63owhU= X-Received: by 2002:a2e:3608:: with SMTP id d8mr993106lja.152.1582762960291; Wed, 26 Feb 2020 16:22:40 -0800 (PST) MIME-Version: 1.0 References: <20200207103608.110305-1-oupton@google.com> <045fcfb5-8578-ad22-7c3e-6bbf20c4ea35@redhat.com> In-Reply-To: <045fcfb5-8578-ad22-7c3e-6bbf20c4ea35@redhat.com> From: Oliver Upton Date: Wed, 26 Feb 2020 16:22:29 -0800 Message-ID: Subject: Re: [PATCH v3 0/5] Handle monitor trap flag during instruction emulation To: Paolo Bonzini Cc: kvm list , Jim Mattson , Peter Shier , Sean Christopherson Content-Type: text/plain; charset="UTF-8" Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Feb 12, 2020 at 3:34 AM Paolo Bonzini wrote: > > On 07/02/20 11:36, Oliver Upton wrote: > > v1: http://lore.kernel.org/r/20200113221053.22053-1-oupton@google.com > > v2: http://lore.kernel.org/r/20200128092715.69429-1-oupton@google.com > > > > v1 => v2: > > - Don't split the #DB delivery by vendors. Unconditionally injecting > > #DB payloads into the 'pending debug exceptions' field will cause KVM > > to get stuck in a loop. Per the SDM, when hardware injects an event > > resulting from this field's value, it is checked against the > > exception interception bitmap. > > - Address Sean's comments by injecting the VM-exit into L1 from > > vmx_check_nested_events(). > > - Added fix for nested INIT VM-exits + 'pending debug exceptions' field > > as it was noticed in implementing v2. > > - Drop Peter + Jim's Reviewed-by tags, as the patch set has changed > > since v1. > > > > v2 => v3: > > - Merge the check/set_pending_dbg helpers into a single helper, > > vmx_update_pending_dbg(). Add clarifying comment to this helper. > > - Rewrite commit message, descriptive comment for change in 3/5 to > > explicitly describe the reason for mutating payload delivery > > behavior. > > - Undo the changes to kvm_vcpu_do_singlestep(). Instead, add a new hook > > to call for 'full' instruction emulation + 'fast' emulation. > > > > KVM already provides guests the ability to use the 'monitor trap flag' > > VM-execution control. Support for this flag is provided by the fact that > > KVM unconditionally forwards MTF VM-exits to the guest (if requested), > > as KVM doesn't utilize MTF. While this provides support during hardware > > instruction execution, it is insufficient for instruction emulation. > > > > Should L0 emulate an instruction on the behalf of L2, L0 should also > > synthesize an MTF VM-exit into L1, should control be set. > > > > The first patch corrects a nuanced difference between the definition of > > a #DB exception payload field and DR6 register. Mask off bit 12 which is > > defined in the 'pending debug exceptions' field when applying to DR6, > > since the payload field is said to be compatible with the aforementioned > > VMCS field. > > > > The second patch sets the 'pending debug exceptions' VMCS field when > > delivering an INIT signal VM-exit to L1, as described in the SDM. This > > patch also introduces helpers for setting the 'pending debug exceptions' > > VMCS field. > > > > The third patch massages KVM's handling of exception payloads with > > regard to API compatibility. Rather than immediately delivering the > > payload w/o opt-in, instead defer the payload + inject > > before completing a KVM_GET_VCPU_EVENTS. This maintains API > > compatibility whilst correcting #DB behavior with regard to higher > > priority VM-exit events. > > > > Fourth patch introduces MTF implementation for emulated instructions. > > Identify if an MTF is due on an instruction boundary from > > kvm_vcpu_do_singlestep(), however only deliver this VM-exit from > > vmx_check_nested_events() to respect the relative prioritization to > > other VM-exits. Since this augments the nested state, introduce a new > > flag for (de)serialization. > > > > Last patch adds tests to kvm-unit-tests to assert the correctness of MTF > > under several conditions (concurrent #DB trap, #DB fault, etc). These > > tests pass under virtualization with this series as well as on > > bare-metal. > > > > Based on commit 2c2787938512 ("KVM: selftests: Stop memslot creation in > > KVM internal memslot region"). > > > > Oliver Upton (4): > > KVM: x86: Mask off reserved bit from #DB exception payload > > KVM: nVMX: Handle pending #DB when injecting INIT VM-exit > > KVM: x86: Deliver exception payload on KVM_GET_VCPU_EVENTS > > KVM: nVMX: Emulate MTF when performing instruction emulation > > > > arch/x86/include/asm/kvm_host.h | 1 + > > arch/x86/include/uapi/asm/kvm.h | 1 + > > arch/x86/kvm/svm.c | 1 + > > arch/x86/kvm/vmx/nested.c | 54 ++++++++++++++++++++++++++++++++- > > arch/x86/kvm/vmx/nested.h | 5 +++ > > arch/x86/kvm/vmx/vmx.c | 37 +++++++++++++++++++++- > > arch/x86/kvm/vmx/vmx.h | 3 ++ > > arch/x86/kvm/x86.c | 39 ++++++++++++++++-------- > > 8 files changed, 126 insertions(+), 15 deletions(-) > > > > Queued (for 5.6-rc2), thanks. > > Paolo > Are there any strong opinions about how the newly introduced nested state should be handled across live migrations? When applying this patch set internally I realized live migration would be busted in the case of a kernel rollback (i.e. a kernel with this patchset emits the nested state, kernel w/o receives it + refuses). Easy fix is to only turn on the feature once it is rollback-proof, but I wonder if there is any room for improvement on this topic.. -- Thanks, Oliver