Re: Xen 4.14.0 is busted on Dell 300x IoT Gateways

[Roman Shaposhnik <roman@xxxxxxxxxx>]

Hi Andrew!

thanks for replying so quickly -- much appreciated.

On Tue, Aug 18, 2020 at 3:20 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

On 18/08/2020 23:09, Roman Shaposhnik wrote:
> Hi!
>
> first things first -- booting on those devices have always
> required efi=no-rs

That is a bug.  Please start a separate thread about it.  EFI Runtime
Services are de-facto mandatory on modern systems, and it is totally
unacceptable (from a users perspective) that Xen just doesn't work by
default.

It needs fixing.

Sure, but right now it is tough to start that thread on account of not having

anything functional on these devices -- I can remove byt_gpio support from

the linux kernel -- but that doesn't seem right to me.

IOW, I don't really have a functional Dom0. If someone can help with that -- I can

then start the thread.

Also, just as an observation, I wouldn't surprised if UEFI implementation

on these devices pushes the envelope on what it means to be standard

compliant UEFI so to speak -- but you're 100% right -- if we can make

Xen run on them without tweaks -- that'd be awesome.

 

> -- but it seems that Xen 4.14 is now 
> busted at a more fundamental level. I'm attaching two
> boot sequences (one with kernel 4.19.5 and one with 5.4.51)
> in the hopes that this may provide some clues right away.

As a note, from your logs:

Kernel command line: console=hvc0 root=(hd0,gpt1)/rootfs.img
dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin
eve_mem=650M,max:650M eve_max_vcpus=1 ctrd_mem=300M,max:300M
ctrd_max_vcpus=1 rootdelay=3 setup_loops eve_installer

You've got some Xen command line parameters on the Kernel command line,
which won't be helping matters.

That's actually on purpose -- Project EVE uses Xen syntax for setting

up these values for cases where we are not running under Xen and need

to tickle other hypervisors (like KVM or ACRN) just so from the Dom0 itself.

See below on running without Xen.

 

>
> Any help would be greatly appreciated!
>
> Oh, and finally it appears that this is NOT a regression from
> Xen 4.13 -- it fails the same way. I haven't tried Xen's earlier
> than that.

This is a Linux issue, not a Xen issue.

It seems like a combination of both frankly -- note that very same kernels

have no trouble booting without Xen and work perfectly with KVM.

 

It is hitting a BUG_ON() while setting up interrupts.

Interestingly, they are both in byt_gpio_runtime_resume() which I guess
is BayTrail as the Intel platform, which probably means that something
pertaining to GPIO interrupts isn't being initialised normally.

Or Xen isn't passing some vital info to the Linux kernel. Or setting up some

weird memory mapping, etc. Like I said -- there's no issue with running

these kernels by themselves.

Thanks,

Roman.