> -----Original Message----- > From: Eduardo Habkost [mailto:ehabk...@redhat.com] > Sent: Tuesday, May 22, 2018 9:04 AM > To: Moger, Babu <babu.mo...@amd.com> > Cc: Duran, Leo <leo.du...@amd.com>; m...@redhat.com; > marcel.apfelb...@gmail.com; pbonz...@redhat.com; r...@twiddle.net; > mtosa...@redhat.com; qemu-devel@nongnu.org; k...@vger.kernel.org; > k...@tripleback.net; ge...@hostfission.com > Subject: Re: [PATCH v10 2/5] i386: Populate AMD Processor Cache > Information for cpuid 0x8000001D > > On Tue, May 22, 2018 at 01:32:52PM +0000, Moger, Babu wrote: > > > > > -----Original Message----- > > > From: Duran, Leo > > > Sent: Monday, May 21, 2018 8:32 PM > > > To: Moger, Babu <babu.mo...@amd.com>; m...@redhat.com; > > > marcel.apfelb...@gmail.com; pbonz...@redhat.com; r...@twiddle.net; > > > ehabk...@redhat.com; mtosa...@redhat.com > > > Cc: qemu-devel@nongnu.org; k...@vger.kernel.org; > k...@tripleback.net; > > > ge...@hostfission.com > > > Subject: RE: [PATCH v10 2/5] i386: Populate AMD Processor Cache > > > Information for cpuid 0x8000001D > > > > > > Babu, > > > > > > If num_sharing_l3_cache() uses MAX_NODES_EPYC, then that function > It’s > > > EPYC specific. > > > > > > An alternative would be to use a data member (e.g., > > > max_nodes_per_socket)) that get initialized (via another helper > function) to > > > MAX_NODES_EPYC. > > > > Thanks Leo. Let me see how we can handle this. This requires changes in > generic > > Data structure which I tried to avoid here. I will wait for all the > > comments > for whole > > series before making this change. Note that right now, this feature is only > enabled > > for EPYC. Yes. I know this could this in future. > > We just need a reasonable default, by now, and it can even be the > same value used on EPYC. This default just need to generate > reasonable results for other cases that don't match real hardware > (like cores=32 or cores=12).
Ok. Will change the name to bit generic for now and keep the defaults as in EPYC. > > -- > Eduardo
