Re: [PATCH v2] x86/vm_event: toggle singlestep from vm_event response

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 06/07/15 18:29, Razvan Cojocaru wrote:
> On 07/06/2015 08:17 PM, Andrew Cooper wrote:
>> On 06/07/15 18:08, Lengyel, Tamas wrote:
>>>     Having said that (and with the understading that it is beyond the
>>>     scope
>>>     of this patch), a way to validate things like these is a good idea. I
>>>     wonder if, in a future patch, we could not have ./configure detect
>>>     these
>>>     things and simply disable the relevant VM_EVENT_FLAG constants with
>>>     #if(n)defs, for example. That way, you wouldn't be able to compile
>>>     code
>>>     that wouldn't work silently on platforms where that is the case.
>>>
>>>
>>> It would be something worth investigating, definitely.
>> It would be mad to conditionally compile out code based on the features
>> or lackthereof of the build machine.
>>
>> For bits like this, there must be active negotiation between userspace
>> and the running hypervisor to see what it can support.  Imagine if the
>> user disabled the monitor trap feature in the BIOS?  Userspace cannot
>> possibly assume that because it is running on Intel, that the feature is
>> present and usable.
> Fair enough, but it would at least compile out the code for machines
> where it _definitely_ won't work, and on those where it _might_ work it
> would just continue to do nothing silently (or perhaps with the
> hypervisor logging an error) once the user disables the monitor trap
> flag in the BIOS, so while not perfect it's still something, with the
> benefit of less development overhead than a full-on system for
> negotiating hypervisor capabilities (which is indeed the safest and
> exhaustive course of action).

That is fine if you are compiling a custom binary for your own use.

It is not fine if you are a distro attempting to provide a binary for
general use by a broad set of users.  Code in tree should cater to this
latter category.

Compile-time feature detection like this is a step backwards from the
1993 days when mechanisms like `cpuid` were introduced.  A one-time
query of available features is nothing like as much overhead as having
to recompile the binary.

~Andrew