On Mon, Jul 6, 2015 at 1:29 PM, Razvan Cojocaru <rcojoc...@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. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
