> -----Original Message----- > From: Eduardo Habkost [mailto:ehabkost@xxxxxxxxxx] > Sent: Tuesday, May 22, 2018 9:04 AM > To: Moger, Babu <Babu.Moger@xxxxxxx> > Cc: Duran, Leo <leo.duran@xxxxxxx>; mst@xxxxxxxxxx; > marcel.apfelbaum@xxxxxxxxx; pbonzini@xxxxxxxxxx; rth@xxxxxxxxxxx; > mtosatti@xxxxxxxxxx; qemu-devel@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; > kash@xxxxxxxxxxxxxx; geoff@xxxxxxxxxxxxxxx > 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.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). Ok. Will change the name to bit generic for now and keep the defaults as in EPYC. > > -- > Eduardo
