Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4455271pxf; Tue, 16 Mar 2021 14:04:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzf1ZR4Pi73IWOMw+lNZlckQeY0nO38vfYPP3YP+rstOioO7Yp0+TjRUeiuc5oBdyZHsEN4 X-Received: by 2002:a17:906:8308:: with SMTP id j8mr31021685ejx.339.1615928642273; Tue, 16 Mar 2021 14:04:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615928642; cv=none; d=google.com; s=arc-20160816; b=e/ENV3ocq1l9H41InLEJFHNE/Lh3kz++Q/1P35e9mLevHK3k1bB4fwUKKtCKHBxPCm M8xYYjP/TwHUTPpU5bMNEmIW92RlaFT5wHnyAVuovfzrJ+WvjY+frHt00yVhNR5WYDJv 9mEPs+HB0KuGkY1U6YoiFawrCquKFwQmpUd7wFO1MP8AqG0CLRMBBC+sCoeaGjsQ+/MH l23Ip+muBEAWxAJiXG4evGcDUtJTn29Ny/g0HdzYRBdPa7v3xHPUxTiWklSbFsFj8LaW hGU2Bw2AJnaE9/UtrxGpmSZ++UAywmckqAaP6n9Nxc/NXxMlZfk3WnFTh9DJYKaQdawn 8MXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=pQ4/WvtlafGFIirf9Lu3VwFiFgy39R8pRw10u/YTZag=; b=JMq9jdGLfuu6flTYiC44xZp5GA+LEsRV3JkGNHKuSTB1NsFHGFMy8pYus1c5PjhW48 Aql7IiEtPFhvwcg0VYWTOA+WbCpZoujhqXL/d26U2zS925nYwFzsemqxsa8filtAXgPJ 7McqtBASjpmkiuZH8i+aZMdzxdxLdleiiDaRq6m2yoPi70JVzzHWqaKP/SuTOsQQ3Qj9 TuE0GQtzr8QUTZnBZgTC6aQXQeb60DPU3xE6ssNsLDyoK1aVHCza0BVxLsqNHnZz/8M2 kg7R+Ad4aSroAk7WJyrOu10fk+PynwGyWdlI3QqEfDNx/rShm1aRbusaAdjlTy1xqgFD tAlQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y3si13426060edr.457.2021.03.16.14.03.35; Tue, 16 Mar 2021 14:04:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239081AbhCPRHZ (ORCPT + 99 others); Tue, 16 Mar 2021 13:07:25 -0400 Received: from gecko.sbs.de ([194.138.37.40]:34495 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239084AbhCPRHI (ORCPT ); Tue, 16 Mar 2021 13:07:08 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 12GH6dC0010712 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 16 Mar 2021 18:06:39 +0100 Received: from [167.87.27.98] ([167.87.27.98]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 12GH1al7023551; Tue, 16 Mar 2021 18:01:36 +0100 Subject: Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping To: Sean Christopherson , Maxim Levitsky Cc: kvm list , Vitaly Kuznetsov , LKML , Thomas Gleixner , Wanpeng Li , Kieran Bingham , Jessica Yu , Andrew Morton , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Joerg Roedel , Jim Mattson , Borislav Petkov , Stefano Garzarella , "H. Peter Anvin" , Paolo Bonzini , Ingo Molnar References: <20210315221020.661693-3-mlevitsk@redhat.com> <1259724f-1bdb-6229-2772-3192f6d17a4a@siemens.com> <71ae8b75c30fd0f87e760216ad310ddf72d31c7b.camel@redhat.com> <2a44c302-744e-2794-59f6-c921b895726d@siemens.com> <1d27b215a488f8b8fc175e97c5ab973cc811922d.camel@redhat.com> <727e5ef1-f771-1301-88d6-d76f05540b01@siemens.com> From: Jan Kiszka Message-ID: <31c0bba9-0399-1f15-a59b-a8f035e366e8@siemens.com> Date: Tue, 16 Mar 2021 18:01:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16.03.21 17:50, Sean Christopherson wrote: > On Tue, Mar 16, 2021, Maxim Levitsky wrote: >> On Tue, 2021-03-16 at 16:31 +0100, Jan Kiszka wrote: >>> Back then, when I was hacking on the gdb-stub and KVM support, the >>> monitor trap flag was not yet broadly available, but the idea to once >>> use it was already there. Now it can be considered broadly available, >>> but it would still require some changes to get it in. >>> >>> Unfortunately, we don't have such thing with SVM, even recent versions, >>> right? So, a proper way of avoiding diverting event injections while we >>> are having the guest in an "incorrect" state should definitely be the goal. >> Yes, I am not aware of anything like monitor trap on SVM. >> >>> >>> Given that KVM knows whether TF originates solely from guest debugging >>> or was (also) injected by the guest, we should be able to identify the >>> cases where your approach is best to apply. And that without any extra >>> control knob that everyone will only forget to set. >> Well I think that the downside of this patch is that the user might actually >> want to single step into an interrupt handler, and this patch makes it a bit >> more complicated, and changes the default behavior. > > Yes. And, as is, this also blocks NMIs and SMIs. I suspect it also doesn't > prevent weirdness if the guest is running in L2, since IRQs for L1 will cause > exits from L2 during nested_ops->check_events(). > >> I have no objections though to use this patch as is, or at least make this >> the new default with a new flag to override this. > > That's less bad, but IMO still violates the principle of least surprise, e.g. > someone that is single-stepping a guest and is expecting an IRQ to fire will be > all kinds of confused if they see all the proper IRR, ISR, EFLAGS.IF, etc... > settings, but no interrupt. From my practical experience with debugging guests via single step, seeing an interrupt in that case is everything but handy and generally also not expected (though logical, I agree). IOW: When there is a knob for it, it will remain off in 99% of the time. But I see the point of having some control, in an ideal world also an indication that there are pending events, permitting the user to decide what to do. But I suspect the gdb frontend and protocol does not easily permit that. > >> Sean Christopherson, what do you think? > > Rather than block all events in KVM, what about having QEMU "pause" the timer? > E.g. save MSR_TSC_DEADLINE and APIC_TMICT (or inspect the guest to find out > which flavor it's using), clear them to zero, then restore both when > single-stepping is disabled. I think that will work? > No one can stop the clock, and timers are only one source of interrupts. Plus they do not all come from QEMU, some also from KVM or in-kernel sources directly. Would quickly become a mess. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux