On Wed, Aug 26, 2020 at 02:38:49PM +0200, Igor Mammedov wrote: > On Fri, 21 Aug 2020 17:12:19 -0500 > Babu Moger <babu.mo...@amd.com> wrote: > > > To support some of the complex topology, we introduced EPYC mode apicid > > decode. > > But, EPYC mode decode is running into problems. Also it can become quite a > > maintenance problem in the future. So, it was decided to remove that code > > and > > use the generic decode which works for majority of the topology. Most of the > > SPECed configuration would work just fine. With some non-SPECed user inputs, > > it will create some sub-optimal configuration. > > Here is the discussion thread. > > https://lore.kernel.org/qemu-devel/c0bcc1a6-1d84-a6e7-e468-d5b437c1b...@amd.com/ > > > > This series removes all the EPYC mode specific apicid changes and use the > > generic > > apicid decode. > > the main difference between EPYC and all other CPUs is that > it requires numa configuration (it's not optional) > so we need an extra patch on top of this series to enfoce that, i.e: > > if (epyc && !numa) > error("EPYC cpu requires numa to be configured") > > I think there was a patch in previous revisions that aimed for this. > Simplest form would be above snippet. > > More complex one, would be moving auto_enable_numa from MachineClass to > MachineState so we can change it at runtime if EPYC is used. That should > take care of use case where user hasn't provided -numa.
This sounds like a good solution. It actually sounds simpler than the alternatives (which just move the complexity to other components). We can keep MachineClass::auto_enable_numa as is, and just use it to initialize the default value of MachineState::auto_enable_numa. -- Eduardo
