Hi Andrew! thanks for replying so quickly -- much appreciated.
On Tue, Aug 18, 2020 at 3:20 PM Andrew Cooper <andrew.coop...@citrix.com> 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.
