On Tue, Jul 29, 2014 at 3:54 PM, Prarit Bhargava wrote:
>
>
> On 07/29/2014 06:36 PM, Borislav Petkov wrote:
>> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
>>> and it was best to keep the code simple with a KiB.
>>
>> You're missing the point - the output doesn't get simple wi
On Tue, 29 Jul 2014, Joe Perches wrote:
> Maybe yet another vsprintf extension?
>
> Maybe %pH where vartype is one of [hh, h, u, ul, ull]
> with something like
> u64 t1 = (u64)*(appropriate cast)vartype;
> u64 t2 = t1;
> int index = 0;
> while ((t1 >>= 10)) {
>
On Tue, 2014-07-29 at 15:42 -0700, David Rientjes wrote:
> On Wed, 30 Jul 2014, Borislav Petkov wrote:
>
> > On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
> > > and it was best to keep the code simple with a KiB.
> >
> > You're missing the point - the output doesn't get simple
On 07/29/2014 07:01 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 03:42:55PM -0700, David Rientjes wrote:
>> If Prarit is going to implement this suggested reverse memparse() ...
>
> The only meaningful argument about the formatting here IMO is what
> people staring at this output are goi
On Tue, Jul 29, 2014 at 03:42:55PM -0700, David Rientjes wrote:
> If Prarit is going to implement this suggested reverse memparse() ...
The only meaningful argument about the formatting here IMO is what
people staring at this output are going to understand from it.
And since those people most oft
On 07/29/2014 06:36 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
>> and it was best to keep the code simple with a KiB.
>
> You're missing the point - the output doesn't get simple with KiB. Read
> the example I just gave you!
>
> (13893632kiB) i
On Wed, 30 Jul 2014, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
> > and it was best to keep the code simple with a KiB.
>
> You're missing the point - the output doesn't get simple with KiB. Read
> the example I just gave you!
>
> (13893632kiB) is a
On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
> and it was best to keep the code simple with a KiB.
You're missing the point - the output doesn't get simple with KiB. Read
the example I just gave you!
(13893632kiB) is actively *not* helping when one looks at it!
--
Regards/Gr
On 07/29/2014 06:29 PM, Borislav Petkov wrote:
> On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
>> The current debug print in EFI does
>>
>> [0.00] efi: mem84: type=3, attr=0xf,
>> range=[0x645b5000-0x645fb000) (0MB)
>>
>> and rounds off the size to 0MB
On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
> The current debug print in EFI does
>
> [0.00] efi: mem84: type=3, attr=0xf,
> range=[0x645b5000-0x645fb000) (0MB)
>
> and rounds off the size to 0MB and isn't very useful. We should print this in
> Kib.
On Tue, 2014-07-29 at 13:29 -0700, David Rientjes wrote:
> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
[]
> > @@ -384,10 +384,10 @@ static void __init print_efi_memmap(void)
> > p < memmap.map_end;
> > p +=
On 07/29/2014 06:02 PM, Joe Perches wrote:
> On Tue, 2014-07-29 at 13:29 -0700, David Rientjes wrote:
>> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
>>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> []
>>> @@ -384,10 +384,10 @@ static void __init print_efi_memmap(void)
On 07/29/2014 04:29 PM, David Rientjes wrote:
> On Tue, 29 Jul 2014, Prarit Bhargava wrote:
>
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 87fc96b..3875090 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/platform/efi/efi.c
>> @@ -384,10 +384,10
On Tue, 29 Jul 2014, Prarit Bhargava wrote:
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 87fc96b..3875090 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -384,10 +384,10 @@ static void __init print_efi_memmap(void)
>
On 29 July 2014 21:20, Mark Salter wrote:
> On Tue, 2014-07-29 at 20:46 +0200, Ard Biesheuvel wrote:
>> On 29 July 2014 20:27, Mark Salter wrote:
>> > On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
>> >> On 29 July 2014 17:29, Mark Salter wrote:
>> >> > On Tue, 2014-07-29 at 12:49 +020
On Tue, 2014-07-29 at 20:46 +0200, Ard Biesheuvel wrote:
> On 29 July 2014 20:27, Mark Salter wrote:
> > On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
> >> On 29 July 2014 17:29, Mark Salter wrote:
> >> > On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
> >> >> If we cannot rel
On 29 July 2014 20:27, Mark Salter wrote:
> On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
>> On 29 July 2014 17:29, Mark Salter wrote:
>> > On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
>> >> If we cannot relocate the kernel Image to its preferred offset of base of
>> >> DR
On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
> On 29 July 2014 17:29, Mark Salter wrote:
> > On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
> >> If we cannot relocate the kernel Image to its preferred offset of base of
> >> DRAM
> >> plus TEXT_OFFSET, instead relocate it to
On 29 July 2014 17:29, Mark Salter wrote:
> On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
>> If we cannot relocate the kernel Image to its preferred offset of base of
>> DRAM
>> plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary
>> plus
>> TEXT_OFFSET. We may
The current debug print in EFI does
[0.00] efi: mem84: type=3, attr=0xf,
range=[0x645b5000-0x645fb000) (0MB)
and rounds off the size to 0MB and isn't very useful. We should print this in
Kib. After applying this patch we get better info with
[0.00] efi: mem84:
On Tuesday 29 July 2014 17:18:52 Mark Rutland wrote:
> Sorry, I'd misunderstood the problem and my suggestion was nonsense
> deriving from that.
>
> Having the (__force void *) cast in the call to __flush_dcache_area
> sounds like the right solution to me.
Well, there isn't really a good solution
On Tue, Jul 29, 2014 at 05:13:07PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 July 2014 17:03:03 Mark Rutland wrote:
> > On Tue, Jul 29, 2014 at 04:20:46PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > > > > -
> > > > > - __flush_dcache_area(release_
On Tuesday 29 July 2014 17:03:03 Mark Rutland wrote:
> On Tue, Jul 29, 2014 at 04:20:46PM +0100, Arnd Bergmann wrote:
> > On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > > > -
> > > > - __flush_dcache_area(release_addr, sizeof(release_addr[0]));
> > > > + writeq_relaxed(__pa(seconda
On Tue, Jul 29, 2014 at 04:20:46PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > > -
> > > - __flush_dcache_area(release_addr, sizeof(release_addr[0]));
> > > + writeq_relaxed(__pa(secondary_holding_pen), release_addr);
> > > + __flush_dcache_area
On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
> The static memory footprint of a kernel Image at boot is larger than the
> Image file itself. Things like .bss data and initial page tables are allocated
> statically but populated dynamically so their content is not contained in the
> Imag
On Tuesday 29 July 2014 11:30:24 Mark Salter wrote:
> On Tue, 2014-07-29 at 17:20 +0200, Arnd Bergmann wrote:
> > On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > > > -
> > > > - __flush_dcache_area(release_addr, sizeof(release_addr[0]));
> > > > + writeq_relaxed(__pa(secondary_holdi
On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
> If we cannot relocate the kernel Image to its preferred offset of base of DRAM
> plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary
> plus
> TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
On Tue, 2014-07-29 at 17:20 +0200, Arnd Bergmann wrote:
> On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > > -
> > > - __flush_dcache_area(release_addr, sizeof(release_addr[0]));
> > > + writeq_relaxed(__pa(secondary_holding_pen), release_addr);
> > > + __flush_dcache_area(releas
On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > -
> > - __flush_dcache_area(release_addr, sizeof(release_addr[0]));
> > + writeq_relaxed(__pa(secondary_holding_pen), release_addr);
> > + __flush_dcache_area(release_addr, sizeof(*release_addr));
>
>__flush_dcache_area((_
On Tue, 2014-07-29 at 11:15 -0400, Mark Salter wrote:
> On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
> > From: Mark Rutland
> >
> > In certain cases the cpu-release-addr of a CPU may not fall in the
> > linear mapping (e.g. when the kernel is loaded above this address due to
> > the p
On Tue, 2014-07-29 at 12:49 +0200, Ard Biesheuvel wrote:
> From: Mark Rutland
>
> In certain cases the cpu-release-addr of a CPU may not fall in the
> linear mapping (e.g. when the kernel is loaded above this address due to
> the presence of other images in memory). This is problematic for the
>
From: Mark Rutland
In certain cases the cpu-release-addr of a CPU may not fall in the
linear mapping (e.g. when the kernel is loaded above this address due to
the presence of other images in memory). This is problematic for the
spin-table code as it assumes that it can trivially convert a
cpu-rel
This is mostly a resend of patches that were circulated a week or 2 ago to
address boot failures that were observed on platforms where the base of DRAM
is occupied by firmware or by UEFI itself.
TEXT_OFFSET is somewhat of a historical artefact, and with Mark Rutland's
patches already queued for 3.
If we cannot relocate the kernel Image to its preferred offset of base of DRAM
plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus
TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
proceed normally otherwise.
Signed-off-by: Ard Biesheuvel
---
The static memory footprint of a kernel Image at boot is larger than the
Image file itself. Things like .bss data and initial page tables are allocated
statically but populated dynamically so their content is not contained in the
Image file.
However, if EFI (or GRUB) has loaded the Image at precis
35 matches
Mail list logo
