Re: [Xen-devel] [PATCH 1/2] xen, libxc: Introduced XEN_DOMCTL_emulate_each_rep

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 <rcojocaru@xxxxxxxxxxxxxxx>
>> 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.

>
>> 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.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel