On 08/17/16 at 11:00am, Alex Thorlton wrote:
> On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > > Why do you guys need the physical mapping all of a sudden?
> > >
> > > It's not that we need it all of the sudden, necessarily, it's just that
> > > we've had to make other changes
On 08/17/16 at 11:00am, Alex Thorlton wrote:
> On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > > Why do you guys need the physical mapping all of a sudden?
> > >
> > > It's not that we need it all of the sudden, necessarily, it's just that
> > > we've had to make other changes
On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > Why do you guys need the physical mapping all of a sudden?
> >
> > It's not that we need it all of the sudden, necessarily, it's just that
> > we've had to make other changes to make things work with the new,
> > (almost)
On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > Why do you guys need the physical mapping all of a sudden?
> >
> > It's not that we need it all of the sudden, necessarily, it's just that
> > we've had to make other changes to make things work with the new,
> > (almost)
> > Why do you guys need the physical mapping all of a sudden?
>
> It's not that we need it all of the sudden, necessarily, it's just that
> we've had to make other changes to make things work with the new,
> (almost) completely isolated, EFI page tables. We ended up choosing the
> lesser of two
> > Why do you guys need the physical mapping all of a sudden?
>
> It's not that we need it all of the sudden, necessarily, it's just that
> we've had to make other changes to make things work with the new,
> (almost) completely isolated, EFI page tables. We ended up choosing the
> lesser of two
On Tue, Aug 16, 2016 at 07:50:10AM +0200, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote:
> > The only thing we're adding here is the physical mappings, to match
> > what is availble in the primary kernel.
>
> I can see what it does - I just am questioning
On Tue, Aug 16, 2016 at 07:50:10AM +0200, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote:
> > The only thing we're adding here is the physical mappings, to match
> > what is availble in the primary kernel.
>
> I can see what it does - I just am questioning
On Tue, Aug 16, 2016 at 01:30:28PM +0100, Matt Fleming wrote:
> That's impossible, because that would mean we loaded the kexec kernel
> over the top of physical pages of EFI services. We still need to be
> able to invoke EFI services from kexec - we just can't change their
> virtual mappings.
On Tue, Aug 16, 2016 at 01:30:28PM +0100, Matt Fleming wrote:
> That's impossible, because that would mean we loaded the kexec kernel
> over the top of physical pages of EFI services. We still need to be
> able to invoke EFI services from kexec - we just can't change their
> virtual mappings.
On Mon, 15 Aug, at 05:07:09PM, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> > (Cc'ing Boris and Dave)
> >
> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > > This is a simple change to add in the physical mappings as well as the
> > > virtual
On Mon, 15 Aug, at 05:07:09PM, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> > (Cc'ing Boris and Dave)
> >
> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > > This is a simple change to add in the physical mappings as well as the
> > > virtual
On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote:
> The only thing we're adding here is the physical mappings, to match
> what is availble in the primary kernel.
I can see what it does - I just am questioning the reasoning for as we
did all that effort so that kexec can have stable
On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote:
> The only thing we're adding here is the physical mappings, to match
> what is availble in the primary kernel.
I can see what it does - I just am questioning the reasoning for as we
did all that effort so that kexec can have stable
On Mon, Aug 15, 2016 at 02:52:22PM -0700, H. Peter Anvin wrote:
> So to answer the implicit question: we have found UEFI stacks in the
> field which fail without the physical mappings present, and we have
> found stacks which fail without a nontrivial SetAddressMapping.
You mean
On Mon, Aug 15, 2016 at 02:52:22PM -0700, H. Peter Anvin wrote:
> So to answer the implicit question: we have found UEFI stacks in the
> field which fail without the physical mappings present, and we have
> found stacks which fail without a nontrivial SetAddressMapping.
You mean
On August 15, 2016 11:47:31 AM PDT, Alex Thorlton wrote:
>On Mon, Aug 15, 2016 at 05:07:09PM +0200, Borislav Petkov wrote:
>> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
>> > (Cc'ing Boris and Dave)
>> >
>> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton
On August 15, 2016 11:47:31 AM PDT, Alex Thorlton wrote:
>On Mon, Aug 15, 2016 at 05:07:09PM +0200, Borislav Petkov wrote:
>> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
>> > (Cc'ing Boris and Dave)
>> >
>> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
>> > > This is a
On Mon, Aug 15, 2016 at 05:07:09PM +0200, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> > (Cc'ing Boris and Dave)
> >
> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > > This is a simple change to add in the physical mappings as well as the
> >
On Mon, Aug 15, 2016 at 05:07:09PM +0200, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> > (Cc'ing Boris and Dave)
> >
> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > > This is a simple change to add in the physical mappings as well as the
> >
On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> (Cc'ing Boris and Dave)
>
> On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > This is a simple change to add in the physical mappings as well as the
> > virtual mappings in efi_map_region_fixed. The motivation here is to
> >
On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> (Cc'ing Boris and Dave)
>
> On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > This is a simple change to add in the physical mappings as well as the
> > virtual mappings in efi_map_region_fixed. The motivation here is to
> >
(Cc'ing Boris and Dave)
On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> This is a simple change to add in the physical mappings as well as the
> virtual mappings in efi_map_region_fixed. The motivation here is to
> get access to EFI runtime code that is only available via the 1:1
>
(Cc'ing Boris and Dave)
On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> This is a simple change to add in the physical mappings as well as the
> virtual mappings in efi_map_region_fixed. The motivation here is to
> get access to EFI runtime code that is only available via the 1:1
>
On Fri, Aug 05, 2016 at 06:59:35PM -0500, Alex Thorlton wrote:
> This is a simple change to add in the physical mappings as well as the
> virtual mappings in efi_map_region_fixed. The motivation here is to
> get access to EFI runtime code that is only available via the 1:1
> mappings on a kexec'd
On Fri, Aug 05, 2016 at 06:59:35PM -0500, Alex Thorlton wrote:
> This is a simple change to add in the physical mappings as well as the
> virtual mappings in efi_map_region_fixed. The motivation here is to
> get access to EFI runtime code that is only available via the 1:1
> mappings on a kexec'd
This is a simple change to add in the physical mappings as well as the
virtual mappings in efi_map_region_fixed. The motivation here is to
get access to EFI runtime code that is only available via the 1:1
mappings on a kexec'd kernel.
The added call is essentially the kexec analog of the first
This is a simple change to add in the physical mappings as well as the
virtual mappings in efi_map_region_fixed. The motivation here is to
get access to EFI runtime code that is only available via the 1:1
mappings on a kexec'd kernel.
The added call is essentially the kexec analog of the first
28 matches
Mail list logo