All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: "Lengyel, Tamas" <tlengyel@novetta.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	keir@xen.org, Jan Beulich <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] vm_event: Rename MEM_ACCESS_EMULATE and MEM_ACCESS_EMULATE_NOWRITE
Date: Tue, 7 Jul 2015 17:15:31 +0300	[thread overview]
Message-ID: <559BDF03.6040808@bitdefender.com> (raw)
In-Reply-To: <CAD33N+5Rf=S2dWOBOQkpcAANsNubGZuuNKD9hXrUC5iQDDT5rw@mail.gmail.com>

On 07/07/2015 05:08 PM, Lengyel, Tamas wrote:
> 
> 
> On Tue, Jul 7, 2015 at 9:54 AM, Razvan Cojocaru
> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
> 
>     By naming, placing and bit shift convention, it could be taken as
>     implied that MEM_ACCESS_EMULATE and MEM_ACCESS_EMULATE_NOWRITE are
>     mem_access event specific flags (instead of being generally
>     applicable as vm_event flags). This patch renames them to
>     VM_EVENT_FLAG_EMULATE and VM_EVENT_FLAG_EMULATE_NOWRITE
>     respectively, and uses bit shifts following the rest of the
>     VM_EVENT_FLAG_ constants.
> 
>     Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com
>     <mailto:rcojocaru@bitdefender.com>>
>     ---
>      xen/arch/x86/mm/p2m.c         |    4 ++--
>      xen/include/public/vm_event.h |   26 +++++++++++++-------------
>      2 files changed, 15 insertions(+), 15 deletions(-)
> 
>     diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>     index 6b39733..4c49369 100644
>     --- a/xen/arch/x86/mm/p2m.c
>     +++ b/xen/arch/x86/mm/p2m.c
>     @@ -1418,7 +1418,7 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
>                                        const vm_event_response_t *rsp)
>      {
>          /* Mark vcpu for skipping one instruction upon rescheduling. */
>     -    if ( rsp->flags & MEM_ACCESS_EMULATE )
>     +    if ( rsp->flags & VM_EVENT_FLAG_EMULATE )
>          {
>              xenmem_access_t access;
>              bool_t violation = 1;
>     @@ -1553,7 +1553,7 @@ bool_t p2m_mem_access_check(paddr_t gpa,
>     unsigned long gla,
>          if ( v->arch.vm_event.emulate_flags )
>          {
>              hvm_mem_access_emulate_one((v->arch.vm_event.emulate_flags &
>     -                                    MEM_ACCESS_EMULATE_NOWRITE) != 0,
>     +                                    VM_EVENT_FLAG_EMULATE_NOWRITE)
>     != 0,
> 
> 
> Now looking at this more closely - VM_EVENT_FLAG_EMULATE_NOWRITE doesn't
> get set on rsp->flags. As such, it would make sense to keep it as a
> separate define (simply VM_EVENT_EMULATE_NOWRITE?). IMHO VM_EVENT_FLAG_*
> defines should correspond to things set on the req/rsp->flags field.

It does get set, it's just not very obvious, but please see line 1468 below:

1417 void p2m_mem_access_emulate_check(struct vcpu *v,
1418                                   const vm_event_response_t *rsp)
1419 {
1420     /* Mark vcpu for skipping one instruction upon rescheduling. */
1421     if ( rsp->flags & MEM_ACCESS_EMULATE )
1422     {
1423         xenmem_access_t access;
1424         bool_t violation = 1;
1425         const struct vm_event_mem_access *data = &rsp->u.mem_access;
1426
1427         if ( p2m_get_mem_access(v->domain, data->gfn, &access) == 0 )
1428         {
1429             switch ( access )
1430             {
1431             case XENMEM_access_n:
1432             case XENMEM_access_n2rwx:
1433             default:
1434                 violation = data->flags & MEM_ACCESS_RWX;
1435                 break;

[...]

1462             case XENMEM_access_rwx:
1463                 violation = 0;
1464                 break;
1465             }
1466         }
1467
1468         v->arch.vm_event.emulate_flags = violation ? rsp->flags : 0;
1469     }
1470 }

With the right conditions, v->arch.vm_event.emulate_flags is assigned
rsp->flags, which does have VM_EVENT_EMULATE_NOWRITE set quite a lot for
us. :)


Thanks,
Razvan

  reply	other threads:[~2015-07-07 14:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07 13:54 [PATCH] vm_event: Rename MEM_ACCESS_EMULATE and MEM_ACCESS_EMULATE_NOWRITE Razvan Cojocaru
2015-07-07 14:08 ` Lengyel, Tamas
2015-07-07 14:15   ` Razvan Cojocaru [this message]
2015-07-07 15:00     ` Lengyel, Tamas

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=559BDF03.6040808@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tlengyel@novetta.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.