All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Juergen Gross <jgross@suse.com>
Cc: andrew.cooper3@citrix.com, daniel.kiper@oracle.com,
	alex.thorlton@hpe.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH 2/3] xen/x86: use trampoline e820 buffer for BIOS interface only
Date: Wed, 22 Mar 2017 09:23:07 -0600	[thread overview]
Message-ID: <58D2A4EB0200007800146563@prv-mh.provo.novell.com> (raw)
In-Reply-To: <f9942665-3e8a-1dfd-81f3-f410abf27db6@suse.com>

>>> On 22.03.17 at 16:01, <jgross@suse.com> wrote:
> On 22/03/17 14:12, Jan Beulich wrote:
>>>>> On 21.03.17 at 14:10, <jgross@suse.com> wrote:
>>> @@ -194,10 +194,10 @@ static void __init efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>>              type = E820_NVS;
>>>              break;
>>>          }
>>> -        if ( e820nr && type == e->type &&
>>> +        if ( e820_raw.nr_map && type == e->type &&
>>>               desc->PhysicalStart == e->addr + e->size )
>>>              e->size += len;
>>> -        else if ( !len || e820nr >= E820MAX )
>>> +        else if ( !len || e820_raw.nr_map >= E820MAX )
>> 
>> ARRAY_SIZE() (also elsewhere)?
> 
> Yes. Would you prefer a separate patch for the other places I don't
> touch yet, or should I fold it into this one?

Either way should be fine.

>>> --- a/xen/include/asm-x86/e820.h
>>> +++ b/xen/include/asm-x86/e820.h
>>> @@ -30,15 +30,16 @@ extern int e820_change_range_type(
>>>      uint32_t orig_type, uint32_t new_type);
>>>  extern int e820_add_range(
>>>      struct e820map *, uint64_t s, uint64_t e, uint32_t type);
>>> -extern unsigned long init_e820(const char *, struct e820entry *, unsigned int *);
>>> +extern unsigned long init_e820(const char *, struct e820map *);
>>>  extern struct e820map e820;
>>> +extern struct e820map e820_raw;
>>>  
>>>  /* These symbols live in the boot trampoline. */
>>>  extern struct e820entry e820map[];
>>>  extern unsigned int e820nr;
>> 
>> It would be nice to restrict the visibility of these two (to be certain
>> there are no stray references), but that may be difficult to achieve.
>> One option might be to have an accessor function at the bottom of
>> e820.c, placing their declarations right ahead of that function. That
>> way only that function can validly use them. Another option would
>> be to drop the declarations altogether, moving the copying to
>> e820_raw into assembly code.
> 
> Hmm, maybe a copy function in assembly code? Something like:
> 
> e820_raw.nr_map = copy_bios_e820(e820_raw.map);
> 
> This would hide struct e820 from assembly and e820map[] and e820nr from
> C code.

Good idea, go ahead, albeit the hiding from assembly part is not
entirely true: Assembly code, with the single argument passed
above, would make the implication that the passed in array is no
smaller than the BIOS one.

Jan


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

  reply	other threads:[~2017-03-22 15:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-21 13:10 [PATCH 0/3] xen: support of large memory maps Juergen Gross
2017-03-21 13:10 ` [PATCH 1/3] xen/x86: split boot trampoline into permanent and temporary part Juergen Gross
2017-03-22 11:33   ` Jan Beulich
     [not found]   ` <58D26F070200007800146281@suse.com>
2017-03-22 11:50     ` Juergen Gross
2017-03-21 13:10 ` [PATCH 2/3] xen/x86: use trampoline e820 buffer for BIOS interface only Juergen Gross
2017-03-22 13:12   ` Jan Beulich
     [not found]   ` <58D2865F02000078001463C2@suse.com>
2017-03-22 15:01     ` Juergen Gross
2017-03-22 15:23       ` Jan Beulich [this message]
     [not found]       ` <58D2A4EB0200007800146563@suse.com>
2017-03-22 15:25         ` Juergen Gross
2017-03-21 13:10 ` [PATCH 3/3] xen/x86: support larger memory map from EFI Juergen Gross
2017-03-22 13:19   ` Jan Beulich
     [not found]   ` <58D287DC02000078001463D8@suse.com>
2017-03-22 15:05     ` Juergen Gross
2017-03-21 13:26 ` [PATCH 0/3] xen: support of large memory maps Daniel Kiper
2017-03-22 15:17 ` Alex Thorlton
2017-03-22 15:22   ` Juergen Gross

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=58D2A4EB0200007800146563@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=alex.thorlton@hpe.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=daniel.kiper@oracle.com \
    --cc=jgross@suse.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 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.