From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fTAPQ-0006FO-Ad for qemu-devel@nongnu.org; Wed, 13 Jun 2018 14:22:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fTAPL-0000AA-3b for qemu-devel@nongnu.org; Wed, 13 Jun 2018 14:22:16 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:42650 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fTAPK-00008R-Vn for qemu-devel@nongnu.org; Wed, 13 Jun 2018 14:22:11 -0400 Date: Wed, 13 Jun 2018 21:22:10 +0300 From: "Michael S. Tsirkin" Message-ID: <20180613211921-mutt-send-email-mst@kernel.org> References: <20180608205830.308627-1-mst@redhat.com> <20180612145605.50f64965@redhat.com> <20180612155708-mutt-send-email-mst@kernel.org> <20180612155803.4ca0d137@redhat.com> <20180612144922.GJ7451@localhost.localdomain> <20180613105543.32e58e99@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180613105543.32e58e99@redhat.com> Subject: Re: [Qemu-devel] [RFC untested PATCH] i386/cpu: make -cpu host support monitor/mwait List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Eduardo Habkost , qemu-devel@nongnu.org, Paolo Bonzini , Richard Henderson On Wed, Jun 13, 2018 at 10:55:43AM +0200, Igor Mammedov wrote: > On Tue, 12 Jun 2018 11:49:22 -0300 > Eduardo Habkost wrote: > > > On Tue, Jun 12, 2018 at 03:58:03PM +0200, Igor Mammedov wrote: > > [...] > > > > > > + if (xcc->host_cpuid_required && enable_cpu_pm) { > > > > > > + host_cpuid(5, 0, &cpu->mwait.eax, &cpu->mwait.ebx, > > > > > > + &cpu->mwait.ecx, &cpu->mwait.edx); > > > > > > + } > [...] > > > > > also max_x86_cpu_initfn() might be better place for filling it up. > > > > Why? > I've missed 'enable_cpu_pm' which is probably a property, > so yep it can't go into initfn. > > However if we not going to migrate this state or use outside of > cpu_x86_cpuid(), I don't see why we should add it to X86CPU state > and keep around. > We can query it on demand from cpu_x86_cpuid() like we do for > PMU leaf. We can do it but the annoying thing is that it spreads the info around as we also need to set CPUID_EXT_MONITOR. This way we set all the info in one place on realize. -- MST