[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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. 

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.