On 06/06/18 11:34, Roger Pau Monné wrote: > On Mon, Jun 04, 2018 at 02:59:07PM +0100, Andrew Cooper wrote: >> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c >> index 528aff1..0872466 100644 >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -3,6 +3,7 @@ >> #include <xen/delay.h> >> #include <xen/smp.h> >> #include <asm/current.h> >> +#include <asm/debugreg.h> >> #include <asm/processor.h> >> #include <asm/xstate.h> >> #include <asm/msr.h> >> @@ -823,10 +824,13 @@ void cpu_init(void) >> /* Ensure FPU gets initialised for each domain. */ >> stts(); >> >> - /* Clear all 6 debug registers: */ >> -#define CD(register) asm volatile ( "mov %0,%%db" #register : : "r"(0UL) ); >> - CD(0); CD(1); CD(2); CD(3); /* no db4 and db5 */; CD(6); CD(7); >> -#undef CD >> + /* Reset debug registers: */ >> + write_debugreg(0, 0); >> + write_debugreg(1, 0); >> + write_debugreg(2, 0); >> + write_debugreg(3, 0); >> + write_debugreg(6, X86_DR6_DEFAULT); >> + write_debugreg(7, X86_DR7_DEFAULT); > AFAICT you are writing the default init values, which should be there > already. So this is just a safebelt in case the CPU is initialized > with some bogus DR values?
Yes. Its just to sanitise state. >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >> index c23983c..10415e6 100644 >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -40,6 +40,7 @@ >> #include <asm/shadow.h> >> #include <asm/hap.h> >> #include <asm/current.h> >> +#include <asm/debugreg.h> >> #include <asm/e820.h> >> #include <asm/io.h> >> #include <asm/regs.h> >> @@ -3907,7 +3908,10 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t >> cs, uint16_t ip) >> v->arch.user_regs.rflags = X86_EFLAGS_MBS; >> v->arch.user_regs.rdx = 0x00000f00; >> v->arch.user_regs.rip = ip; >> - memset(&v->arch.debugreg, 0, sizeof(v->arch.debugreg)); >> + >> + memset(&v->arch.debugreg, 0, sizeof(v->arch.debugreg) - 16); > For clarity I would use offsetof here, or rather just zero the whole > thing. This is not a hot path, so I would prefer to avoid the > optimization. This particular expression doesn't survive past patch 6. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
