From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.163477.1673864886429391903 for ; Mon, 16 Jan 2023 02:28:06 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DCgirwYt; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673864885; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZLCx2O+aHQInxLfBg24NUr+Mv2IOpPA2IahxgJM3HYc=; b=DCgirwYt0C3ZSBtD6Jc+Hg+uj0PvpXlUdVfWACoKktEGdn+f3YVBPNM2Uqkrh4nVP2tee0 9/7HVmaYqVqSJuG+d3Tj1X14kCG3DYruPw4Vmf+JfbvppGXK49LC6/HlLZGUSHzX15Ni6Q i9qSznfsR0H8nX+G1DzyUES87QoydAs= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-660-9ziwiTh9O42h_AgZhjQ1Iw-1; Mon, 16 Jan 2023 05:28:04 -0500 X-MC-Unique: 9ziwiTh9O42h_AgZhjQ1Iw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 91CA229ABA04; Mon, 16 Jan 2023 10:28:03 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.124]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3D4F6C15BA0; Mon, 16 Jan 2023 10:28:02 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 61E2C18017F5; Mon, 16 Jan 2023 11:28:01 +0100 (CET) Date: Mon, 16 Jan 2023 11:28:01 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io, dave.hansen@intel.com Cc: dionnaglaze@google.com, dave.hansen@linux.intel.com, Jiewen , "Shutemov, Kirill" Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior Message-ID: <20230116102801.y3l6xn3gdgregn4k@sirius.home.kraxel.org> References: <16581.1673625639418051810@groups.io> <0918b9db-c949-75ce-a24e-f12f03865938@intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 13, 2023 at 10:34:15AM -0800, Dave Hansen wrote: > On 1/13/23 10:23, Dionna Glaze via groups.io wrote: > >> However, *NONE* of this points me in the direction of saying that we > >> should have an OS/firmware protocol to negotiate whether the firmware or > >> OS does page acceptance other than the existing UEFI memory map bit. > > We know of distributions that are going to release SEV-SNP support > > without unaccepted memory support, > > Well, I guess that's a bit of a different problem. > > I'd love to hear from the distros what they're planning on carrying > outside of mainline and what their plans are for the kernel side of this > series. Fedora has near zero additional patches, so it pretty much depends on how mainline merges stuff. If SEV-SNP or TDX or both will land in an upstream release before support for unaccepted memory lands too you'll see that in Fedora kernels, and I guess likewise in most non-enterprise distros. RHEL/CentOS typically requires mainline acceptance too for backports, so it likewise depends on upstream merging, and additionally rhel release planning comes into play. In case unaccepted memory support lands later than TDX it could (depending on timing) very well be that the choices are to either backport TDX without unaccepted memory support, or move both TDX support and unaccepted memory support to a later release. take care, Gerd