On Mon, May 09, 2016 at 10:55:24PM +0100, Matt Fleming wrote:
> On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote:
> >
> > If you think we're violating EFI rules by accessing these registers from
> > both sides of the fence, please let me know. I'd like to make sure that
> > we get everything be
On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote:
>
> If you think we're violating EFI rules by accessing these registers from
> both sides of the fence, please let me know. I'd like to make sure that
> we get everything behaving the way it should be!
Oh no, I don't think this is violating the
On Wed, May 04, 2016 at 12:36:36PM +0200, Borislav Petkov wrote:
> On Tue, May 03, 2016 at 01:47:51PM -0500, Alex Thorlton wrote:
> > I think this will work for us, for the most part. Only issue is that
> > the efi_call_virt macro is only accessible from inside
> > runtime-wrappers.c. If we could
On Tue, May 03, 2016 at 01:47:51PM -0500, Alex Thorlton wrote:
> I think this will work for us, for the most part. Only issue is that
> the efi_call_virt macro is only accessible from inside
> runtime-wrappers.c. If we could pull that macro (and whatever else it
> needs) up to the header file, I
On Tue, May 03, 2016 at 11:48:20AM +0200, Borislav Petkov wrote:
> On Mon, May 02, 2016 at 07:10:36PM -0500, Alex Thorlton wrote:
> > +#define uv_call_virt(f, args...) \
> > +({ \
> > + efi_status_t __s;
On Mon, May 02, 2016 at 07:10:36PM -0500, Alex Thorlton wrote:
> +#define uv_call_virt(f, args...) \
> +({ \
> + efi_status_t __s; \
> + kernel_fpu_begin();
On Mon, May 02, 2016 at 05:27:19PM -0500, Alex Thorlton wrote:
> Thanks for the help. I'll get back to you when I know a bit more about
> what's happening with our runtime callbacks!
I've made a bit of progress here. I was able to switch over to a very
slightly modified version of efi_call_virt
On Mon, May 02, 2016 at 12:02:22PM +0200, Borislav Petkov wrote:
> On Fri, Apr 29, 2016 at 10:41:19AM -0500, Alex Thorlton wrote:
> > You can see here that we've made it past the MMR read in uv_system_init,
> > but we die inside of our first EFI callback. In this example, it looks
> > like we're u
On 5/2/2016 2:39 PM, Alex Thorlton wrote:
>> > Who owns the MMR space and what is it used for? Do both the kernel and
>> > the firmware need access to it? My SGI UV knowledge is zero, so I'm
>> > happy to be educated! I can't think of any analogous memory regions on
>> > x86 where the EFI service
On Sat, Apr 30, 2016 at 11:12:09PM +0100, Matt Fleming wrote:
> On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote:
> >
> > You can see here that we've made it past the MMR read in uv_system_init,
> > but we die inside of our first EFI callback. In this example, it looks
> > like we're using the
On Fri, Apr 29, 2016 at 10:41:19AM -0500, Alex Thorlton wrote:
> I think this is partially correct, but in doing that, we find that we're
> still missing something. Watch what happens when I make this small
> tweak to my kernel:
>
> 8<---
> diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
> b/arch
On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote:
>
> You can see here that we've made it past the MMR read in uv_system_init,
> but we die inside of our first EFI callback. In this example, it looks
> like we're using the kernel page table at the time of the failure, and I
> believe that the f
On Thu, Apr 28, 2016 at 02:57:11PM +0200, Borislav Petkov wrote:
> > After d2f7cbe7b26a74 ("x86/efi: Runtime services virtual mapping") was
> > introduced (I'm sure you remember the BIOS issue we had a while back) we
> > had to fall back to using EFI_OLD_MEMMAP, so for a while we relied on
> > efi_
On Fri, Apr 29, 2016 at 10:01:15AM +0100, Matt Fleming wrote:
> On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote:
> >
> > From what I know, this works because the first PGD entry (the one
> > containing the identity mappings) of the trampoline_pgd is shared with
> > the main kernel PGD (init_lev
On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote:
>
> From what I know, this works because the first PGD entry (the one
> containing the identity mappings) of the trampoline_pgd is shared with
> the main kernel PGD (init_level4_pgt), so when __map_region maps this
> stuff into the trampoline_pgd
On Wed, Apr 27, 2016 at 08:41:28PM -0500, Alex Thorlton wrote:
> In this particular instance, it's not using the EFI page table - it's
> showing that the register isn't mapped into the main kernel page table,
> via the bad paging request. The issue isn't that there's something
> wrong with the EFI
On Thu, Apr 28, 2016 at 12:51:22AM +0200, Borislav Petkov wrote:
> On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote:
> > A bit of digging will tell us that this is the failing line:
> >
> > m_n_config.v = uv_read_local_mmr(UVH_RH_GAM_CONFIG_MMR );
>
> That looks like
>
> All code
>
On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote:
> A bit of digging will tell us that this is the failing line:
>
> m_n_config.v = uv_read_local_mmr(UVH_RH_GAM_CONFIG_MMR );
That looks like
All code
0: 65 48 03 05 1d b8 49add%gs:0x7e49b81d(%rip),%rax#
On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote:
Adding Boris to Cc.
> Hey guys,
>
> We've hit an issue that we haven't seen before on recent community
> kernels. Hoping that you can provide some insight.
>
> Late last week I hit this bad paging request in uv_system_init on one o
Hey guys,
We've hit an issue that we haven't seen before on recent community
kernels. Hoping that you can provide some insight.
Late last week I hit this bad paging request in uv_system_init on one of
our small UV systems:
8<---
[0.355998] UV: Found UV2000/3000 hub
[0.360088] BUG: unabl
20 matches
Mail list logo
