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 CE138C3A59F for ; Mon, 26 Aug 2019 22:39:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B3562173E for ; Mon, 26 Aug 2019 22:39:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ARF98h46" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727058AbfHZWjG (ORCPT ); Mon, 26 Aug 2019 18:39:06 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:44396 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726278AbfHZWjG (ORCPT ); Mon, 26 Aug 2019 18:39:06 -0400 Received: by mail-io1-f67.google.com with SMTP id j4so33113840iog.11 for ; Mon, 26 Aug 2019 15:39:05 -0700 (PDT) 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:content-transfer-encoding; bh=vj/S7jjU3jKgz2U6enZ47KqQXxikDOW/jPjW399kyoI=; b=ARF98h46F8hh8FwqXVk3FW5RpGS3C8xLe5uDOIMF0/zLBZiHiMMBET3go9L9Ei9FGV oJ7t6gxblz6nNUwYfdIFIdglH9eogyzpmqjnW3sVCnM3U0PjaXpHoAECOStbd3YLRgkB NuU6Ph+If4flYXB6c+546VO57oCKHIABwRlF00bu/4BXZwhPieVg1bLnbs8WM3rfON/B aKH65KkNYnYQTW6Y2Z2J54j6atwdY0/dVq9hgjtBk5SPg3AQYx7jVUSjURNxnc+YBj93 Lz19jTSTwS1MhWd6FhIfxgNoOsjlBq4AadttmwRwUjtkjePH4wPniZIl/ETubLgAVKXS S7ug== 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:content-transfer-encoding; bh=vj/S7jjU3jKgz2U6enZ47KqQXxikDOW/jPjW399kyoI=; b=Wz8OQTaffTPRJBRAU7wl5+dT2p+BDPpO7c4IfKdI9xUoD8U7fVg/wmNveZy5foqFQv vQRepGq5oHVr7ElWQHkvc6yZV3xKcEIaorP486CLVynFe4HCsPuB6njlfGDTGlxFpHwg TE3rS7HTmVXcofxazFcCfrxfYA1fhj9oILNWjm9EkHcx0IdzMia7gAogT/81J3ZYvA5l zqd/7XXC9SoPE1psOwQGBiPbuC8/+6c4hORJzLyCrilteEkkGdADJDQs1o2HrOGQnGxd WxxS2cezAxwzUjI6vo0GXYqm54Q2NQ5gnwOkmPxbUIemfufTKXHI90RgsWg5K45VF/rJ /vkQ== X-Gm-Message-State: APjAAAUHvSC/IQAWYBh9wRBL7Iaod9o2SoVlREoZnthDbn8VA2Vt5sIz Y2XLzx9rRUAjv5JDTfZPvQcaZKka8oETnJCzIXTZW38aaGU= X-Google-Smtp-Source: APXvYqxVTl/tvpfHFvfq0vMkd5JKGOw3Y6C0GYxPqXqBqIbAIVgybKrnPQe6jpt+gHmXF+Pgw1LlEM48NKHoJiOnNLw= X-Received: by 2002:a6b:4e14:: with SMTP id c20mr2768374iob.26.1566859145261; Mon, 26 Aug 2019 15:39:05 -0700 (PDT) MIME-Version: 1.0 References: <20190826102449.142687-1-liran.alon@oracle.com> <20190826102449.142687-3-liran.alon@oracle.com> In-Reply-To: From: Jim Mattson Date: Mon, 26 Aug 2019 15:38:54 -0700 Message-ID: Subject: Re: [PATCH 2/2] KVM: x86: Fix INIT signal handling in various CPU states To: Liran Alon Cc: Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , kvm list , Sean Christopherson , Vitaly Kuznetsov , Joao Martins , Nikita Leshenko , Marc Orr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Aug 26, 2019 at 3:04 PM Liran Alon wrote: > > > > > On 27 Aug 2019, at 0:17, Jim Mattson wrote: > > Suppose that L0 just finished emulating an L2 instruction with > > EFLAGS.TF set. So, we've just queued up a #DB trap in > > vcpu->arch.exception. On this emulated VM-exit from L2 to L1, the > > guest pending debug exceptions field in the vmcs12 should get the > > value of vcpu->arch.exception.payload, and the queued #DB should be > > squashed. > > If I understand correctly you are discussing a case where L2 exited to L0= for > emulating some instruction when L2=E2=80=99s RFLAGS.TF is set. Therefore,= after x86 > emulator finished emulating L2 instruction, it queued a #DB exception. Right. For example, L0 really likes to emulate L2's MOV-to-CR instructions. For added complication, what if the emulated instruction is in the shadow of a POPSS that triggered a data breakpoint? Then there will be existing pending debug exceptions in vmcs02 that need to be merged with DR6.BS. (This isn't anything new with your change, though.) > Then before resuming L2 guest, some other vCPU send an INIT signal > to this vCPU. When L0 will reach vmx_check_nested_events() it will > see pending INIT signal and exit on EXIT_REASON_INIT_SIGNAL > but nested_vmx_vmexit() will basically drop pending #DB exception > in prepare_vmcs12() when it calls kvm_clear_exception_queue() > because vmcs12_save_pending_event() only saves injected exceptions. > (As changed by myself a long time ago) > > I think you are right this is a bug. > I also think it could trivially be fixed by just making sure vmx_check_ne= sted_events() > first evaluates pending exceptions and only then pending apic events. > However, we also want to make sure to request an =E2=80=9Cimmediate-exit= =E2=80=9D in case > eval of pending exception require emulation of an exit from L2 to L1. Hmmm. Any exception other than a #DB trap should take precedence over the INIT. However, the INIT takes precedence over a #DB trap. But maybe you can fudge the ordering, because there is no way for the guest to tell which came first? What about a single-step trap on VMXOFF, with the INIT latched? In that case, the guest could tell that the INIT was latched before the VMXOFF, so the INIT must take precedence. Do we get that ordering right?