All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 02/20] PVH xen: add XENMEM_add_to_physmap_range
Date: Fri, 17 May 2013 15:24:08 -0700	[thread overview]
Message-ID: <20130517152408.6ff4a0c4@mantra.us.oracle.com> (raw)
In-Reply-To: <5195EC3C02000078000D6E7D@nat28.tlf.novell.com>

On Fri, 17 May 2013 07:37:16 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 17.05.13 at 01:56, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Thu, 16 May 2013 08:21:16 +0100
> > "Jan Beulich" <JBeulich@suse.com> wrote:
> > 
> >> >>> On 16.05.13 at 01:05, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> >>> wrote:
> >> > On Wed, 15 May 2013 10:58:43 +0100
> >> > "Jan Beulich" <JBeulich@suse.com> wrote:
> >> > 
> >> >xatpr->size-1, 1) )
> >> 
> >> ... you can read directly into the respective xatp fields here.
> > 
> > I could, but it makes the lines long/wrap in the if statement
> > making the code
> > harder to read IMO. The compiler should do exact same thing in both
> > cases.
> 
> I'm afraid it's not permitted to do so because of the addresses of
> the variables being taken and, through some macro levels, passed
> to global functions.
> 
> > If it really bothers you, I can change it.
> 
> It's certainly a matter of taste to some degree, but to me it's
> inefficient code (unless you could prove at least modern gcc indeed
> doing said optimization despite the use of the & operator) and
> would sooner or later (once stumbling across that code again)
> prompt me to submit a cleanup patch...

Modern compilers are amazing, it generates pretty much the same code, 
slightly different ordering, and only two instructions are different:

NEW (meaning not using local variables):

        if ( copy_from_guest_offset(&xatp.idx, xatpr->idxs, xatpr->size-1, 1)
             || copy_from_guest_offset(&xatp.gpfn, xatpr->gpfns, xatpr->size-1,
                                       1) )
            return -EFAULT;


0xffff82c4c017198b <xenmem_add_to_physmap_range+31>:    mov    %rax,%r12
0xffff82c4c017198e <xenmem_add_to_physmap_range+34>:    and    %rsp,%r12
0xffff82c4c0171991 <xenmem_add_to_physmap_range+37>:    lea    -0x50(%rbp),%r15
0xffff82c4c0171995 <xenmem_add_to_physmap_range+41>:    lea    0x8(%r15),%rdx
0xffff82c4c0171999 <xenmem_add_to_physmap_range+45>:    mov    %rdx,-0x58(%rbp)
0xffff82c4c017199d <xenmem_add_to_physmap_range+49>:    mov    %r12,%r13

0xffff82c4c01719a0 <xenmem_add_to_physmap_range+52>:    lea    0x10(%r15),%rdx
0xffff82c4c01719a0 <xenmem_add_to_physmap_range+52>:    lea    -0x60(%rbp),%rdx
                      ^^^^^^^^^ Above is OLD with local variables.

0xffff82c4c01719a4 <xenmem_add_to_physmap_range+56>:    mov    %rdx,-0x60(%rbp)
0xffff82c4c01719a8 <xenmem_add_to_physmap_range+60>:    mov    %r12,%r14
0xffff82c4c01719ab <xenmem_add_to_physmap_range+63>:    lea    -0x34(%rbp),%rdx
0xffff82c4c01719af <xenmem_add_to_physmap_range+67>:    mov    %rdx,-0x70(%rbp)
0xffff82c4c01719b3 <xenmem_add_to_physmap_range+71>:    mov    %r12,-0x78(%rbp)
0xffff82c4c01719b7 <xenmem_add_to_physmap_range+75>:    jmpq   0xffff82c4c0171b6a <xenmem_add_to_physmap_range+510 at mm.c:4685>
0xffff82c4c01719bc <xenmem_add_to_physmap_range+80>:    mov    0x8(%rbx),%rdx
0xffff82c4c01719c0 <xenmem_add_to_physmap_range+84>:    mov    0x7fe8(%r12),%rcx
0xffff82c4c01719c8 <xenmem_add_to_physmap_range+92>:    mov    0x10(%rcx),%rcx
0xffff82c4c01719cc <xenmem_add_to_physmap_range+96>:    cmpb   $0x0,0x1e8(%rcx)
0xffff82c4c01719d3 <xenmem_add_to_physmap_range+103>:   je     0xffff82c4c01719ed <xenmem_add_to_physmap_range+129 at mm.c:4689>
0xffff82c4c01719d5 <xenmem_add_to_physmap_range+105>:   movzwl %ax,%eax
0xffff82c4c01719d8 <xenmem_add_to_physmap_range+108>:   lea    -0x8(%rdx,%rax,8),%rsi
0xffff82c4c01719dd <xenmem_add_to_physmap_range+113>:   mov    $0x8,%edx

0xffff82c4c01719e2 <xenmem_add_to_physmap_range+118>:   mov    -0x58(%rbp),%rdi
0xffff82c4c01719fc <xenmem_add_to_physmap_range+144>:   mov    %r15,%rdi
                      ^^^^^^^^^ Above is OLD with local variables.

