From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH V2] vm_event: Allow subscribing to write events for specific MSR-s Date: Thu, 14 Apr 2016 09:33:09 -0600 Message-ID: References: <1460524280-6902-1-git-send-email-rcojocaru@bitdefender.com> <20160413094726.GA2133@localhost.localdomain> <570E342F.5060606@bitdefender.com> <570E5E18.9050309@bitdefender.com> <570E5F4F.7070506@citrix.com> <570F64F3.7030604@bitdefender.com> <570FC34F02000078000E678A@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5508526702716737255==" Return-path: In-Reply-To: <570FC34F02000078000E678A@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich Cc: Kevin Tian , "wei.liu2@citrix.com" , Razvan Cojocaru , Andrew Cooper , Ian Jackson , Xen-devel , Jun Nakajima , Keir Fraser List-Id: xen-devel@lists.xenproject.org --===============5508526702716737255== Content-Type: multipart/alternative; boundary=001a11471aee8f8b7a0530739c63 --001a11471aee8f8b7a0530739c63 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 14, 2016 at 9:20 AM, Jan Beulich wrote: > >>> Razvan Cojocaru 04/14/16 11:37 AM >>> > >On 04/13/2016 06:05 PM, Tamas K Lengyel wrote: > >> > >> Yea, well then we need to introduce a new struct with a new subop to > >> pass the bitmask. I guess its a lesson in ABI design to leave some > >> wiggle room for future-proofing it (my bad). So I guess we can introduce > >> XEN_DOMCTL_MONITOR_OP_ENABLE_V2 and struct xen_domctl_monitor_op_v2 > >> where say expand the union to uint64_t just in case? > > > >I can do that, but it would seem that this is somewhat at odds with > >Andrew Cooper's perspective - he has stated that it's within the rules > >and the domctl can be changed without there being the need for > >XEN_DOMCTL_MONITOR_OP_ENABLE_V2. So this should be clarified, please, > >otherwise I'm incurring the risk of changing the code only to have to > >revert it later. > > You basically have two options - the new sub-op or changing the existing > one while (if not already done so in a dev cycle) bumping the domctl > interface version. If bumping the domctl version is not too much hassle I think that would be the easiest. Tamas --001a11471aee8f8b7a0530739c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 14, 2016 at 9:20 AM, Jan Beulich <jbeulich@suse.com>= ; wrote:
>>> Razvan Cojoc= aru <rcojocaru@bitdefender.= com> 04/14/16 11:37 AM >>>
>On 04/13/2016 06:05 PM, Tamas K Lengyel wrote:
>>
>> Yea, well then we need to introduce a new = struct with a new subop to
>> pass the bitmask. I guess its a lesson in ABI design to leave some=
>> wiggle room for future-proofing it (my bad). So I guess we can int= roduce
>> XEN_DOMCTL_MONITOR_OP_ENABLE_V2 and struct xen_domctl_monitor_op_v= 2
>> where say expand the union to uint64_t just in case?
>
>I can do that, but it would seem that this is somewhat at odds with
>Andrew Cooper's perspective - he has stated that it's within th= e rules
>and the domctl can be changed without there being the need for
>XEN_DOMCTL_MONITOR_OP_ENABLE_V2. So this should be clarified, please, >otherwise I'm incurring the risk of changing the code only to have = to
>revert it later.

You basically have two options - the new sub-op or changing the exis= ting
one while (if not already done so in a dev cycle) bumping the domctl
interface version.

If bumping the domctl ve= rsion is not too much hassle I think that would be the easiest.
<= br>
Tamas

--001a11471aee8f8b7a0530739c63-- --===============5508526702716737255== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============5508526702716737255==--