On Fri, Feb 11, 2022 at 10:59:10AM +0100, Jan Beulich wrote: > On 11.02.2022 10:40, Roger Pau Monné wrote: > > On Thu, Feb 10, 2022 at 03:55:52PM +0100, Jan Beulich wrote: > >> This avoids unnecessary (and always somewhat scary) log messages for the > >> recovered from #GP(0). > > > > Could we maybe get rid of the #GP messages for cases like this where we > > are explicitly probing for MSR presence? (ie: it's expected that we > > can get a #GP) > > This would mean some form of annotation of such RDMSR attempts (for > the recovery code to recognize in order to skip the printk()). Not > all rdmsr_safe() uses are, strictly speaking, probes, so I wouldn't > want to put such in rdmsr_safe() itself. > > In any event - quite a bit more work. Plus I'm not convinced it's a > good idea to suppress any such log messages. > > >> Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Roger Pau Monné <roger....@citrix.com> > >> --- > >> Perhaps even use "!= 6" in at least the CPUID-faulting family check? > > > > Likely, or else you would also need to check for family 11 (Knights > > Corner?) which doesn't seem to support PLATFORM_INFO either. > > I don't think Xen is able to run on these (likewise for IA64, which > iirc were surfacing as x86 model 7)? These are the co-processor ones, > aren't they? Right, Knights Corner uses a socket mount but it's still a co-processor. It was Knights Landing the first one that could be used as a host processor. > My question was more towards whether we would (wrongly) > exclude future processors when using != 6, if Intel decided to ever > make new CPUs with a family other than 6. In the case here I think we should only avoid the probe for family 0xf. Newer families (or even models on family 6 not supporting PLATFORM_INFO) will just get a #GP message which is OK I think, we could fix that in due time. It's better to get a #GP message for probing than to just skip detection of CPUID faulting on unknown newer families IMO. Thanks, Roger.
