From mboxrd@z Thu Jan 1 00:00:00 1970 From: Babu Moger Subject: Re: [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC CPU Date: Tue, 12 Jun 2018 14:46:51 -0500 Message-ID: <39f328af-a9c1-15bb-653e-9456b045768d@amd.com> References: <1528498581-131037-1-git-send-email-babu.moger@amd.com> <1528498581-131037-4-git-send-email-babu.moger@amd.com> <20180611205030.GW7451@localhost.localdomain> <20180611211026.GA7451@localhost.localdomain> <20180612174021.GL7451@localhost.localdomain> <20180612190554.GO7451@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "geoff@hostfission.com" , "kvm@vger.kernel.org" , "mst@redhat.com" , "kash@tripleback.net" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "pbonzini@redhat.com" , Jiri Denemark , "rth@twiddle.net" To: Eduardo Habkost Return-path: In-Reply-To: <20180612190554.GO7451@localhost.localdomain> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel2=m.gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On 06/12/2018 02:05 PM, Eduardo Habkost wrote: > On Tue, Jun 12, 2018 at 06:38:08PM +0000, Moger, Babu wrote: > [...] >>> I'm starting to think that enabling TOPOEXT automatically is >>> adding too much complexity and compatibility problems, and it's >>> better to leave this task to management software. >>> >>> The main problem here is: >>> >>> This works today with QEMU 2.12 + Linux <=3D 4.15: >>> $ $QEMU -machine pc -cpu EPYC,enforce -smp >>> 8,sockets=3D2,cores=3D2,threads=3D2" >>> and must keep working with QEMU 3.0 and Linux <=3D 4.15. >>> >>> In addition to that, the results for: >>> $ $QEMU -machine pc-q35-3.0 -cpu EPYC,enforce [...] >>> must be deterministic and expose exactly the same CPUID data even >>> if host hardware or software changes, as long as the QEMU >>> command-line is the same. >>> >>> Do you see a way to fulfill those two constraints while making >>> "-machine pc-q35-3.0 -cpu EPYC" enable TOPOEXT automatically? >>> >> Now(setting feature before x86_cpu_expand_features), enabling >> TOPOEXT appears to work fine. > What about the above constraints? Are you really fulfilling > them? > > This one is tricky: > > ] This works today with QEMU 2.12 + Linux <=3D 4.15: > ] $ $QEMU -machine pc -cpu EPYC,enforce -smp 8,sockets=3D2,cores=3D2,th= reads=3D2" > ] and must keep working with QEMU 3.0 and Linux <=3D 4.15. =C2=A0This works fine on kernel <=3D 4.15 with some warnings(-smp=20 8,sockets=3D2,cores=3D2,threads=3D2 -cpu EPYC). qemu-system-x86_64: warning: host doesn't support requested feature:=20 CPUID.80000001H:EDX.rdtscp [bit 27] qemu-system-x86_64: warning: host doesn't support requested feature:=20 CPUID.80000001H:ECX.topoext [bit 22] qemu-system-x86_64: This family of AMD CPU doesn't support=20 hyperthreading(2). Please configure -smp options properly or try=20 enabling topoext feature. continues.. > > If we enable TOPOEXT unconditionally, the command-line won't work > with Linux <=3D 4.15. > > If we enable TOPOEXT only if the kernel returns TOPOEXT on > GET_SUPPORTED_CPUID, we break the second constraint: > > ] The results for: > ] $ $QEMU -machine pc-q35-3.0 -cpu EPYC,enforce [...] > ] must be deterministic and expose exactly the same CPUID data even > ] if host hardware or software changes, as long as the QEMU > ] command-line is the same. > This fails on kernel=C2=A0 <=3D 4.15 with following messages((-smp=20 8,sockets=3D2,cores=3D2,threads=3D2 -cpu EPYC,enforce). qemu-system-x86_64: warning: host doesn't support requested feature:=20 CPUID.80000001H:EDX.rdtscp [bit 27] qemu-system-x86_64: warning: host doesn't support requested feature:=20 CPUID.80000001H:ECX.topoext [bit 22] qemu-system-x86_64: Host doesn't support requested features exits.. What do you think our options are here?