From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2] x86/vm_event: toggle singlestep from vm_event response Date: Mon, 6 Jul 2015 18:17:47 +0100 Message-ID: <559AB83B.4030907@citrix.com> References: <1435673482-10674-1-git-send-email-tlengyel@novetta.com> <5592A51E.1050200@citrix.com> <559ABA50020000780008CD3A@mail.emea.novell.com> <559AC0D3020000780008CDFD@mail.emea.novell.com> <559AB4E7.1040506@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0963785607676783252==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Lengyel, Tamas" , Razvan Cojocaru Cc: stefano.stabellini@citrix.com, keir@xen.org, Ian Campbell , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org --===============0963785607676783252== Content-Type: multipart/alternative; boundary="------------000803010002080908070607" --------------000803010002080908070607 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit 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. --------------000803010002080908070607 Content-Type: text/html; charset="windows-1252" Content-Length: 2091 Content-Transfer-Encoding: quoted-printable
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.=A0 Imagine if the user disabled the monitor trap feature in the BIOS=3F=A0 Userspace cannot possibly assume that because it is running on Intel, that the feature is present and usable.
--------------000803010002080908070607-- --===============0963785607676783252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0963785607676783252==--