From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 1/5] xen/vm_event: Added support for XSETBV
 events
Date: Fri, 8 May 2015 10:10:58 +0100
Message-ID: <554C7DA2.50601@citrix.com>
References: <1430932352-4289-1-git-send-email-rcojocaru@bitdefender.com>
	<1430932352-4289-2-git-send-email-rcojocaru@bitdefender.com>
	<554BA904.2020501@citrix.com> <554C7C91.9040208@bitdefender.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <554C7C91.9040208@bitdefender.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Razvan Cojocaru <rcojocaru@bitdefender.com>, xen-devel@lists.xen.org
Cc: kevin.tian@intel.com, keir@xen.org, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, eddie.dong@intel.com, tim@xen.org, jbeulich@suse.com, Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com, wei.liu2@citrix.com, boris.ostrovsky@oracle.com, suravee.suthikulpanit@amd.com
List-Id: xen-devel@lists.xenproject.org

On 08/05/15 10:06, Razvan Cojocaru wrote:
> On 05/07/2015 09:03 PM, Andrew Cooper wrote:
>> In an effort to be architecture neutral, it might be an idea to have
>> something like
>>
>> struct vm_event_write_cr {
>>     uint64_t index;
>>     uint64_t old_val, new_val;
>> };
>>
>> And have a per-arch index of control registers, such as
>>
>> X86_CR0
>> X86_CR3
>> X86_CR4
>> X86_XCR0
>> ...
>> ARM32_$foo
> Staging's vm_event.h looks like this now:
>
>  63 /* CR0 was updated */
>  64 #define VM_EVENT_REASON_MOV_TO_CR0              4
>  65 /* CR3 was updated */
>  66 #define VM_EVENT_REASON_MOV_TO_CR3              5
>  67 /* CR4 was updated */
>  68 #define VM_EVENT_REASON_MOV_TO_CR4              6
>  69 /* An MSR was updated. */
>  70 #define VM_EVENT_REASON_MOV_TO_MSR              7
>
> Now, I can change VM_EVENT_REASON_MOV_TO_CR0 to
> VM_EVENT_REASON_MOV_TO_CR and use that for all CR and XCR events (well,
> only XCR0 now).
>
> Should VM_EVENT_REASON_MOV_TO_MSR become 5, or should we keep backward
> compatibility with prior clients and leave a gap?

For Tamas' cleanup series, we accepted ABI/API incompatible changes to
try and get the interface in order.  Therefore, until 4.6 is released,
anything goes, and I am very much in favour of more changes to clean the
arch-specific bits out of the common bits.

~Andrew