[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V2] vm_event: Allow subscribing to write events for specific MSR-s



On 04/14/2016 06:33 PM, Tamas K Lengyel wrote:
> 
> 
> On Thu, Apr 14, 2016 at 9:20 AM, Jan Beulich <jbeulich@xxxxxxxx
> <mailto:jbeulich@xxxxxxxx>> wrote:
> 
>     >>> Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx
>     <mailto:rcojocaru@xxxxxxxxxxxxxxx>> 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.

Fair enough, I'll look into that option then.


Thanks,
Razvan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.