|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/3] xen/x86: use trampoline e820 buffer for BIOS interface only
On 22/03/17 14:12, Jan Beulich wrote:
>>>> On 21.03.17 at 14:10, <jgross@xxxxxxxx> wrote:
>> @@ -133,7 +134,8 @@ static struct change_member *change_point[2*E820MAX]
>> __initdata;
>> static struct e820entry *overlap_list[E820MAX] __initdata;
>> static struct e820entry new_bios[E820MAX] __initdata;
>>
>> -static int __init sanitize_e820_map(struct e820entry * biosmap, char *
>> pnr_map)
>> +static int __init sanitize_e820_map(struct e820entry * biosmap,
>> + unsigned int * pnr_map)
>
> Please correct style violations in code you touch anyway (here:
> stray blanks after the *s).
Okay.
>
>> @@ -508,17 +510,16 @@ static void __init reserve_dmi_region(void)
>> }
>> }
>>
>> -static void __init machine_specific_memory_setup(
>> - struct e820entry *raw, unsigned int *raw_nr)
>> +static void __init machine_specific_memory_setup(struct e820map *raw)
>> {
>> unsigned long mpt_limit, ro_mpt_limit;
>> uint64_t top_of_ram, size;
>> int i;
>>
>> - char nr = (char)*raw_nr;
>> - sanitize_e820_map(raw, &nr);
>> - *raw_nr = nr;
>> - (void)copy_e820_map(raw, nr);
>> + unsigned int nr = raw->nr_map;
>> + sanitize_e820_map(raw->map, &nr);
>
> And here: Missing blank line between declarations and
> statements (in fact the blank line is there but misplaced). Or wait:
> The variable "nr" doesn't appear to be needed at all:
>
> sanitize_e820_map(raw->map, &raw->nr_map);
> copy_e820_map(raw->map, raw->nr_map);
>
> I guess it was there merely because field type and parameter
> type didn't match up.
You are right. Will remove it.
>
>> + raw->nr_map = nr;
>> + (void)copy_e820_map(raw->map, nr);
>
> Stray cast.
Indeed.
>
>> @@ -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?
>> --- 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.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |