On 09/17/2015 04:37 PM, Andrew Cooper wrote: > On 17/09/15 14:20, Razvan Cojocaru wrote: >> On 09/17/2015 03:59 PM, Andrew Cooper wrote: >>> On 15/09/15 10:19, Razvan Cojocaru wrote: >>>> Previously, if vm_event emulation support was enabled, then REP >>>> optimizations were disabled when emulating REP-compatible >>>> instructions. This patch allows fine-tuning of this behaviour by >>>> providing a dedicated libxc helper function. >>>> >>>> Signed-off-by: Razvan Cojocaru <rcojoc...@bitdefender.com> >>> This disables all rep optimisations by default, so on its own is >>> inappropriate. >> REP optimizations are enabled by default. Emulate_each_rep is initially >> set to 0, when struct hvm_domain is being initialized, which means that >> REP optimizations are enabled. I've tested this and it does work, am I >> missing something? > > Oops - you are completely correct. I got the logic reversed in my > head. Sorry for the noise.
No problem at all, thanks for the review! >>> I am also not sure that an individual domctl subop is appropriate. Its >>> purpose is to undo a performance hit caused by introspection, so should >>> live as an introspection subop IMO. >> Do you mean xc_monitor_emulate_each_rep() instead of >> xc_domain_emulate_each_rep()? >> >> I've placed this in its own domctl subop because it's not introspection >> (or vm_event) specific. The change in >> xen/arch/x86/hvm/emulate.c enables / disables REP emulation >> optimizations regardless of whether there's a vm_event client or not. I >> thought this might come handy for somebody else too. > > I can't think of a rational reason for anyone to disable rep > optimisations for the sake of it. > > I am concerned about introducing options with which people can > needlessly shoot themselves in the foot. On the other hand, there are > already enough of those. Understood, in that case I'll move it to an xc_monitor_() function and add an extra check for that in emulate.c in V2 (unless anyone has an objection to that?). Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
