xen-devel.lists.xenproject.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).