0xffff82c4c01719e6 <xenmem_add_to_physmap_range+122>:   callq  0xffff82c4c01b5861 <copy_from_user_hvm at hvm.c:2739>
0xffff82c4c01719eb <xenmem_add_to_physmap_range+127>:   jmp    0xffff82c4c0171a03 <xenmem_add_to_physmap_range+151 at mm.c:4689>
0xffff82c4c01719ed <xenmem_add_to_physmap_range+129>:   movzwl %ax,%eax
0xffff82c4c01719f0 <xenmem_add_to_physmap_range+132>:   lea    -0x8(%rdx,%rax,8),%rsi
0xffff82c4c01719f5 <xenmem_add_to_physmap_range+137>:   mov    $0x8,%edx
0xffff82c4c01719fa <xenmem_add_to_physmap_range+142>:   mov    -0x58(%rbp),%rdi
0xffff82c4c01719fe <xenmem_add_to_physmap_range+146>:   callq  0xffff82c4c018c59b <copy_from_user at usercopy.c:167>

Since, I already changed it, I'll leave it changed, but now I'm going crazy
whether the '||' belongs on line by itself, and the CODING_STYE doesn't
say anything, so hopefully I've it right and not have to crank out
another version just for that :).

thanks,
Mukesh

  reply	other threads:[~2013-05-17 22:24 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15  0:52 [PATCH 00/20][V5]: PVH xen: version 5 patches Mukesh Rathor
2013-05-15  0:52 ` [PATCH 01/20] PVH xen: turn gdb_frames/gdt_ents into union Mukesh Rathor
2013-05-15  0:52 ` [PATCH 02/20] PVH xen: add XENMEM_add_to_physmap_range Mukesh Rathor
2013-05-15  9:58   ` Jan Beulich
2013-05-15 23:05     ` Mukesh Rathor
2013-05-16  7:21       ` Jan Beulich
2013-05-16 11:03         ` Stefano Stabellini
2013-05-16 12:01           ` Jan Beulich
2013-05-16 15:04             ` Stefano Stabellini
2013-05-16 23:56         ` Mukesh Rathor
2013-05-17  6:37           ` Jan Beulich
2013-05-17 22:24             ` Mukesh Rathor [this message]
2013-05-15  0:52 ` [PATCH 03/20] PVH xen: create domctl_memory_mapping() function Mukesh Rathor
2013-05-15 10:07   ` Jan Beulich
2013-05-15  0:52 ` [PATCH 04/20] PVH xen: add params to read_segment_register Mukesh Rathor
2013-05-15  0:52 ` [PATCH 05/20] PVH xen: vmx realted preparatory changes for PVH Mukesh Rathor
2013-05-15  0:52 ` [PATCH 06/20] PVH xen: Move e820 fields out of pv_domain struct Mukesh Rathor
2013-05-15 10:27   ` Jan Beulich
2013-05-15  0:52 ` [PATCH 07/20] PVH xen: Introduce PVH guest type Mukesh Rathor
2013-05-15  0:52 ` [PATCH 08/20] PVH xen: tools changes to create PVH domain Mukesh Rathor
2013-05-15  0:52 ` [PATCH 09/20] PVH xen: domain creation code changes Mukesh Rathor
2013-05-15  0:52 ` [PATCH 10/20] PVH xen: create PVH vmcs, and also initialization Mukesh Rathor
2013-05-15  0:52 ` [PATCH 11/20] PVH xen: introduce pvh.c Mukesh Rathor
2013-05-15 10:42   ` Jan Beulich
2013-05-16  1:42     ` Mukesh Rathor
2013-05-16  8:00       ` Jan Beulich
2013-05-17  0:27         ` Mukesh Rathor
2013-05-17  6:43           ` Jan Beulich
2013-05-21  0:08             ` Mukesh Rathor
2013-05-21  7:07               ` Jan Beulich
2013-05-15  0:52 ` [PATCH 12/20] PVH xen: create read_descriptor_sel() Mukesh Rathor
2013-05-15  0:52 ` [PATCH 13/20] PVH xen: introduce vmx_pvh.c Mukesh Rathor
2013-05-15 11:46   ` Jan Beulich
2013-05-15  0:52 ` [PATCH 14/20] PVH xen: some misc changes like mtrr, intr, msi Mukesh Rathor
2013-05-15  0:52 ` [PATCH 15/20] PVH xen: hcall page initialize, create PVH guest type, etc Mukesh Rathor
2013-05-15  0:52 ` [PATCH 16/20] PVH xen: Miscellaneous changes Mukesh Rathor
2013-05-15 11:53   ` Jan Beulich
2013-05-16  1:51     ` Mukesh Rathor
2013-05-15  0:52 ` [PATCH 17/20] PVH xen: Introduce p2m_map_foreign Mukesh Rathor
2013-05-15 11:55   ` Jan Beulich
2013-05-15  0:52 ` [PATCH 18/20] PVH xen: Add and remove foreign pages Mukesh Rathor
2013-05-15 12:05   ` Jan Beulich
2013-05-15  0:52 ` [PATCH 19/20] PVH xen: elf and iommu related changes to prep for dom0 PVH Mukesh Rathor
2013-05-15 12:12   ` Jan Beulich
2013-05-16  1:58     ` Mukesh Rathor
2013-05-16  8:03       ` Jan Beulich
2013-05-17  1:14         ` Mukesh Rathor
2013-05-17  6:45           ` Jan Beulich
2013-05-18  2:01         ` Mukesh Rathor
2013-05-21  7:14           ` Jan Beulich
2013-05-15  0:52 ` [PATCH 20/20] PVH xen: PVH dom0 creation Mukesh Rathor

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=20130517152408.6ff4a0c4@mantra.us.oracle.com \
    --to=mukesh.rathor@oracle.com \
    --cc=JBeulich@suse.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.