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.129.124]) by mx.groups.io with SMTP id smtpd.web10.6393.1675414198585474537 for ; Fri, 03 Feb 2023 00:49:58 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aFXLejlr; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675414197; 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=SQt8Clo5/4bn/awnC+PZN1T+WycA8DT0U9xGTLkDM2s=; b=aFXLejlrTezvv7tPisuGzFfeq1ch2/Y7d/gpuVvWAoSVJ0qqPd63D3whEVdKPB7Ywooico gwaIccEkGYcSGooOUz3ZzKXroJ1aGXDDzYVHK/9nCcvq5NWBS4pv+js2vwoGqZ5Qc1GFDu 8eFUleDCPXKNzqUYxVQTVK/+syh65mc= 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-633-QifX4zS_NPq7KssiGsmkDA-1; Fri, 03 Feb 2023 03:49:53 -0500 X-MC-Unique: QifX4zS_NPq7KssiGsmkDA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1C71D3801F58; Fri, 3 Feb 2023 08:49:53 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CF6B0400DFA1; Fri, 3 Feb 2023 08:49:52 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 6D0D1180060E; Fri, 3 Feb 2023 09:49:51 +0100 (CET) Date: Fri, 3 Feb 2023 09:49:51 +0100 From: "Gerd Hoffmann" To: "Ni, Ray" Cc: Laszlo Ersek , "Wu, Jiaxin" , "devel@edk2.groups.io" , "Dong, Eric" , "Zeng, Star" , "Kumar, Rahul R" Subject: Re: [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: Skip SMBASE configuration Message-ID: <20230203084951.l66gzanxqm6huvqt@sirius.home.kraxel.org> References: <20230119075303.nkyno36h25xscwkn@sirius.home.kraxel.org> <20230201134051.7jlc7a74cogcskw5@sirius.home.kraxel.org> <20230202090003.5vmmeyhsv4zn7wn4@sirius.home.kraxel.org> <00b01cd3-7ed2-b0f1-e2ef-1d48930a0083@redhat.com> <20230203073144.pdrwf7logbgbow3c@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > Please don't imagine that "I" want to hide something. If I cannot tell you something, > that's because the information cannot be public for now required by > the company policy. I fully understand that it not your personal choice but company policy. Just explicitly say so -- ideally right from the start -- when this is the case instead of leaving others in the void would make discussions alot easier. So, to summarize: Intel processors have some new way to set SMBASE which does not require entering SMM mode. It requires running code on each CPU thread though, which is incompatible with StandaloneMM. So it needs to be done before setting up StandaloneMM and you choose to do it in a PEI module. More details can not be shared per intel company policy. The PEIM is closed source. Would that be known right from start the discussion on the OVMF changes would have been much shorter and much less frustrating. That information makes pretty clear that it is not relevant at all for OVMF. Even in case the PEIM gets released as open source in the future it is not relevant. What matters for OVMF is what qemu and kvm support (which is why it has its own SmmCpuFeaturesLib variant in the first place). take care, Gerd