Avi Kivity wrote: > Alexander Graf wrote: >> Avi Kivity wrote: >>> Alexander Graf wrote: >>>> Netware writes and reads to the DEBUGCTL and LAST*IP MSRs without >>>> further checks and is really confused to receive a #GP during that. >>>> To make it happy we should just make them stubs, which is exactly >>>> what SVM already does. >>>> >>>> To support VMX too, I put these in the generic code. Maybe the SVM >>>> code could be cleaned up to use generic code too. >>>> >>> >>> Please add a pr_unimpl() when bits that cause a real processor to do >>> something are set. >> >> Like this? I also removed the set handlers for the *IP MSRs, as these >> are read only and made it only handle debug bits, no perfmon bits. >> > > With a changelog entry. ok. > >> + pr_unimpl(vcpu, "%s: MSR_IA32_DEBUGCTLMSR 0x%llx, nop\n", >> + __func__, data); >> > > We can avoid the printout if data == 0, since we support that case fully. I was thinking a lot about that. Even though we support data == 0, usually the kernel log output is useful for people trying to find if something is cause a problem. If they see that DEBUGCTL gets set, but won't see it getting unset, they'd get confused IMHO. So the current behavior is on purpose, but if you oppose to that idea, please tell me. --------------- Netware writes to DEBUGCTL and reads from the DEBUGCTL and LAST*IP MSRs without further checks and is really confused to receive a #GP during that. To make it happy we should just make them stubs, which is exactly what SVM already does. Writes to DEBUGCTL that are vendor-specific are resembled to behave as if the virtual CPU does not know them. Signed-off-by: Alexander Graf