On Sat, 20 Nov 2021, Dave Voutila wrote: > Philip Guenther <pguent...@proofpoint.com> writes: > > > On Wed, 17 Nov 2021, Josh Grosse wrote: > > ... > >> vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported > >> vmx_handle_cr: mov to cr0 @ 100149e, data=0x80010031 > >> vmx_handle_wrmsr: wrmsr exit, msr=0x8b, discarding data written from > >> guest=0x0:0x0 > >> vmx_handle_wrmsr: wrmsr exit, msr=0x8b, discarding data written from > >> guest=0x0:0x0 > >> vmm_handle_cpuid: unsupported rax=0x40000100 > >> vmm_handle_cpuid: invalid cpuid input leaf 0x15, guest > >> rip=0xffffffff81c89979 - resetting to 0xd > >> vmm_handle_cpuid: function 0x06 (thermal/power mgt) not supported > >> vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported > > > > The cpuid leaf clamping added in vmm.c rev 1.185 broke the "fake up to > > cpuid 0x15 if tsc_is_invariant" logic added in vmm.c rev 1.182 > > I believe something's amiss here, but I think it's a coincidence. ...
Sure; I didn't see my diff as addressing Josh's problem**: I merely noticed those debug messages and thought "what's that about?" I don't understand most of vmm (and certainly not its I/O emulation) enough to really review your diff for correctness; sorry. Philip ** yeah, Josh says it _does_ make fdc vanish, but I don't understand why. Maybe the problem requires not just the bogus I/O return you're addressing but also that the guests's clock gets screwed up from thinking it can use TSC but then it can't get cpuid(0x15) values and that results in it, uh, I guess up, I don't know. <shrug>
