On Thu, Jun 20, 2019 at 10:03:07AM +0800, Like Xu wrote: > On 2019/6/20 7:36, Eduardo Habkost wrote: > > On Wed, Jun 19, 2019 at 04:15:46PM -0300, Eduardo Habkost wrote: > > > On Wed, Jun 12, 2019 at 04:41:02PM +0800, Like Xu wrote: > > > > In guest CPUID generation process, the cpuid_min_level would be > > > > adjusted to > > > > the maximum passed value for basic CPUID configuration and it should > > > > not be > > > > restricted by the limited value returned from cpu_x86_cpuid(). After > > > > the basic > > > > cpu_x86_cpuid() loop is finished, the cpuid_0_entry.eax needs to be > > > > configured > > > > again by the last adjusted cpuid_min_level value. > > > > > > > > If a user wants to expose CPUID.1F by passing dies > 1 for any reason > > > > without > > > > host support, a per-cpu smp topology warning will appear but it's not > > > > blocked. > > > > > > > > Signed-off-by: Like Xu <like...@linux.intel.com> > > > > > > This code doesn't look at host CPUID at all, as far as I can see. > > > Isn't it simpler to just make cpuid_x86_cpuid() return the > > > correct data? > > > > I suggest the following change instead. > > > > Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> > > Hi Eduardo, > > Your code is more reasonable and concise than mine on this > so let's not break cpuid_x86_cpuid(). > > I'll remove the use of enable_cpuid_0x1f in next version, and should I > resend the patch series "Refactor cpu topo into machine properties" because > rebase-fix may distract you ?
"Refactor cpu topo" and patches 1-4 of this series are already queued on my machine-next branch. You can send the next version of the series using that branch as base: https://github.com/ehabkost/qemu.git machine-next -- Eduardo
