From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fTApu-00023v-TZ for qemu-devel@nongnu.org; Wed, 13 Jun 2018 14:49:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fTApr-0007I0-JF for qemu-devel@nongnu.org; Wed, 13 Jun 2018 14:49:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58940) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fTApr-0007Ey-Am for qemu-devel@nongnu.org; Wed, 13 Jun 2018 14:49:35 -0400 Date: Wed, 13 Jun 2018 15:49:28 -0300 From: Eduardo Habkost Message-ID: <20180613184928.GI7451@localhost.localdomain> References: <20180612174021.GL7451@localhost.localdomain> <20180612190554.GO7451@localhost.localdomain> <39f328af-a9c1-15bb-653e-9456b045768d@amd.com> <20180613171820.GC7451@localhost.localdomain> <20180613181730.GG7451@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC CPU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Moger, Babu" Cc: "mst@redhat.com" , "marcel.apfelbaum@gmail.com" , "pbonzini@redhat.com" , "rth@twiddle.net" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "kash@tripleback.net" , "geoff@hostfission.com" , Jiri Denemark On Wed, Jun 13, 2018 at 06:21:58PM +0000, Moger, Babu wrote: > > > > -----Original Message----- > > From: Eduardo Habkost [mailto:ehabkost@redhat.com] > > Sent: Wednesday, June 13, 2018 1:18 PM > > To: Moger, Babu > > Cc: mst@redhat.com; marcel.apfelbaum@gmail.com; pbonzini@redhat.com; > > rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org; > > kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com; Jiri > > Denemark > > Subject: Re: [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC > > CPU > > > > On Wed, Jun 13, 2018 at 06:10:30PM +0000, Moger, Babu wrote: > > > > -----Original Message----- > > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com] > > > > Sent: Wednesday, June 13, 2018 12:18 PM > > > > To: Moger, Babu > > > > Cc: mst@redhat.com; marcel.apfelbaum@gmail.com; > > pbonzini@redhat.com; > > > > rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org; > > > > kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com; Jiri > > > > Denemark > > > > Subject: Re: [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC > > > > CPU > > > > > > > > On Wed, Jun 13, 2018 at 04:52:18PM +0000, Moger, Babu wrote: > > > > [...] > > > > > > What do you think our options are here? > > > > > > > > > > Should we drop automatic topoext completely and move forward? > > > > > What are your thoughts? > > > > > > > > Let's drop automatic topoext by now, and see if we find solutions > > > > later. I don't want to hold the rest of the patches because of > > > > this. > > > > > > Ok. I will drop topoext. > > > > > > > > > > > I'm thinking we could simply make kvm_arch_get_supported_cpuid() > > > > always return TOPOEXT on AMD CPUs, because the feature flag don't > > > > really depend on any KVM code to work (is that correct?). > > > > > > Yes, that is correct. I don't see any dependent code on TOPOEXT in KVM > > driver. > > > > > > Ok. Let me add TOPOEXT flag for all the AMD cpus and see how it goes. > > > > Hmm, this could actually solve all of our problems, then: > > > > We can forget about auto-topoext: just add TOPOEXT in > > kvm_arch_get_supported_cpuid(), add TOPOEXT unconditionally to > > the CPU models where you are interested into (EPYC only?), and > > add topoext=off to pc-2.12 compat_props. > > > > Ok Sure. Sorry, I forgot we still need to decide what to do if TOPOEXT is enabled in the CPU model (or command-line) but the -smp options are not compatible with it. In other words, what should guest see on CPUID if using: "-machine pc-q35-3.0 -cpu EPYC -smp 64,cores=64" or: "-machine pc-q35-3.0 -cpu Opteron_G5,+topoext -smp 64,cores=64" I wonder what would happen if we just return zeroes on CPUID[0x800001E] if !topology_supports_topoext(), instead of trying to clear/set TOPOEXT depending on the -smp option? It would make things much simpler for QEMU and libvirt. -- Eduardo