Xen-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Elliott Mitchell <ehem+xen@m5p.com>
To: Masami Hiramatsu <masami.hiramatsu@linaro.org>,
	Julien Grall <julien@xen.org>,
	xen-devel@lists.xenproject.org,
	Alex Benn??e <alex.bennee@linaro.org>,
	bertrand.marquis@arm.com, andre.przywara@arm.com,
	Julien Grall <jgrall@amazon.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Jan Beulich <jbeulich@suse.com>,
	Wei Liu <wl@xen.org>, Roger Pau Monn?? <roger.pau@citrix.com>
Subject: Re: Xen-ARM EFI/ACPI problems (was: Re: [PATCH 0/4] xen/arm: Unbreak ACPI)
Date: Fri, 16 Oct 2020 22:12:49 -0700
Message-ID: <20201017051249.GA26457@mattapan.m5p.com> (raw)
In-Reply-To: <20201016223323.GA23508@mattapan.m5p.com>

On Fri, Oct 16, 2020 at 03:33:23PM -0700, Elliott Mitchell wrote:
> On the device I'm on (Raspberry PI 4B with Tianocore -> GRUB -> Xen) I
> discovered a SPCR table shows up if I boot with the device the output is
> plugged into is powered down.  I'm guessing this causes Tianocore to
> advise GRUB/Linux/Xen to boot with a serial console (presenting a Serial
> Port Console Redirect table), whereas if the display device is
> functioning the absense of SPCR is supposed to indicate console on
> framebuffer.
> 
> This means the ACPI_FAILURE case in acpi_iomem_deny_access() simply needs
> to be filled in similar to how it likely is on x86.  Allocate a serial
> port for Xen's use as console, present it to domain 0 as hvc0, and hide
> it from domain 0.

Looks like things are worse than I thought.

Upon examining some of my `dmesg` copies it looks like Linux interprets
the ignore_uart field in STAO tables as applying strictly to the UART
referenced in the SPCR table.  As such, when booted with the framebuffer
available, Linux thinks it can freely access the UART found in the
hardware table.  The specification for the STAO table is apparently
garbage since it only allows a hypervisor to tell a VM to ignore a
single UART.  Instead it really needs to be possible to mask arbitrary
devices.  :-(

As such, for ARM devices which can include framebuffers, I'm guessing Xen
will need to either pass a modified table to domain 0, or simulate the
device sufficiently to prevent concurrent access.  This could be as
simple as simulating a MMIO page which discards all writes.





> Next issue for me will be getting the framebuffer operational.
> Apparently the Xen-ARM EFI implementation doesn't provide any EFI
> variables to domain 0?  Jan Beulich, your name was mentioned as person
> likely to have ideas for getting Linux's efifb code operational Xen-ARM.

There may be multiple pieces to this.

For the framebuffer this might be as simple as parsing the BGRT table and
ensuring the addresses are directly mapped to domain 0.  I just noticed
in dmesg, "efi_bgrt: Ignoring BGRT: invalid image address".  I'm guessing
one thing got remapped, but a second didn't.

The other need for EFI variable access is for modifying EFI's boot
process.  While I suspect it may be feasible for most users to reboot to
a kernel directly on hardware to update GRUB/other bootloader, adding an
extra step increases the potential for a failure at the Wrong Time.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445




  reply index

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-26 20:55 [PATCH 0/4] xen/arm: Unbreak ACPI Julien Grall
2020-09-26 20:55 ` [PATCH 1/4] xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory() Julien Grall
2020-09-28  8:18   ` Jan Beulich
2020-09-28  9:58     ` Julien Grall
2020-09-28 10:09       ` Jan Beulich
2020-09-28 10:39         ` Julien Grall
2020-10-10  9:49           ` Julien Grall
2020-10-10 10:04             ` Julien Grall
2020-09-29 11:10   ` Rahul Singh
2020-10-01  0:06   ` Stefano Stabellini
2020-10-01 15:09     ` Julien Grall
2020-09-26 20:55 ` [PATCH 2/4] xen/arm: acpi: The fixmap area should always be cleared during failure/unmap Julien Grall
2020-09-29 11:13   ` Rahul Singh
2020-10-01  0:30   ` Stefano Stabellini
2020-10-01 15:14     ` Julien Grall
2020-09-26 20:55 ` [PATCH 3/4] xen/arm: Check if the platform is not using ACPI before initializing Dom0less Julien Grall
2020-09-29 11:17   ` Rahul Singh
2020-09-30 23:26   ` Stefano Stabellini
2020-09-26 20:55 ` [PATCH 4/4] xen/arm: Introduce fw_unreserved_regions() and use it Julien Grall
2020-09-30 23:40   ` Stefano Stabellini
2020-10-01 15:34     ` Julien Grall
2020-09-27  1:47 ` [PATCH 0/4] xen/arm: Unbreak ACPI Elliott Mitchell
2020-09-29 15:28   ` Elliott Mitchell
2020-09-28  6:47 ` Masami Hiramatsu
2020-09-28 13:00   ` Masami Hiramatsu
2020-10-16 22:33     ` Xen-ARM EFI/ACPI problems (was: Re: [PATCH 0/4] xen/arm: Unbreak ACPI) Elliott Mitchell
2020-10-17  5:12       ` Elliott Mitchell [this message]
2020-10-08 18:39   ` [PATCH 0/4] xen/arm: Unbreak ACPI Elliott Mitchell
2020-10-09  9:39     ` Julien Grall
2020-10-09 14:22       ` Elliott Mitchell
2020-10-09 18:15         ` Julien Grall
2020-10-09 22:36           ` Elliott Mitchell
2020-10-09 21:49   ` Elliott Mitchell
2020-10-10 11:02   ` Julien Grall
2020-10-12 19:02     ` Stefano Stabellini
2020-10-12 21:34       ` Elliott Mitchell
2020-10-14  1:06         ` Stefano Stabellini
2020-10-14  1:37           ` Elliott Mitchell
2020-10-14 17:47             ` Julien Grall
2020-10-15 18:00               ` Stefano Stabellini
2020-10-14 17:44       ` Julien Grall
2020-09-29 11:10 ` Rahul Singh
2020-09-29 15:29 ` Alex Bennée
2020-09-29 17:07   ` Julien Grall
2020-09-29 21:11     ` Alex Bennée
2020-09-29 23:39       ` André Przywara
2020-09-30  8:51         ` Alex Bennée
2020-09-30 10:35         ` Julien Grall
2020-09-30  9:42       ` Julien Grall
2020-09-30 10:38         ` Alex Bennée
2020-09-30 11:10           ` Julien Grall

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=20201017051249.GA26457@mattapan.m5p.com \
    --to=ehem+xen@m5p.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=alex.bennee@linaro.org \
    --cc=andre.przywara@arm.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=jgrall@amazon.com \
    --cc=julien@xen.org \
    --cc=masami.hiramatsu@linaro.org \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --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

Xen-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/xen-devel/0 xen-devel/git/0.git
	git clone --mirror https://lore.kernel.org/xen-devel/1 xen-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 xen-devel xen-devel/ https://lore.kernel.org/xen-devel \
		xen-devel@lists.xenproject.org xen-devel@lists.xen.org
	public-inbox-index xen-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.xenproject.lists.xen-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git