xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Roman Shaposhnik <roman@zededa.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Paul Durrant" <paul@xen.org>, "Jan Beulich" <jbeulich@suse.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>
Subject: Re: Xen 4.14.0 is busted on Dell 300x IoT Gateways
Date: Tue, 18 Aug 2020 15:34:01 -0700	[thread overview]
Message-ID: <CAMmSBy8TQuF2qqVUBv1=LyA_tcDC-c_z80NgiXnDPo2OJCzg7g@mail.gmail.com> (raw)
In-Reply-To: <0f6b9a9d-e25f-c2ae-ea2b-fd13107a3b06@citrix.com>

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

Hi Andrew!

thanks for replying so quickly -- much appreciated.

On Tue, Aug 18, 2020 at 3:20 PM Andrew Cooper <andrew.cooper3@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.

[-- Attachment #2: Type: text/html, Size: 4633 bytes --]

  reply	other threads:[~2020-08-18 22:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18 22:09 Xen 4.14.0 is busted on Dell 300x IoT Gateways Roman Shaposhnik
2020-08-18 22:20 ` Andrew Cooper
2020-08-18 22:34   ` Roman Shaposhnik [this message]
2020-08-21  1:39 ` Stefano Stabellini
2020-08-21  7:15 ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Sergey Temerkhanov
2020-08-21  7:15   ` [PATCH 1/2] Xen: Use a dedicated irq_info structure pointer Sergey Temerkhanov
2020-08-21  7:15   ` [PATCH 2/2] Xen: Rename irq_info structure Sergey Temerkhanov
2020-08-21 10:18   ` [PATCH 0/2] Xen: Use a dedicated pointer for IRQ data Jürgen Groß
2020-08-21 11:19     ` Sergei Temerkhanov
2020-08-21 12:17       ` Jürgen Groß
2020-08-21 20:07         ` Thomas Gleixner
2020-08-21 20:38           ` Sergei Temerkhanov
2020-08-22  0:16             ` Thomas Gleixner
2020-08-25  3:14           ` Stefano Stabellini
2020-08-25  8:58             ` Thomas Gleixner
2020-08-25 13:49               ` Jürgen Groß
2020-08-25 15:22                 ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer, Thomas Gleixner
2020-08-25 15:43                   ` [PATCH] xen/events: Use chip data for storing per IRQ XEN data pointer Jürgen Groß
2020-08-25 22:04                     ` Roman Shaposhnik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMmSBy8TQuF2qqVUBv1=LyA_tcDC-c_z80NgiXnDPo2OJCzg7g@mail.gmail.com' \
    --to=roman@zededa.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).