On 27/05/18 04:56, Tian, Kevin wrote: >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Tuesday, May 22, 2018 7:21 PM >> >> Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, >> Xen >> updates a host MSR load list entry with the current hardware value of >> MSR_DEBUGCTL. This is wrong. >> >> On VMExit, hardware automatically resets MSR_DEBUGCTL to 0. The only >> case >> where different behaviour is needed is if Xen is debugging itself, and this >> needs setting up unconditionally for the lifetime of the VM. >> >> The `ler` command line boolean is the only way to configure any use of >> MSR_DEBUGCTL for Xen, so tie the host load list entry to this setting in >> construct_vmcs(). Any runtime update of Xen's MSR_DEBUGCTL setting >> requires >> more complicated synchronisation across all the running VMs. >> >> In the exceedingly common case, this avoids the unnecessary overhead of >> having >> a host load entry performing the same zeroing operation that hardware >> has >> already performed as part of the VMExit. > I didn't get "unnecessary overhead" part. if "ler' is disabled, as you > said earlier it's a bug to save/restore thus overhead doesn't matter.
The current behaviour (bug or otherwise), means that when ler is disabled, we end up with a host load list entry zeroing MSR_DEBUGCTL as soon as the guest first writes to the MSR. This causes unnecessary overhead because host load/save lists are slow. Irrespective, I've reworked this patch differently, to fully disentangle it from the EFER series. See patch 1 of my "x86/vmx: Misc fixes and improvements" series. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
