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.Moger@xxxxxxx>; mst@xxxxxxxxxx; > > marcel.apfelbaum@xxxxxxxxx; pbonzini@xxxxxxxxxx; rth@xxxxxxxxxxx; > > ehabkost@xxxxxxxxxx; mtosatti@xxxxxxxxxx > > Cc: qemu-devel@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; kash@xxxxxxxxxxxxxx; > > geoff@xxxxxxxxxxxxxxx > > 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). -- Eduardo
