On Thu, Jun 06, 2013 at 11:02:18PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 09:50:57PM +0100, Matthew Garrett wrote:
> > What do you mean by "call them"? I don't think we ever want to call by
> > physical address, other than maybe in the kexec case. The only reason
> > we really care
On Thu, Jun 06, 2013 at 09:50:57PM +0100, Matthew Garrett wrote:
> What do you mean by "call them"? I don't think we ever want to call by
> physical address, other than maybe in the kexec case. The only reason
> we really care about the physical addresses being mapped 1:1 is that
> some pointers ma
On Thu, Jun 06, 2013 at 10:44:10PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 09:30:57PM +0100, Matthew Garrett wrote:
> > Well, we want the 1:1 mappings to exist all the time. The only
> > thing the option should change is whether they're passed to
> > SetVirtualAddressMap() or not.
>
On Thu, Jun 06, 2013 at 09:30:57PM +0100, Matthew Garrett wrote:
> Well, we want the 1:1 mappings to exist all the time. The only
> thing the option should change is whether they're passed to
> SetVirtualAddressMap() or not.
But can you call them even if they haven't been passed through
SetVirtual
On Thu, Jun 06, 2013 at 10:27:17PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 09:18:28PM +0100, Matthew Garrett wrote:
> > kexec seems like a lower priority than compatibility. Perhaps keep the
> > efi argument for people who want to use kexec?
>
> This is what I currently have in the
On Thu, Jun 06, 2013 at 09:18:28PM +0100, Matthew Garrett wrote:
> kexec seems like a lower priority than compatibility. Perhaps keep the
> efi argument for people who want to use kexec?
This is what I currently have in the code: if you boot with efi=1:1_map,
you get them.
> hpa suggested allocat
On Thu, Jun 06, 2013 at 10:07:05PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 08:54:50PM +0100, Matthew Garrett wrote:
> > We want both to be available when we're making the call, but I think
> > we should probably enter via the high addresses. The only reason we're
> > doing this at a
On Thu, Jun 06, 2013 at 08:54:50PM +0100, Matthew Garrett wrote:
> We want both to be available when we're making the call, but I think
> we should probably enter via the high addresses. The only reason we're
> doing this at all is that some systems don't update all of their
> pointers from physica
On Thu, Jun 06, 2013 at 09:41:34PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 08:35:48PM +0100, Matthew Garrett wrote:
> > No, I think that's the wrong thing to do. We should set up the current
> > mappings and the 1:1 mappings, and pass the current mappings through
> > SetVirtualAddre
On Thu, Jun 06, 2013 at 08:35:48PM +0100, Matthew Garrett wrote:
> No, I think that's the wrong thing to do. We should set up the current
> mappings and the 1:1 mappings, and pass the current mappings through
> SetVirtualAddressMap(). That matches the behaviour of Windows.
And when do we use the 1
On 06/06/2013 12:36 PM, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 12:28:20PM -0700, H. Peter Anvin wrote:
>> Or we could materialize mappings for this specific PGD. However,
>> adding a read of %cr3 in __do_page_fault sounds expensive.
>
> Yes, I think we want to make sure all mappings are
On Thu, Jun 06, 2013 at 12:28:20PM -0700, H. Peter Anvin wrote:
> Or we could materialize mappings for this specific PGD. However,
> adding a read of %cr3 in __do_page_fault sounds expensive.
Yes, I think we want to make sure all mappings are there when we do an
EFI runtime call so that we never #
On Thu, Jun 06, 2013 at 08:51:40PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 06:50:52PM +0100, Matthew Garrett wrote:
> > On Thu, Jun 06, 2013 at 03:26:03PM +0200, Borislav Petkov wrote:
> >
> > > This would break the Macs, remember?
> >
> > I think the Macs will be fine as long as
On 06/06/2013 08:58 AM, Borislav Petkov wrote:
> --
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 654be4ae3047..7a6129afdff1 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1021,6 +1021,9 @@ __do_page_fault(struct pt_regs *regs, unsigned long
> error_code)
>
On Thu, Jun 06, 2013 at 06:50:52PM +0100, Matthew Garrett wrote:
> On Thu, Jun 06, 2013 at 03:26:03PM +0200, Borislav Petkov wrote:
>
> > This would break the Macs, remember?
>
> I think the Macs will be fine as long as we're passing the high mappings
> into SetVirtualAddressMap().
Right, on th
On Thu, Jun 06, 2013 at 03:26:03PM +0200, Borislav Petkov wrote:
> This would break the Macs, remember?
I think the Macs will be fine as long as we're passing the high mappings
into SetVirtualAddressMap().
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line
On Thu, Jun 06, 2013 at 03:29:08PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 02:14:39PM +0100, Matt Fleming wrote:
> > This patch makes my TunnelMountain machine spin in handle_pte_fault()
> > when triggering one of the "firmware makes references to physical
> > addresses" code paths.
On Thu, Jun 06, 2013 at 04:00:39PM +0100, Matt Fleming wrote:
> On Thu, 06 Jun, at 09:48:46AM, Russ Anderson wrote:
> > This looks like it will try to allocate more than the remaining size.
> > Is that intended?
>
> Yes, the intention is to trigger garbage collection.
OK, if that's what it takes.
On Thu, 06 Jun, at 09:48:46AM, Russ Anderson wrote:
> This looks like it will try to allocate more than the remaining size.
> Is that intended?
Yes, the intention is to trigger garbage collection.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the lin
On Thu, Jun 06, 2013 at 10:25:42AM +0100, Matt Fleming wrote:
> On Thu, 06 Jun, at 03:40:26PM, joeyli wrote:
> > OK, I moved volatile checking to the top of the function.
> > New version, version 3 diff result like the following.
>
> Thanks. This is what I've now got queued up.
>
> ---
>
> >From
On Thu, 06 Jun, at 03:26:03PM, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 11:42:24AM +0100, Matt Fleming wrote:
> > On Sun, 02 Jun, at 02:56:09PM, Borislav Petkov wrote:
> > > +
> > > +static int __init parse_efi_cmdline(char *str)
> > > +{
> > > + if (*str == '=')
> > > + str++;
> >
On Thu, Jun 06, 2013 at 02:30:23PM +0100, Matt Fleming wrote:
> I meant because the .pgd member is uninitialised and contains garbage.
Oh yeah, good catch! Fixed.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list:
On Thu, 06 Jun, at 03:24:06PM, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 11:22:33AM +0100, Matt Fleming wrote:
> > > @@ -697,7 +714,10 @@ static int __change_page_attr(struct cpa_data *cpa,
> > > int primary)
> > > else
> > > address = *cpa->vaddr;
> > > repeat:
> > > - kpte =
On Thu, Jun 06, 2013 at 02:14:39PM +0100, Matt Fleming wrote:
> This patch makes my TunnelMountain machine spin in handle_pte_fault()
> when triggering one of the "firmware makes references to physical
> addresses" code paths.
>
> I'll try and dig into this tomorrow to figure out what's going on.
On Thu, Jun 06, 2013 at 11:42:24AM +0100, Matt Fleming wrote:
> On Sun, 02 Jun, at 02:56:09PM, Borislav Petkov wrote:
> > +
> > +static int __init parse_efi_cmdline(char *str)
> > +{
> > + if (*str == '=')
> > + str++;
> > + if (!strncmp(str, "1:1_map", 7))
> > + efi_config
On Thu, Jun 06, 2013 at 11:22:33AM +0100, Matt Fleming wrote:
> > @@ -697,7 +714,10 @@ static int __change_page_attr(struct cpa_data *cpa,
> > int primary)
> > else
> > address = *cpa->vaddr;
> > repeat:
> > - kpte = lookup_address(address, &level);
> > + if (cpa->pgd)
> > +
On Sun, 02 Jun, at 02:56:10PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Due to the braindead design of EFI, we cannot map runtime services more
> than once for the duration of a booted system. Thus, if we want to use
> EFI runtime services in a kexec'ed kernel, maybe the only possible a
On Sun, 02 Jun, at 02:56:09PM, Borislav Petkov wrote:
> +
> +static int __init parse_efi_cmdline(char *str)
> +{
> + if (*str == '=')
> + str++;
> + if (!strncmp(str, "1:1_map", 7))
> + efi_config |= EFI_CFG_MAP11;
> +
> + return 0;
> +}
> +early_param("efi", par
On Sun, 02 Jun, at 02:56:08PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Add the ability to map pages in an arbitrary pgd.
>
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/include/asm/pgtable_types.h | 3 +-
> arch/x86/mm/pageattr.c | 80
> ++
On Sun, 02 Jun, at 02:56:07PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> ... to void * like the boot services and lose all the void * casts. No
> functionality change.
>
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/boot/compressed/eboot.c | 2 +-
> arch/x86/include/asm/efi.h
On Thu, 06 Jun, at 03:40:26PM, joeyli wrote:
> OK, I moved volatile checking to the top of the function.
> New version, version 3 diff result like the following.
Thanks. This is what I've now got queued up.
---
>From 118428bf3b207d9b390a27f32dfef6dc2979078d Mon Sep 17 00:00:00 2001
From: Matthew
於 四，2013-06-06 於 05:42 +，Matthew Garrett 提到：
> On Thu, 2013-06-06 at 13:05 +0800, joeyli wrote:
>
> > + if (!(attributes & EFI_VARIABLE_NON_VOLATILE))
> > + return EFI_OUT_OF_RESOURCES;
>
> I'd move this up to the top of the function, and just return 0 - there's
>
32 matches
Mail list logo
