On 10/08/13 at 06:48pm, Borislav Petkov wrote:
> From: Borislav Petkov
>
> We map the EFI regions needed for runtime services contiguously on
> virtual addresses starting from -4G down for a total max space of 64G.
> This way, we provide for stable runtime services addresses across
> kernels so t
On 10/10/13 at 04:06pm, Dave Young wrote:
> On 10/08/13 at 06:48pm, Borislav Petkov wrote:
> > From: Borislav Petkov
> >
> > We map the EFI regions needed for runtime services contiguously on
> > virtual addresses starting from -4G down for a total max space of 64G.
> > This way, we provide for s
On Thu, Oct 10, 2013 at 04:14:34PM +0800, Dave Young wrote:
> Even though I still have no idea why kernel text overlap with efi boot
> region, anyway map the un-overlapped part is necessary though.
>
> I can post the kexec related patches after your mapping patches settle
> down
Right, "settle dow
On Thu, 10 Oct, at 10:58:28AM, Borislav Petkov wrote:
> On Thu, Oct 10, 2013 at 04:14:34PM +0800, Dave Young wrote:
> > Even though I still have no idea why kernel text overlap with efi boot
> > region, anyway map the un-overlapped part is necessary though.
> >
> > I can post the kexec related patc
From: Matt Fleming
It's incredibly difficult to diagnose early EFI boot issues without
special hardware because earlyprintk=vga doesn't work on EFI systems.
Add support for writing to the EFI framebuffer, via earlyprintk=efi,
which will actually give users a chance of providing debug output.
Cc
* Matt Fleming wrote:
> From: Matt Fleming
>
> It's incredibly difficult to diagnose early EFI boot issues without
> special hardware because earlyprintk=vga doesn't work on EFI systems.
>
> Add support for writing to the EFI framebuffer, via earlyprintk=efi,
> which will actually give users
On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
>
> Is a non-32-bit framebuffer a possibility? If yes then it might be nice to
> emit an informative printk() here, so that users who try to enable EFI
> early-printk can at least see why it's not working. (Assuming they get to
> look
* Peter Jones wrote:
> On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
> >
> > Is a non-32-bit framebuffer a possibility? If yes then it might be nice to
> > emit an informative printk() here, so that users who try to enable EFI
> > early-printk can at least see why it's not work
On Thu, Oct 10, 2013 at 07:45:21PM +0200, Ingo Molnar wrote:
> Also, the main question would be, what is the typical value for
> si->lfb_depth. 32 on almost all EFI systems? All around the map? Depends
> on what graphics state the EFI bootloader passes us?
Microsoft require that it be 32, so in
On Thu, Oct 10, 2013 at 07:45:21PM +0200, Ingo Molnar wrote:
>
> * Peter Jones wrote:
>
> > On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
> > >
> > > Is a non-32-bit framebuffer a possibility? If yes then it might be nice
> > > to
> > > emit an informative printk() here, so tha
* Matthew Garrett wrote:
> On Thu, Oct 10, 2013 at 07:45:21PM +0200, Ingo Molnar wrote:
>
> > Also, the main question would be, what is the typical value for
> > si->lfb_depth. 32 on almost all EFI systems? All around the map? Depends
> > on what graphics state the EFI bootloader passes us?
>
On 10/10/13 at 01:34pm, Matt Fleming wrote:
> On Thu, 10 Oct, at 10:58:28AM, Borislav Petkov wrote:
> > On Thu, Oct 10, 2013 at 04:14:34PM +0800, Dave Young wrote:
> > > Even though I still have no idea why kernel text overlap with efi boot
> > > region, anyway map the un-overlapped part is necessa
12 matches
Mail list logo
