All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com,
	ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	eddie.dong@intel.com, tim@xen.org, xen-devel@lists.xen.org,
	jun.nakajima@intel.com, keir@xen.org, ian.jackson@eu.citrix.com
Subject: Re: [PATCH] xen/vm_event: Clean up control-register-write vm_events
Date: Tue, 12 May 2015 21:38:01 +0300	[thread overview]
Message-ID: <55524889.3020604@bitdefender.com> (raw)
In-Reply-To: <55523E39.9080904@citrix.com>

On 05/12/2015 08:54 PM, Andrew Cooper wrote:
> On 12/05/15 17:52, Razvan Cojocaru wrote:
>> On 05/12/2015 06:53 PM, Andrew Cooper wrote:
>>> On 12/05/15 16:50, Andrew Cooper wrote:
>>>> On 12/05/15 16:49, Razvan Cojocaru wrote:
>>>>> On 05/12/2015 06:35 PM, Jan Beulich wrote:
>>>>>>>>> On 12.05.15 at 16:58, <rcojocaru@bitdefender.com> wrote:
>>>>>>> +/* Supported values for the vm_event_write_ctrlreg index. */
>>>>>>> +#define X86_CR0     (1 << 0)
>>>>>>> +#define X86_CR3     (1 << 1)
>>>>>>> +#define X86_CR4     (1 << 2)
>>>>>>> +#define X86_XCR0    (1 << 3)
>>>>>> These names, being put in the public interface, are way too generic.
>>>>> I've copied them from Andrew Cooper's suggestion in the previous thread,
>>>>> hopefully he'll chime in. I'm happy to rename / move them if so desired.
>>>> I intended something like VM_EVENT_ARCH_X86_CR0 etc.
>>> or perhaps slightly more specific to ctrl_reg read/write.
>> VM_EVENT_ARCH_X86_MOV_TO_CR0? Or maybe VM_EVENT_WRITE_ARCH_X86_CR0?
> 
> Are there any other events which could plausibly use the same indicies? 
> Monitoring ctrl_reg reads perhaps ?

I see what you mean, those could be reused for reads and result in less
verbosity in the vm_event.h header.

I'll stick to VM_EVENT_ARCH_X86_CR0 and so on (unless requested
otherwise), I don't have a better naming convention (I guess if we need
to emphasize that something is being done to said control register we
could call them VM_EVENT_ACCESS_ARCH_X86_CR0, but that's more verbose
and IMHO not much better).

>> There's something else that should also be clarified: I've renamed the
>> vm_event.h struct to vm_event_write_ctrlreg, and changed
>> monitor.mov_to_cr* to monitor.write_ctrlreg*, but left
>> xc_monitor_mov_to_cr() in libxc, and mov_to_cr in the domctl part (I
>> thought it fit with mov_to_msr(), etc.). Should I change that to
>> write_ctrlreg as well? On the one hand, mov_to_cr seems to be consistent
>> with the previous interface, and on the other it's not consistent with
>> the name changes the patch has made.
> 
> Any API/ABI changes in this area are fine until 4.6 is released, and a
> consistent interface is much preferred.

Understood. Then I'll rename xc_monitor_mov_to_cr() to
xc_monitor_write_ctrlreg(), since vm_event_write_ctrlreg has been
previously requested. I'll also rename
XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR to
XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG, and VM_EVENT_REASON_MOV_TO_CR to
VM_EVENT_REASON_WRITE_CTRLREG.

I'm reading your reply to mean that I should also rename
xc_monitor_mov_to_msr() to xc_monitor_write_msr(), and do similar things
to the respective vm_event struct, VM_EVENT_REASON_MOV_TO_MSR and so on.
Is that correct?


Thanks,
Razvan

  reply	other threads:[~2015-05-12 18:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 14:58 [PATCH] xen/vm_event: Clean up control-register-write vm_events Razvan Cojocaru
2015-05-12 15:35 ` Jan Beulich
2015-05-12 15:49   ` Razvan Cojocaru
2015-05-12 15:50     ` Andrew Cooper
2015-05-12 15:53       ` Andrew Cooper
2015-05-12 16:52         ` Razvan Cojocaru
2015-05-12 17:54           ` Andrew Cooper
2015-05-12 18:38             ` Razvan Cojocaru [this message]
2015-05-13  6:06               ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55524889.3020604@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.