Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp41514ybb; Tue, 7 Apr 2020 16:22:36 -0700 (PDT) X-Google-Smtp-Source: APiQypLNW6r+TbUOjXzW56N85WZlaSU7e6M3VlgtXO3A0hsjYJRXbIkrx56RvCed7ligAAJI1vZl X-Received: by 2002:a05:6820:221:: with SMTP id j1mr3933606oob.12.1586301756203; Tue, 07 Apr 2020 16:22:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586301756; cv=none; d=google.com; s=arc-20160816; b=sAV7jbc1FulsN2JHSscloMbj7FR7D1oCsYmXjKqnLI0H/9GOEXe5Ls4o+fgx25Si3y oZaXmLwX5qsVFq6+KN2rxGAEiunNC0Oy4KaQ9KS/gLFHgVqR7fDibEA5G4WzI3QcV/FC s8LIoleYYZtTPjGVpp64cpm9Asxtxh9Hjuih1je7mp2fk1StbxHx9nAMO6hI1hMxD68U kip+u1LJhO371XK+XhScSScM/CeiPWFoHCrCoq+WzUBmB8fyB7equgOHzrUkmLMYQVG8 lf+G9X53Qr/xuv39vP6YNl8hk/nY6iSMmEIDhF3wFyAh5fhwYtv1/5G5ppMP8JeJRrwM js2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=JNil6nP8N1rn0FX0l7qjFNt3DCUgnp90BBcEDpPgrho=; b=gUS1Ft5Hr/BiKvtDciEXsCN7eAJhEtfu1aTwY/CFlJ6rdO5ZLgnhyDG9MUQ0t+zaTT quU9dzkinldieUYtd5K2IsbwtZI9TICG31CdXTBxHLfpM4leNegEl5LxmdtOsTICGVa7 J8bpVsERRHCxoNaTU9Q7FIFlGIRDwaXW9JHbSHgE9sJ2aUQYrrxSmkYOqGsBB40R2qOf bjcM4QO9L4Xt9HWGuAbhjKnFe0Z9UczNpoPa1HdoNBrNy/LdLa1raDp1kkW3sZmOOLXi 2MhdlhPH7SYBVvYvqy3Nycvy7FiNWGZw1UqiO/bwtbWOH5gtd8YSrXELyO466pnDscXa DMMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l6si1937221otn.219.2020.04.07.16.22.21; Tue, 07 Apr 2020 16:22:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726467AbgDGXVn (ORCPT + 99 others); Tue, 7 Apr 2020 19:21:43 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48654 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726395AbgDGXVn (ORCPT ); Tue, 7 Apr 2020 19:21:43 -0400 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jLxXG-0006vE-7B; Wed, 08 Apr 2020 01:21:38 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id B01FF10069D; Wed, 8 Apr 2020 01:21:37 +0200 (CEST) From: Thomas Gleixner To: Paolo Bonzini , Andy Lutomirski , Vivek Goyal Cc: Peter Zijlstra , Andy Lutomirski , LKML , X86 ML , kvm list , stable Subject: Re: [PATCH v2] x86/kvm: Disable KVM_ASYNC_PF_SEND_ALWAYS In-Reply-To: References: <20200407172140.GB64635@redhat.com> <772A564B-3268-49F4-9AEA-CDA648F6131F@amacapital.net> <87eeszjbe6.fsf@nanos.tec.linutronix.de> Date: Wed, 08 Apr 2020 01:21:37 +0200 Message-ID: <874ktukhku.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paolo Bonzini writes: > On 07/04/20 22:20, Thomas Gleixner wrote: >>>> Havind said that, I thought disabling interrupts does not mask exceptions. >>>> So page fault exception should have been delivered even with interrupts >>>> disabled. Is that correct? May be there was no vm exit/entry during >>>> those 10 seconds and that's why. >> No. Async PF is not a real exception. It has interrupt semantics and it >> can only be injected when the guest has interrupts enabled. It's bad >> design. > > Page-ready async PF has interrupt semantics. > > Page-not-present async PF however does not have interrupt semantics, it > has to be injected immediately or not at all (falling back to host page > fault in the latter case). If interrupts are disabled in the guest then it is NOT injected and the guest is suspended. So it HAS interrupt semantics. Conditional ones, i.e. if interrupts are disabled, bail, if not then inject it. But that does not make it an exception by any means. It never should have been hooked to #PF in the first place and it never should have been named that way. The functionality is to opportunisticly tell the guest to do some other stuff. So the proper name for this seperate interrupt vector would be: VECTOR_OMG_DOS - Opportunisticly Make Guest Do Other Stuff and the counter part VECTOR_STOP_DOS - Stop Doing Other Stuff > So page-not-present async PF definitely needs to be an exception, this > is independent of whether it can be injected when IF=0. That wants to be a straight #PF. See my reply to Andy. > Hypervisors do not have any reserved exception vector, and must use > vectors up to 31, which is why I believe #PF was used in the first place > (though that predates my involvement in KVM by a few years). No. That was just bad taste or something worse. It has nothing to do with exceptions, see above. Stop proliferating the confusion. > These days, #VE would be a much better exception to use instead (and > it also has a defined mechanism to avoid reentrancy). #VE is not going to solve anything. The idea of OMG_DOS is to (opportunisticly) avoid that the guest (and perhaps host) sit idle waiting for I/O until the fault has been resolved. That makes sense as there might be enough other stuff to do which does not depend on that particular page. If not then fine, the guest will go idle. Thanks, tglx