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 EE6F5C433EF for ; Fri, 22 Apr 2022 07:58:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358510AbiDVIB3 (ORCPT ); Fri, 22 Apr 2022 04:01:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349087AbiDVIBY (ORCPT ); Fri, 22 Apr 2022 04:01:24 -0400 Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A184237BF8 for ; Fri, 22 Apr 2022 00:58:31 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id k12so4584024ilv.3 for ; Fri, 22 Apr 2022 00:58:31 -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=Bs1ARD/3mYc/Q8GOvyTn31OWHleeyCohrGDUgjVzb5c=; b=p+I+yyKB3vk9fRPIkec81mqI7u7jjNG4T/gBJ7wEluxmyol/g/AAulxisd7IjBxgr2 IO6BpSnF1kpLqLtrdnvrHaTUJv0X2wBtdniE/vF2ftltP2695m9jCGk4rRlGK8tOchIX DlGhM0xaSPRnCZQx7+9tFMg1cvBMYUTK09FM0PNRn+VHNTXzyvQATMS8o6aBe40UaOqB FGfOWAw7zIE0ev4+5dxe0f2SMwTyZlRzBP/x3mUsH/00DNrTIfks0QKDdqfywjvbK+ut zMxmoLAKwNdMgG1bQDz8doVsp1uwm2fWWa2FRdN8rgAwgg7shr1NqQb3KPlHx0IHfH+x 1Xeg== 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=Bs1ARD/3mYc/Q8GOvyTn31OWHleeyCohrGDUgjVzb5c=; b=Y0qZGbd1P8+l1ZCd6VqQEWBbNtJDbbXNekrqvZf2L/6ybta6ABp6GQLpefmP+ads8v vlz81z2zvx1EL/AC48N5OzoZX2nmDw/oTagePJQ1gwxcsKNl+RjdH6yvupmuvbiEWY3m TpzrqymE/24VDbUDxDfnjX/gsgcpR40gS/PSxIUZ2ZR1xFxFXcqZN3GO1TMsjcXWXY6N Ej633n5AkroBuKsv0h51U/BB4g21XEVpPSlnhqkHAOCfz3dfiau5wvnj/Tp0BYc+I3TH D+OhE2sXNtxn90rMJq1IadN+79koya+ZiX1G8Q1JZZrwJeTVJps7aGq+kygpLfpuE2LB EJpw== X-Gm-Message-State: AOAM530Tq4aQjpm5HeRt2zyiDNGGRLJ89b67mLqUsA6K8kVdqEoUx3Xs BTN33pz2W/RM7rFfAEfA/NzWP8PBPsz+gg== X-Google-Smtp-Source: ABdhPJxGh4l1P/5zNuiHNIaIg80R6S4iA2eyq7GpR4Gotde6duI/fSeWt3QpVY9yefAmiuwTK8d/2A== X-Received: by 2002:a05:6e02:148f:b0:2cd:2242:40d6 with SMTP id n15-20020a056e02148f00b002cd224240d6mr1503449ilk.187.1650614310633; Fri, 22 Apr 2022 00:58:30 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id f4-20020a056e0204c400b002caa9f3cc3fsm893115ils.56.2022.04.22.00.58.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 00:58:29 -0700 (PDT) Date: Fri, 22 Apr 2022 07:58:25 +0000 From: Oliver Upton To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, will@kernel.org, maz@kernel.org, apatel@ventanamicro.com, atishp@rivosinc.com, seanjc@google.com, pgonda@google.com Subject: Re: [PATCH 0/4] KVM: fix KVM_EXIT_SYSTEM_EVENT mess Message-ID: References: <20220421180443.1465634-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220421180443.1465634-1-pbonzini@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paolo, On Thu, Apr 21, 2022 at 02:04:39PM -0400, Paolo Bonzini wrote: > The KVM_SYSTEM_EVENT_NDATA_VALID mechanism that was introduced > contextually with KVM_SYSTEM_EVENT_SEV_TERM is not a good match > for ARM and RISC-V, which want to communicate information even > for existing KVM_SYSTEM_EVENT_* constants. Userspace is not ready > to filter out bit 31 of type, and fails to process the > KVM_EXIT_SYSTEM_EVENT exit. > > Therefore, tie the availability of ndata to a system capability; > if the capability is present, ndata is always valid, so patch 1 > makes x86 always initialize it. Then patches 2 and 3 fix > ARM and RISC-V compilation and patch 4 enables the capability. > > Only compiled on x86, waiting for acks. > > Paolo > > Paolo Bonzini (4): > KVM: x86: always initialize system_event.ndata > KVM: ARM: replace system_event.flags with ndata and data[0] > KVM: RISC-V: replace system_event.flags with ndata and data[0] > KVM: tell userspace that system_event.ndata is valid Is there any way we could clean this up in 5.18 and leave the whole ndata/data pattern for 5.19? IOW, for 5.18 go back and fix the padding: struct { __u32 type; __u32 pad; __u64 flags; } system_event; Then for 5.19 circle back on the data business, except use a flag bit for it: struct { __u32 type; __u32 pad; #define KVM_SYSTEM_EVENT_NDATA_VALID (1u << 63) __u64 flags; __u64 ndata; __u64 data[16]; } system_event; Where we apply that bit to system_event::flags this time instead of ::type. Could also go the CAP route. Wouldn't this be enough to preserve ABI with whatever userspace has been spun up for system_event::flags already and also keep the SEV stuff happy in 5.19? It is a bit weird to churn existing UAPI usage in the very next kernel cycle, but could be convinced otherwise :) -- Thanks, Oliver