RE: [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC CPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx]
> On Behalf Of Babu Moger
> Sent: Tuesday, June 12, 2018 2:47 PM
> To: Eduardo Habkost <ehabkost@xxxxxxxxxx>
> Cc: mst@xxxxxxxxxx; marcel.apfelbaum@xxxxxxxxx; pbonzini@xxxxxxxxxx;
> rth@xxxxxxxxxxx; mtosatti@xxxxxxxxxx; qemu-devel@xxxxxxxxxx;
> kvm@xxxxxxxxxxxxxxx; kash@xxxxxxxxxxxxxx; geoff@xxxxxxxxxxxxxxx; Jiri
> Denemark <jdenemar@xxxxxxxxxx>
> Subject: Re: [PATCH v13 3/5] i386: Enable TOPOEXT feature on AMD EPYC
> CPU
> 
> 
> 
> 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 <= 4.15:
> >>>    $ $QEMU -machine pc -cpu EPYC,enforce -smp
> >>> 8,sockets=2,cores=2,threads=2"
> >>> and must keep working with QEMU 3.0 and Linux <= 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 <= 4.15:
> > ]   $ $QEMU -machine pc -cpu EPYC,enforce -smp
> 8,sockets=2,cores=2,threads=2"
> > ] and must keep working with QEMU 3.0 and Linux <= 4.15.
>   This works fine on kernel <= 4.15 with some warnings(-smp
> 8,sockets=2,cores=2,threads=2 -cpu EPYC).
> 
> qemu-system-x86_64: warning: host doesn't support requested feature:
> CPUID.80000001H:EDX.rdtscp [bit 27]
> qemu-system-x86_64: warning: host doesn't support requested feature:
> CPUID.80000001H:ECX.topoext [bit 22]
> qemu-system-x86_64: This family of AMD CPU doesn't support
> hyperthreading(2). Please configure -smp options properly or try
> enabling topoext feature.
> continues..
> >
> > If we enable TOPOEXT unconditionally, the command-line won't work
> > with Linux <= 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  <= 4.15 with following messages((-smp
> 8,sockets=2,cores=2,threads=2 -cpu EPYC,enforce).
> qemu-system-x86_64: warning: host doesn't support requested feature:
> CPUID.80000001H:EDX.rdtscp [bit 27]
> qemu-system-x86_64: warning: host doesn't support requested feature:
> 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?

Should we drop automatic topoext completely and move forward? What are your thoughts?





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux