>>> On 15.02.16 at 18:17, <tleng...@novetta.com> wrote: > On Mon, Feb 15, 2016 at 10:06 AM, Jan Beulich <jbeul...@suse.com> wrote: >> >>> On 15.02.16 at 17:55, <tleng...@novetta.com> wrote: >> > All paths that end up using this dr7 value in vm_event have v==current, >> so >> > right now there is no caller to this function using dr7 where v!=current. >> > Future callers where v!=current could do so indeed. >> >> Well, first of all the vm_event consumers of this data are secondary. >> The primary consumer is the VM save logic, which runs with >> v != current. It just so happens that hvm_save_cpu_ctxt() already >> ignores that field and uses v->arch.debugreg[7] instead. Hence >> we're back to square one: How much of an overhead is the extra >> VMREAD (the data gathered by which the primary consumer has no >> use for)? > > > I don't have an answer to that but I don't think it's very significant. My > original intention was to introduce a separate hvm function to do this > saving of dr7 which was voted against by Andrew. I personally don't have a > use for dr7 at the moment either way.
Andrew, thoughts? (As usual, a single such unnecessary addition may not be noticable, but once we set a precedent, more might follow, until we get into the noticable range.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel