Re: [Xen-devel] EFI Xen unstable crashes on Dell E6410 when calling efi_get_time.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Oct 22, 2014 at 11:22:17AM +0100, Jan Beulich wrote:
> >>> On 22.10.14 at 11:45, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 22/10/14 01:29, Marcos E. Matsunaga wrote:
> >> I went out and got the serial cable. Attached is the full output.
> >>
> >>
> >> On 10/21/2014 05:06 PM, Marcos E. Matsunaga wrote:
> >>> Folks,
> >>>
> >>> I am trying to boot Xen using efibootmgr on a Dell E6410 laptop with
> >>> 4GB RAM, running an Intel I5 dual core with VT and all the
> >>> virtualization options enabled.
> >>>
> >>> It crashes almost immediately. I am working on getting the serial
> >>> console up so that I can get a more detailed stack.
> >>>
> >>> A screenshot of the console is attached.
> >>>
> >>> The xen.cfg file is:
> >>>
> >>> [global]
> >>> default=xen
> >>>
> >>> [xen]
> >>> options=console=vga,com1 com1=115200,8n1 dom0_max_vcpus=2 vga="qxl"
> >>> kernel=vmlinuz-3.8.13-48.el7uek.Other_EFI_v1.x86_64
> >>> root=UUID=917bfc7f-8d9c-4acf-a98a-a9f558daccf2  ro console=hvc0
> >>> enforcing=0 biosdevname=0 earlyprintk=xen nomodeset
> >>> ramdisk=initramfs-3.8.13-48.el7uek.Other_EFI_v1.x86_64.img
> >>>
> >>>
> >>> The codepath is "(gdb) x/20i get_cmos_time
> >>>    0xffff82d080188825 <get_cmos_time>:  push   %rbp
> >>>    0xffff82d080188826 <get_cmos_time+1>:        mov %rsp,%rbp
> >>>    0xffff82d080188829 <get_cmos_time+4>:        push   %r12
> >>>    0xffff82d08018882b <get_cmos_time+6>:        push   %rbx
> >>>    0xffff82d08018882c <get_cmos_time+7>:        cmpb
> >>> $0x0,0xb620d(%rip)        # 0xffff82d08023ea40 <efi_enabled>
> >>>    0xffff82d080188833 <get_cmos_time+14>:       je 0xffff82d080188843
> >>> <get_cmos_time+30>
> >>>    0xffff82d080188835 <get_cmos_time+16>:       callq
> >>> 0xffff82d080100069 <efi_get_time>"
> >>>
> >>
> > 
> > Ok - there are two separate bugs here.
> > 
> > The first is that we call into the efi runtime via efi_rs->GetTime, and
> > a pagefault happens for the instruction at 0x00000000db25a33d for the
> > virtual address 0x00000000fed1f410
> > 
> > The memory map looks quite weird, but the faulting address is covered in
> > this range.
> > 
> > (XEN)  00000fed1c000-00000fed1ffff type=11 attr=8000000000000000

type 11 is 
> > 
> > So I would expect it to be mapped into the EFI pagetables.
> 
> Then you must have missed
> 
> (XEN) Unknown cachability for MFNs 0xfed1c-0xfed1f
> 
> which means no mapping got established (as we don't know what
> cachability attributes to give to it).
> 
> This is a firmware bug.

Could we use the UC- by default? Looking at the Linux code
(efi_enter_virtual_mode_generic, it will pick 'efi_ioremap' which
calls 'ioremap' (which calls ioremap_nocache)


diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index f272171..d567675 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1160,9 +1160,13 @@ void __init efi_init_memory(void)
             prot |= _PAGE_PWT | _PAGE_PCD | MAP_SMALL_PAGES;
         else
         {
-            printk(XENLOG_ERR "Unknown cachability for MFNs %#lx-%#lx\n",
-                   smfn, emfn - 1);
-            continue;
+            printk(XENLOG_ERR "Unknown cachability for MFNs %#lx-%#lx %s\n",
+                   smfn, emfn - 1,
+                   desc->Type == EfiMemoryMappedIO ? "using UC-" : "");
+            if ( desc->type == EfiMemoryMappedIO )
+                prot |= _PAGE_PWT | _PAGE_PCD | MAP_SMALL_PAGES;
+            else
+                continue;
         }
 
         if ( desc->Attribute & EFI_MEMORY_WP )
> 
> > The EFI code is a mix of #ifdefs.  Can you confirm whether you are
> > compiling with USE_SET_VIRTUAL_ADDRESS_MAP or not?
> 
> No-one should be altering these, their presence is purely for
> documentation purposes.

The build was just a pure 'make' so whatever the default ones are.
> 
> > The second is that once the pagefault has happened, we trap back into
> > Xen and attempt to do a pagetable walk, falling over an assertion in
> > map_domain_page().
> > 
> > For EFI calls, we run on the efi pagetables, not the idle pagetables, so
> > I am not surprised that the assertion has failed.  I suspect that the
> > pagefault hander for hypervisor faults needs to become wise to the fact
> > that we may receive a fault when calling into the firmware.  As all the
> > efi pagetables are xenheap pages, there is nothing conceptually wrong
> > with using map_domain_page() to do the walk.
> 
> I'm not sure it's worth taking care of this special case. But yes, if
> we really want to, extending the condition to also consider
> efi_l4_pgtable would seem the right thing to do.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel