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.web10.5614.1675409511484898552 for ; Thu, 02 Feb 2023 23:31:51 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SUPPZ37l; 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=1675409510; 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=TekA1jZrowVX/bwyVceunkNtU1Lizt58srRGBytHRl8=; b=SUPPZ37lIIbVr2yQMEG8khGk+/MMzxPWKs83HAIsRQBw0viXDSSXRvr+luX4jMPmCPmlNN exPTKBbXfVDgViyir7Qh4IVsdw8Qw8wFSJFa3X1qXIAcHnJ9GlcPeglLrmfq704ErDdSkt 7VGbzxBMz1aXmGj+gNQvqIi54OTgGyI= 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-284-GdoNtL0vNQqqK1jtav8SFA-1; Fri, 03 Feb 2023 02:31:46 -0500 X-MC-Unique: GdoNtL0vNQqqK1jtav8SFA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6EFA529ABA16; Fri, 3 Feb 2023 07:31:46 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 255F62166B34; Fri, 3 Feb 2023 07:31:46 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id B0CD1180060E; Fri, 3 Feb 2023 08:31:44 +0100 (CET) Date: Fri, 3 Feb 2023 08:31:44 +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: <20230203073144.pdrwf7logbgbow3c@sirius.home.kraxel.org> References: <20230118095620.9860-6-jiaxin.wu@intel.com> <20230118121958.cxbfh3fljedvebis@sirius.home.kraxel.org> <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> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > > Ok. So new Intel processors apparently got new MSR(s) to set SMBASE > > > directly. Any specific reason why you don't add support for that to > > > PiSmmCpuDxeSmm? That would avoid needing the new HOB (and the related > > > problems with the 8190 cpu limit) in the first place. > > The reason is the hardware interface to set SMBASE is in thread scope meaning > such firmware-hardware communication needs to be done for each CPU thread. > > It's doable to program the hardware interface using DXE MP service protocol in > CpuSmm driver's entry point. > But, considering the standalone MM environment where the CpuMm driver runs > in a isolated environment and it cannot invoke any DXE or PEI MP service, you could > understand that why we choose to put the hardware interface programming in a separate > PEI module. This is the major reason. Ok, *that* finally makes sense to me. Can you please add a source code comment explaining this to the patch series? Patch #1 (which adds the interface) is the best place I think. > I admit that a minor benefit of this design is we can isolate the > private hardware interface programming in a close-source module. > Otherwise, the SmmCpuFeaturesLib might need to expose a new API for > the hardware interface programming. "benefit" and "closed-source" in one sentence while discussion patches for an open source project. And you are wondering (see parallel mail by Jiaxin) why outsiders get the impression you are trying to hide information. No further questions. > Though this new HOB is not in PI spec, you remind me that we might > need to add more fields to the HOB so a way to distinguish between > different versions of the HOB should be considered. The way could be > to introduce a new GUID for new version of HOB, or add a field > (version?) in the HOB. I prefer the second. Established practice is to use a new GUID. We should stick to that. take care, Gerd