On 26/10/18 16:15, Jan Beulich wrote: >>>> On 15.10.18 at 12:36, <andrew.coop...@citrix.com> wrote: >> @@ -970,9 +972,13 @@ int arch_set_info_guest( >> v->arch.pv.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(v, cr4) : >> real_cr4_to_pv_guest_cr4(mmu_cr4_features); >> >> - memset(v->arch.debugreg, 0, sizeof(v->arch.debugreg)); >> - for ( i = 0; i < 8; i++ ) >> - (void)set_debugreg(v, i, c(debugreg[i])); >> + memset(v->arch.dr, 0, sizeof(v->arch.dr)); >> + v->arch.dr6 = v->arch.dr7 = v->arch.pv.dr7_emul = 0; > Considering your earlier change to correct initial values, wouldn't > it be better to use the (non-zero) default values here too, even > if due to ... > >> + for ( i = 0; i < ARRAY_SIZE(v->arch.dr); i++ ) >> + set_debugreg(v, i, c(debugreg[i])); >> + set_debugreg(v, 6, c(debugreg[6])); >> + set_debugreg(v, 7, c(debugreg[7])); > ... this doing so might be benign at this point in time?
Actually, now you point this out, it is a latent bug. Initialising dr6 to 0 here means that by the end of the series, the DR6 merge logic will leave RTM asserted. > > With or without this adjustment > Reviewed-by: Jan Beulich <jbeul...@suse.com> Thanks. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
