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 B2A50C433F5 for ; Mon, 28 Mar 2022 17:51:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244728AbiC1Rwj (ORCPT ); Mon, 28 Mar 2022 13:52:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244644AbiC1Rwh (ORCPT ); Mon, 28 Mar 2022 13:52:37 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC3D93C735 for ; Mon, 28 Mar 2022 10:50:56 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id l4-20020a17090a49c400b001c6840df4a3so82924pjm.0 for ; Mon, 28 Mar 2022 10:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=k9swn3UFVhgUXTfUhyp3q19zbpP+fWfmwmrzd9mdhuI=; b=H+qH3IZyJmG67UHSvVV7IVVXEF0PU0oygFqGrp1ftXvA0kbdX9isRmj4lQghH+0oVx M23tHe9cunGKcFjBk/S4/8xYZ5SZ6YwJawFegP8XU8ismQ8CEj7yYyBllhQeb58vnPS8 QPZVd2kyVjHkP/Hw1BOfjEUGqPJsMJaVjj3ck3aZtDKniYz7BK6cM+WltubF/h852fzl R+frgR5k+wo4AOEZqBzvg0zNfdJicrQV1XGWNEY4otWyoD1MgbcdOlxN0/T41uZLhDlq HesGN+EFX8DRdAJDCkqFf2bw2P+XYpLpuc46eypq6pfAV/U7b+5TrRogLk89w4ZstQEq xB+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=k9swn3UFVhgUXTfUhyp3q19zbpP+fWfmwmrzd9mdhuI=; b=qUQkGG2u73/wtb1r/xAm+iik6Gprrld4MKQXPCC83fOvm8Q9HaCs/KtQpZ0TJnR5QB 7A5He6fOyG1ap9p3XQ7gt4G0ZTWgYbHtDoBsEPMADy9e6X1zVWTPfUHL4Ym1pug1S2HQ 2FMZNAJ+ZjZD0BrG45o5HMnbTPmtagiQm8a84vlAaJ/kEm7qepKHgGOksOGfSkjVxcGT 9LpGrhfyxC53rVzDFW/UXLkUtebjAr2YENchKeI3SFFfyfNA2zejAtSPu2HkF5jncx9j 36PxDbrSgMQtS7xGOWGt95RocuXfWXukxnDhUTMGpzH8zQ9kOunC527k0xXN2sjRA6uY rmHg== X-Gm-Message-State: AOAM533WdEU2mbt22B9Uc13V6tfSJwx1bSFc8njk/o+3levrcHIlmtKN sM7265HSd5wER7UBvicKoeXRtA== X-Google-Smtp-Source: ABdhPJxnaQhNGStKoPg9KikqgUp5Q7S6gz5EymGQc6i8+buIPXZRJ9565uoCA8b+0h1AfvpOm2r7Jw== X-Received: by 2002:a17:903:11c7:b0:151:7290:ccc with SMTP id q7-20020a17090311c700b0015172900cccmr27401517plh.95.1648489856246; Mon, 28 Mar 2022 10:50:56 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id z6-20020a056a00240600b004e17ab23340sm17616971pfh.177.2022.03.28.10.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 10:50:55 -0700 (PDT) Date: Mon, 28 Mar 2022 17:50:51 +0000 From: Sean Christopherson To: Maxim Levitsky Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver Upton , Peter Shier Subject: Re: [PATCH 00/21] KVM: x86: Event/exception fixes and cleanups Message-ID: References: <20220311032801.3467418-1-seanjc@google.com> <08548cb00c4b20426e5ee9ae2432744d6fa44fe8.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 27, 2022, Maxim Levitsky wrote: > Other than that I am actually very happy that you posted this patch series, > as this gives more chance that this long standing issue will be fixed, > and if your patches are better/simpler/less invasive to KVM and still address the issue, > I fully support using them instead of mine. I highly doubt they're simpler or less invasive, but I do hope that the approach wil be easier to maintain. > Totally agree with you about your thoughts about splitting pending/injected exception, > I also can't say I liked my approach that much, for the same reasons you mentioned. > > It is also the main reason I put the whole thing on the backlog lately, > because I was feeling that I am changing too much of the KVM, > for a relatively theoretical issue. > > > I will review your patches, compare them to mine, and check if you or I missed something. > > PS: > > Back then, I also did an extensive review on few cases when qemu injects exceptions itself, > which it does thankfully rarely. There are several (theoretical) issues there. > I don't remember those details, I need to refresh my memory. > > AFAIK, qemu injects #MC sometimes when it gets it from the kernel in form of a signal, > if I recall this correctly, and it also reflects back #DB, when guest debug was enabled > (and that is the reason for some work I did in this area, like the KVM_GUESTDBG_BLOCKIRQ thing) > > Qemu does this without considering nested and/or pending exception/etc. > It just kind of abuses the KVM_SET_VCPU_EVENTS for that. I wouldn't call that abuse, the ioctl() isn't just for migration. Not checking for a pending exception is firmly a userspace bug and not something KVM should try to fix. For #DB, I suspect it's a non-issue. The exit is synchronous, so unless userspace is deferring the reflection, which would be architecturally wrong in and of itself, there can never be another pending exception. For #MC, I think the correct behavior would be to defer the synthesized #MC if there's a pending exception and resume the guest until the exception is injected. E.g. if a different task encounters the real #MC, the synthesized #MC will be fully asynchronous and may be coincident with a pending exception that is unrelated to the #MC. That would require to userspace to enable KVM_CAP_EXCEPTION_PAYLOAD, otherwise userspace won't be able to differentiate between a pending and injected exception, e.g. if the #MC occurs during exception vectoring, userspace should override the injected exception and synthesize #MC, otherwise it would likely soft hang the guest.