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 52D44C433EF for ; Fri, 1 Jul 2022 07:37:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235255AbiGAHhn (ORCPT ); Fri, 1 Jul 2022 03:37:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231313AbiGAHhm (ORCPT ); Fri, 1 Jul 2022 03:37:42 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 485E86D551 for ; Fri, 1 Jul 2022 00:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656661060; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7YSpU59gT8QB4BAcnl2JJyxyCcYteDUajcj+60eh/hA=; b=EnnGxrdp/RBNO0bU6jA54V8zRof+PcCWpQGeyUnYUgM0luLb0hsv3zw18+iSOEa4axyjs/ VWzA8ERYcgBxRqh3Nn7e30OH32rGifkdf/WVuGtinkH0NCAIM810ZOzXlleVuNIlJckLR7 8aLjQgyW3KG9rPZvw/y28Y0R/VWm1VE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-575-0oeNBz39MeyGRLFmQh2JLg-1; Fri, 01 Jul 2022 03:37:38 -0400 X-MC-Unique: 0oeNBz39MeyGRLFmQh2JLg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2BCF83C0D873; Fri, 1 Jul 2022 07:37:38 +0000 (UTC) Received: from starship (unknown [10.40.194.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id A6ACB1121314; Fri, 1 Jul 2022 07:37:35 +0000 (UTC) Message-ID: <53b6874517a76d8d046e665c1f2f378769b721a0.camel@redhat.com> Subject: Re: [PATCH v2 00/21] KVM: x86: Event/exception fixes and cleanups From: Maxim Levitsky To: Jim Mattson Cc: Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver Upton , Peter Shier Date: Fri, 01 Jul 2022 10:37:34 +0300 In-Reply-To: References: <20220614204730.3359543-1-seanjc@google.com> <7e05e0befa13af05f1e5f0fd8658bc4e7bdf764f.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2022-06-30 at 09:28 -0700, Jim Mattson wrote: > On Thu, Jun 30, 2022 at 1:22 AM Maxim Levitsky wrote: > > On Wed, 2022-06-29 at 06:42 -0700, Jim Mattson wrote: > > > Unlike the AMD "INTn intercept," these trap intercepts *do not* happen > > > at the start of the instruction. > > > > Are you sure about that? > > I had been sure when I wrote that, but now that I see your response, I > have to question my memory. The SDM is definitely more authoritative > than I am. x86 is like a fractal, the more I know it more I realize I don't. > > > > When you say "ignores," do you mean that AMD ignores a data breakpoint > > > or single-step trap generated by MOV-SS, or it ignores the fact that > > > delivering such a #DB trap between the MOV-SS and the subsequent > > > MOV-ESP will create a stack frame in the wrong place? > > > > Two things which can be infered from the SVM spec. > > - AMD doesn't distinguish between MOV SS and STI int shadow. > > - AMD has no 'pending debug exception field' in the vmcb. > > > > I don't know what AMD does for #DB that happens on MOV SS, nor if it > > does distinguish these internally, > > probably just drops the #DB or something. > > Without carrying pending debug exceptions, it seems that the only two > choices are to deliver the #DB, with the exception frame in an > unintended location or to drop the #DB. The latter seems preferable, > but neither one seems good. What I don't understand is why you claim > that AMD does this "rightfully." Are you saying that anyone with the > audacity to run a debugger on legacy code deserves to be thrown in > front of a moving train? I understand what you mean, its a tradeof of 100% compliant implementation vs complexity the corner cases introduce. #DB can already be missed in some cases I think, especially from my experience from debuggers, and even more especially when debugging an OS. It is a pain, as the OS naturally tries to switch tasks and process interrupts all the time, I even added that _BLOCKIRQ flag to KVM to make it a bit better. But still I understand what you mean, so maybe indeed VMX did it better. > > > > Hence, the facility for injecting a "pending MTF"--so that it won't be "lost." > > Yes, though that is would be mostly useful for nesting. > > > > For not nesting hypervisor, if the hypervisor figured out that a higher priority event overrode > > the MTF, it can just process the MTF - why to re-inject it? > > You're right. The facility is probably just there to make MTF > virtualizable. Intel was paying much closer attention to > virtualizability by the time MTF came along. That makes sense. > > > > These are single-step, I/O and data breakpoint traps. > > > > I am not sure what you mean. single-step, IO, data breakpoints are indeed the trap #DB, > > while "general detect", code breakpoint are fault #DB, and we also have the task switch #DB, but since the hardware doesn't > > emulate the task switches, this has to be injected. > > Just enumerating. No more, no less. > All right, thank you very much for the help, especialy for the tables you provided, all of this should be enough now for me to review the patch series. Thanks, Best regards, Maxim Levitsky