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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 A3710C11F6A for ; Tue, 6 Jul 2021 12:12:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9714862201 for ; Tue, 6 Jul 2021 12:12:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343558AbhGFMOf (ORCPT ); Tue, 6 Jul 2021 08:14:35 -0400 Received: from forward102j.mail.yandex.net ([5.45.198.243]:59255 "EHLO forward102j.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238498AbhGFMJH (ORCPT ); Tue, 6 Jul 2021 08:09:07 -0400 Received: from myt5-1892386aa303.qloud-c.yandex.net (myt5-1892386aa303.qloud-c.yandex.net [IPv6:2a02:6b8:c12:4323:0:640:1892:386a]) by forward102j.mail.yandex.net (Yandex) with ESMTP id 4F0D0F20AFF; Tue, 6 Jul 2021 15:06:27 +0300 (MSK) Received: from myt5-89cdf5c4a3a5.qloud-c.yandex.net (myt5-89cdf5c4a3a5.qloud-c.yandex.net [2a02:6b8:c12:289b:0:640:89cd:f5c4]) by myt5-1892386aa303.qloud-c.yandex.net (mxback/Yandex) with ESMTP id cftkzOqST2-6QIuZM7g; Tue, 06 Jul 2021 15:06:27 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1625573187; bh=bWhW4xbIU0foB+1vY5bZzoaCcvH8gAkkGUUfpILN4pE=; h=In-Reply-To:From:To:Subject:Message-ID:Cc:Date:References; b=YbVpnhkTvQ5sORCFIdUCAfL83J1JRJnCfrDMsLYC6Kpyijia27B9f2afXp0a/AkWm N01vqh90lpSMzHyCM4sbe5NFSApQwatP4VEBAPIwk6LcOAaCwImlMlBkAGFGR4jICP HKpf//egMNwAz9FDSgz0X8kF+saXhij/4f8J7sys= Authentication-Results: myt5-1892386aa303.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt5-89cdf5c4a3a5.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 0JWzyvF38O-6PPKs9vn; Tue, 06 Jul 2021 15:06:25 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: [PATCH v2] KVM: X86: Fix exception untrigger on ret to user To: Maxim Levitsky Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Jan Kiszka , x86@kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org References: <20210628124814.1001507-1-stsp2@yandex.ru> <32451d4990cad450f6c8269dbd5fa6a59d126221.camel@redhat.com> <7969ff6b1406329a5a931c4ae39cb810db3eefcd.camel@redhat.com> From: stsp Message-ID: <7f264d9f-cb59-0d10-d435-b846f9b61333@yandex.ru> Date: Tue, 6 Jul 2021 15:06:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <7969ff6b1406329a5a931c4ae39cb810db3eefcd.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 06.07.2021 14:49, Maxim Levitsky пишет: > Now about the KVM's userspace API where this is exposed: > > I see now too that KVM_SET_REGS clears the pending exception. > This is new to me and it is IMHO *wrong* thing to do. > However I bet that someone somewhere depends on this, > since this behavior is very old. What alternative would you suggest? Check for ready_for_interrupt_injection and never call KVM_SET_REGS if it indicates "not ready"? But what if someone calls it nevertheless? Perhaps return an error from KVM_SET_REGS if exception is pending? Also KVM_SET_SREGS needs some treatment here too, as it can also be called when an exception is pending, leading to problems. > This doesn't affect qemu since when it does KVM_SET_REGS, > it also does KVM_SET_VCPU_EVENTS afterward, and that > restores either pending or injected exception state. > (that state is first read with KVM_GET_VCPU_EVENTS ioctl). > > Also note just for reference that KVM_SET_SREGS has ability > to set a pending interrupt, something that is also redundant > since KVM_SET_VCPU_EVENTS does this. > I recently added KVM_SET_SREGS2 ioctl which now lacks this > ability. > > KVM_SET_VCPU_EVENTS/KVM_GET_VCPU_EVENTS allows to read/write > state of both pending and injected exception and on top of that > allows to read/write the exception payload of a pending exception. > > You should consider using it to preserve/modify the exception state, > although the later isn't recommended (qemu does this in few places, > but it is a bit buggy, especially in regard to nested guests). I need neither to preserve nor modify the exception state. All I need is to safely call KVM_SET_REGS/KVM_SET_SREGS, but that appears unsafe when exception is pending. Please take a look into this commit: https://www.lkml.org/lkml/2020/12/1/324 It was suggested that the removal of "!kvm_event_needs_reinjection(vcpu)" condition from kvm_vcpu_ready_for_interrupt_injection() is what introduced the problem, as right now ready_for_interrupt_injection doesn't account for pending exception. I already added the check to my user-space code, and now it works reliably on some very old kernels prior to the aforementioned patch. So should we treat that as a regressions, or any other proposal?