Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

[Roman Shaposhnik <roman@xxxxxxxxxx>]

Hi Marek, after applying Jan's patch I'm making much further progress.
Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
my end).

I'm attaching the logs from Xen and Dom0.

At this point it seems that adding efi=attr=uc is a better option for
these boxes than a wholesale efi=no-rs

Question #1: is this something that EFI_SET_VIRTUAL_ADDRESS_MAP was
supposed to cover by default (so I don't have to add efi=attr=uc)?

Question #2: is there any downside to *always* specifying efi=attr=uc?
Even for servers that, strictly speaking, don't need it?

Thanks,
Roman.

On Mon, Nov 25, 2019 at 11:02 PM Roman Shaposhnik <roman@xxxxxxxxxx> wrote:
>
> On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki
> <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> > > On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
> > > <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > > Do you have by
> > > > a chance messages of that crash (without efi=no-rs, but with
> > > > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial 
> > > > output is
> > > > available?
> > >
> > > With my awesome soldering skills ;-) I managed to rig a serial console.
> > >
> > > Output is attached. Please let me know if you'd like me to run any
> > > other experiments.
> >
> > Looks helpful, lets try to do something:
> >
> > >  Xen 4.13.0-rc
> > > (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y  Tue 
> > > Nov 26 03:19:38 UTC 2019
> > > (XEN) Latest ChangeSet:
> > > (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80
> > > (XEN) Bootloader: GRUB 2.03
> > > (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot 
> > > dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
> > (...)
> > > (XEN) EFI memory map:
> > (...)
> > > (XEN)  0000077587000-00000775f4fff type=5 attr=800000000000000f
> >
> > This is code that crashes - runtime services code, so somewhere with
> > actual UEFI code.
>
> Yup -- that was my hunch with adding efi=no-rs option.
>
> > (...)
> > > (XEN)  00000ff900000-00000ffffffff type=11 attr=8000000000000000
> > > (XEN) Unknown cachability for MFNs 0xff900-0xfffff
> >
> > The faulting address is in this range. And because of unknown
> > cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen
> > cmdline.
>
> Feels like we're getting exactly the same failure. Log attached.
>
> Thanks,
> Roman.

Attachment: xen3.txt
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel