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

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

[-- Attachment #1.1: Type: text/plain, Size: 2369 bytes --]

On 06/07/15 18:36, Lengyel, Tamas wrote:
>
>
> On Mon, Jul 6, 2015 at 1:29 PM, Razvan Cojocaru
> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> 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).
>
>     Just a thought,
>     Razvan
>
>
> I could see a new XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES making sense
> for this so userspace would get a definite yes/no for features
> available on the given platform. If the user then decides to ignore
> and attempt to use something not available, that would be on him.

Very much +1 to this suggestion.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 4484 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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