On 06/07/15 18:36, Lengyel, Tamas wrote: > > > On Mon, Jul 6, 2015 at 1:29 PM, Razvan Cojocaru > <rcojoc...@bitdefender.com <mailto: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.
Very much +1 to this suggestion. ~Andrew
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
