xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: andrew.cooper3@citrix.com, daniel.kiper@oracle.com,
	alex.thorlton@hpe.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/3] xen/x86: use trampoline e820 buffer for BIOS interface only
Date: Thu, 23 Mar 2017 17:54:28 +0100	[thread overview]
Message-ID: <c7b0986e-a3d7-0fba-6aab-439fd93e310a@suse.com> (raw)
In-Reply-To: <58D3F93C0200007800146D13@suse.com>

On 23/03/17 16:35, Jan Beulich wrote:
>>>> On 23.03.17 at 07:25, <jgross@suse.com> wrote:
>> --- a/xen/arch/x86/boot/mem.S
>> +++ b/xen/arch/x86/boot/mem.S
>> @@ -67,10 +67,32 @@ get_memory_map:
>>  
>>          ret
>>  
>> +/*
>> + * Copy E820 map obtained from BIOS to a buffer allocated by Xen.
>> + * Input: %rdi: target address of e820 entry array
>> + *        %rsi: maximum number of entries to copy
> 
> %esi (and also needs to be used that way below)

Okay.

> 
>> + * Output: %rax: number of entries copied
>> + */
>> +        .code64
>> +ENTRY(e820map_copy)
>> +        mov     %rsi, %rax
>> +        movq    $bootsym(e820map), %rsi
> 
> %rip-relative leaq? Even more - is bootsym() usable here at all? The
> comment next to its definition says otherwise. Otoh I'm sure you've
> tested this, so it must be working despite me not seeing how it would
> do so.

Hmm, let me double ckeck. I'm sure to have tested it: the system came up
and the memory map looked as usual.

Oh wait - don't know whether I should cry or laugh: the system is really
fault tolerant! Seems as if e820map_copy returned zero and Xen used the
Multiboot-e820 map!

Thank you very much for questioning using bootsym!

>> +        movl    bootsym(e820nr), %ecx
>> +        cmpl    %ecx, %eax
>> +        cmova   %ecx, %eax                      # number of entries to move
>> +        movl    %eax, %ecx
>> +        shll    $2, %ecx
>> +        jz      .Lcopyexit                      # early exit: nothing to move
>> +        addl    %eax, %ecx                      # number of 4-byte moves
>> +        cld                                     # (5 times of entries)
> 
> I don't think you need this - the function is being called from C
> code, which assume EFLAGS.DF to be always clear. And to make
> the "5 times" more obvious, how about
> 
>         cmova   %ecx, %eax                      # number of entries to move
>         imul    $5, %eax, %ecx
>         jrcxz   .Lcopyexit                      # early exit: nothing to move
> 
> And the branch isn't even needed - REP MOVS does the right
> thing when %rcx is zero.

Okay, I'll change it.

> 
>> +        rep movsd                               # do the move
>> +.Lcopyexit:
>> +        retq
> 
> Please be consistent: Either suffix all insns, or only those where the
> suffix is really needed. And in no case should you use an Intel
> mnemonic (movsd) in AT&T syntax code (should be movsl).

No suffixes then in general and movsl here.

> 
>> @@ -782,14 +782,16 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>      }
>>      else if ( efi_enabled(EFI_BOOT) )
>>          memmap_type = "EFI";
>> -    else if ( e820_raw_nr != 0 )
>> +    else if ( (nr_e820 = copy_bios_e820(e820_raw.map, E820MAX)) != 0 )
> 
> ARRAY_SIZE()?

Of course!


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-03-23 16:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23  6:25 [PATCH v2 0/3] xen: support of large memory maps Juergen Gross
2017-03-23  6:25 ` [PATCH v2 1/3] xen/x86: split boot trampoline into permanent and temporary part Juergen Gross
2017-03-23 15:04   ` Jan Beulich
     [not found]   ` <58D3F2070200007800146CE0@suse.com>
2017-03-23 16:44     ` Juergen Gross
2017-03-23 16:54       ` Jan Beulich
     [not found]       ` <58D40BCB0200007800146E2A@suse.com>
2017-03-23 17:01         ` Juergen Gross
2017-03-23  6:25 ` [PATCH v2 2/3] xen/x86: use trampoline e820 buffer for BIOS interface only Juergen Gross
2017-03-23 15:35   ` Jan Beulich
2017-03-23 15:40     ` Andrew Cooper
2017-03-23 16:22       ` Jan Beulich
     [not found]   ` <58D3F93C0200007800146D13@suse.com>
2017-03-23 16:54     ` Juergen Gross [this message]
2017-03-23  6:25 ` [PATCH v2 3/3] xen/x86: support larger memory map from EFI Juergen Gross
2017-03-23 15:35   ` 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=c7b0986e-a3d7-0fba-6aab-439fd93e310a@suse.com \
    --to=jgross@suse.com \
    --cc=JBeulich@suse.com \
    --cc=alex.thorlton@hpe.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=daniel.kiper@oracle.com \
    --cc=xen-devel@lists.xenproject.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).