On 10/30/13 at 11:45am, Borislav Petkov wrote:
> On Wed, Oct 30, 2013 at 05:32:27PM +0800, Dave Young wrote:
> > Boris, thanks for update, it's very elaborate, I have still wonder if
> > 32 bit case should be mentioned as well.
>
> Ah, so that's why is mfleming bugging me about it on IRC :)
>
> W
On Wed, Oct 30, 2013 at 05:32:27PM +0800, Dave Young wrote:
> Boris, thanks for update, it's very elaborate, I have still wonder if
> 32 bit case should be mentioned as well.
Ah, so that's why is mfleming bugging me about it on IRC :)
Well, I left out the 32-bit case simply because I don't think
On 10/29/13 at 10:40am, Borislav Petkov wrote:
> On Tue, Oct 29, 2013 at 02:47:20PM +0800, Dave Young wrote:
> > Boris, could you update the comment? it says below: update that memory
> > descriptor with the virtual address obtained from ioremap().
> >
> > Logiclly your patch should update it, then
On Tue, Oct 29, 2013 at 02:47:20PM +0800, Dave Young wrote:
> Boris, could you update the comment? it says below: update that memory
> descriptor with the virtual address obtained from ioremap().
>
> Logiclly your patch should update it, then my patch update it again
> with the case of mapping to f
> /*
> * This function will switch the EFI runtime services to virtual mode.
> * Essentially, look through the EFI memmap and map every region that
> @@ -862,10 +906,10 @@ void efi_memory_uc(u64 addr, unsigned long size)
> void __init efi_enter_virtual_mode(void)
Boris, could you update the
On Mon, Oct 28, 2013 at 11:22:46AM +, Matt Fleming wrote:
> Could you use the efi_enabled() function to test for EFI_OLD_MEMMAP
> instead of test_bit()?
Sure.
> This way we won't exhaust the bitspace quite so soon (since ARM/ARM64
Yeah, very foresightful.
> can reuse EFI_ARCH_1 if they need
On Tue, 08 Oct, at 06:48:31PM, 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
> kerne
On Mon, 21 Oct, at 03:37:41PM, Borislav Petkov wrote:
> On Mon, Oct 21, 2013 at 08:47:39PM +0800, Dave Young wrote:
> > What's the status of this series?
>
> They should appear at some point in Matt's efi-next branch, I think.
>
> > I need below patch for mapping to fixed virt addr passed
> > fro
On Wed, Oct 23, 2013 at 08:51:31PM +0800, Dave Young wrote:
> In kexed 2nd kernel, phys_start_b need to be mapped to virt_start_b
> Simply use efi_map_region from your patch does not work because it
> will map phys_start_b to a different virt address, isn't it?
Oh ok, in the second kernel we're no
On 10/23/13 at 02:25pm, Borislav Petkov wrote:
> On Wed, Oct 23, 2013 at 10:17:31AM +0800, Dave Young wrote:
> > The reason is that I only pass runtime regions from 1st kernel to
> > kexec kernel, your efi mapping function uses the region size to
> > determin the virtual address from top to down. B
On Wed, Oct 23, 2013 at 02:25:31PM +0200, Borislav Petkov wrote:
> Matt, didn't you question the need to keep boot services regions
> mapped indefinitely? What was the story there?
We shouldn't need boot services regions to be mapped after
SetVirtualAddressMap is called.
--
Matthew Garrett | m
On Wed, Oct 23, 2013 at 10:17:31AM +0800, Dave Young wrote:
> The reason is that I only pass runtime regions from 1st kernel to
> kexec kernel, your efi mapping function uses the region size to
> determin the virtual address from top to down. Because the passed-in
> md ranges in kexec kernel are di
On 10/22/13 at 01:18pm, Borislav Petkov wrote:
> On Mon, Oct 21, 2013 at 11:04:26PM +0800, Dave Young wrote:
> > > You need this to map the runtime regions in the kexec kernel, right?
> > > Please write that in the commit message.
> >
> > Yes, will do
>
> Ok, but but, why doesn't the normal code
On Mon, Oct 21, 2013 at 11:04:26PM +0800, Dave Young wrote:
> > You need this to map the runtime regions in the kexec kernel, right?
> > Please write that in the commit message.
>
> Yes, will do
Ok, but but, why doesn't the normal code path in efi_enter_virtual_mode
work anymore? I mean, why do y
On 10/21/13 at 03:37pm, Borislav Petkov wrote:
> On Mon, Oct 21, 2013 at 08:47:39PM +0800, Dave Young wrote:
> > What's the status of this series?
>
> They should appear at some point in Matt's efi-next branch, I think.
>
> > I need below patch for mapping to fixed virt addr passed
> > from 1st k
On Mon, Oct 21, 2013 at 08:47:39PM +0800, Dave Young wrote:
> What's the status of this series?
They should appear at some point in Matt's efi-next branch, I think.
> I need below patch for mapping to fixed virt addr passed
> from 1st kernel.
You need this to map the runtime regions in the kexec
On 10/14/13 at 05:58pm, Borislav Petkov wrote:
> On Sun, Oct 13, 2013 at 11:25:21AM +0200, Borislav Petkov wrote:
> > In the meantime, I'll finish randconfigs testing of the patches and
> > upload the latest version to k-org, I'll let you know.
>
> Ok, here it is:
>
> git://git.kernel.org/pub/scm
> > > - Original Message -
> > > From: "Matt Fleming"
> > > To: "Dave Young"
> > > Cc: "Borislav Petkov" , "X86 ML" ,
> > > "LKML" , "Borislav Petkov" ,
> > > "Matthew Garrett&
On Sun, Oct 13, 2013 at 11:25:21AM +0200, Borislav Petkov wrote:
> In the meantime, I'll finish randconfigs testing of the patches and
> upload the latest version to k-org, I'll let you know.
Ok, here it is:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#efi
This version seems to work o
Message -
> > From: "Matt Fleming"
> > To: "Dave Young"
> > Cc: "Borislav Petkov" , "X86 ML" , "LKML"
> > , "Borislav Petkov" , "Matthew
> > Garrett" , "H. Peter Anvin" , "James
On Sun, Oct 13, 2013 at 11:11:27AM +0800, Dave Young wrote:
> Boris, I think we have got the agreement about passing setup_data?
Yes.
Basically, we want to start with what hpa suggested and see where it
gets us:
http://marc.info/?l=linux-kernel&m=138006799131051
> I think it should be on top of
On Sat, Oct 12, 2013 at 12:30:55PM +0200, Borislav Petkov wrote:
> On Sat, Oct 12, 2013 at 11:13:08AM +0100, Matt Fleming wrote:
> > On Sat, 12 Oct, at 03:54:44PM, Dave Young wrote:
> > > Boris:
> > >
> > > For the boot service region overlapping problem I have another idea,
> > > how about modify
On Sat, Oct 12, 2013 at 11:13:08AM +0100, Matt Fleming wrote:
> On Sat, 12 Oct, at 03:54:44PM, Dave Young wrote:
> > Boris:
> >
> > For the boot service region overlapping problem I have another idea,
> > how about modify your mapping code to always mapping the RUNTIME region
> > (non boot service
On Sat, Oct 12, 2013 at 11:13:08AM +0100, Matt Fleming wrote:
> On Sat, 12 Oct, at 03:54:44PM, Dave Young wrote:
> > Boris:
> >
> > For the boot service region overlapping problem I have another idea,
> > how about modify your mapping code to always mapping the RUNTIME region
> > (non boot service
On Sat, 12 Oct, at 03:54:44PM, Dave Young wrote:
> Boris:
>
> For the boot service region overlapping problem I have another idea,
> how about modify your mapping code to always mapping the RUNTIME region
> (non boot service region) firstly from the efi_va, then mapping other
> regions in order, i
On 10/11/13 at 09:41am, Borislav Petkov wrote:
> On Fri, Oct 11, 2013 at 02:24:37PM +0800, Dave Young wrote:
> > But for current implementation from Boris, getting same mapping
> > between diffrent kernel depends on same md order (same start and
> > size for each one) How about using this mapping s
quot;James
> Bottomley" , "Vivek Goyal"
> , linux-...@vger.kernel.org, fwts-de...@lists.ubuntu.com
> Sent: Friday, October 11, 2013 6:27:06 PM
> Subject: Re: [PATCH 12/12] EFI: Runtime services virtual mapping
>
> On Fri, 11 Oct, at 02:24:37PM, Dave Young wr
86 ML" , "LKML"
, "Borislav Petkov" , "Matthew
Garrett" , "H. Peter Anvin" , "James
Bottomley" , "Vivek Goyal"
, linux-...@vger.kernel.org, fwts-de...@lists.ubuntu.com
Sent: Friday, October 11, 2013 6:27:06 PM
Subject: Re: [PATCH 12/12] EF
On Fri, 11 Oct, at 02:24:37PM, Dave Young wrote:
> For the boot efi_reserve_boot_services code, it's mainly for the
> SetVirtualAddressMap callback use, so boot regions should not be reused
> before SetVirtualAddressMap, but the overlapping happens before the
> efi_reserve_boot_services, isn't it a
On Fri, Oct 11, 2013 at 02:24:37PM +0800, Dave Young wrote:
> But for current implementation from Boris, getting same mapping
> between diffrent kernel depends on same md order (same start and
> size for each one) How about using this mapping solution but at the
> same time for kexec kernel we also
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
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
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 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 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
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 that a kexec'd kernel can still use them.
This way, they're
36 matches
Mail list logo
