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> >> --- >> 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? 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. Jan
