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

Reply via email to