qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Jiahui Cen <cenjiahui@huawei.com>
Cc: xieyingtai@huawei.com, Igor Mammedov <imammedo@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH] acpi/gpex: Inform os to keep firmware resource map
Date: Wed, 21 Jul 2021 22:22:37 -0700	[thread overview]
Message-ID: <20210722052237.GA327218@roeck-us.net> (raw)
In-Reply-To: <20201217132926.4812-1-cenjiahui@huawei.com>

Hi,

On Thu, Dec 17, 2020 at 09:29:26PM +0800, Jiahui Cen wrote:
> There may be some differences in pci resource assignment between guest os
> and firmware.
> 
> Eg. A Bridge with Bus [d2]
>     -+-[0000:d2]---01.0-[d3]----01.0
> 
>     where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref) [size=256]
>           [d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) [size=128K]
>                                           BAR4 (mem, 64-bit, pref) [size=64M]
> 
>     In EDK2, the Resource Map would be:
>         PciBus: Resource Map for Bridge [D2|01|00]
>         Type = PMem64; Base = 0x8004000000;     Length = 0x4100000;     Alignment = 0x3FFFFFF
>            Base = 0x8004000000; Length = 0x4000000;     Alignment = 0x3FFFFFF;  Owner = PCI [D3|01|00:20]
>            Base = 0x8008000000; Length = 0x20000;       Alignment = 0x1FFFF;    Owner = PCI [D3|01|00:10]
>         Type =  Mem64; Base = 0x8008100000;     Length = 0x100; Alignment = 0xFFF
> 
>     While in Linux, kernel will use 0x2FFFFFF as the alignment to calculate
>     the PMem64 size, which would be 0x6000000.
> 
> The diffences could result in resource assignment failure.
> 
> Using _DSM #5 method to inform guest os not to ignore the PCI configuration
> that firmware has done at boot time could handle the differences.
> 
> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>

Since this patch is in qemu (ie starting with qemu v6.0), some of my qemu
tests booting aarch64 systems with efi bios no longer work. For example,
the following command fails to instantiate the Ethernet interface.

CMDLINE="root=/dev/vda console=ttyAMA0"
ROOTFS="rootfs.ext2"

qemu-system-aarch64 -M virt -kernel arch/arm64/boot/Image -no-reboot \
	-m 512 -cpu cortex-a57 -no-reboot \
	-device tulip,netdev=net0 -netdev user,id=net0 \
	-bios QEMU_EFI-aarch64.fd \
	-snapshot \
	-device virtio-blk-device,drive=d0 \
	-drive file=${ROOTFS},if=none,id=d0,format=raw \
	-nographic -serial stdio -monitor none \
	--append "${CMDLINE}"

QEMU_EFI-aarch64.fd is from https://retrage.github.io/edk2-nightly/.

Key difference is PCI BAR assignment.

good (qemu v5.2):

[    3.921801] pci 0000:00:01.0: [1011:0019] type 00 class 0x020000
[    3.922207] pci 0000:00:01.0: reg 0x10: [io  0x0000-0x007f]
[    3.922505] pci 0000:00:01.0: reg 0x14: [mem 0x10000000-0x1000007f]
[    3.927111] pci 0000:00:01.0: BAR 0: assigned [io  0x1000-0x107f]
[    3.927455] pci 0000:00:01.0: BAR 1: assigned [mem 0x10000000-0x1000007f]

bad (qemu v6.0 and later):

[    3.922887] pci 0000:00:01.0: [1011:0019] type 00 class 0x020000
[    3.923278] pci 0000:00:01.0: reg 0x10: [io  0x0000-0x007f]
[    3.923451] pci 0000:00:01.0: reg 0x14: [mem 0x10000000-0x1000007f]

Reverting this patch fixes the problem.

Does this mean that I can no longer run aarch64 efi boot tests
with qemu v6.0 and later if the test involves PCI devices ?
Or is there some alternative command line which would still work ?

Thanks,
Guenter


      parent reply	other threads:[~2021-07-22  5:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 13:29 Jiahui Cen
2020-12-17 13:52 ` Jiahui Cen
2020-12-17 17:23   ` Laszlo Ersek
2020-12-17 19:24     ` Ard Biesheuvel
2020-12-17 18:29 ` Michael S. Tsirkin
2020-12-18  5:56   ` Jiahui Cen
2020-12-17 20:04 ` Michael S. Tsirkin
2020-12-18  5:56   ` Jiahui Cen
2020-12-19 19:06     ` Michael S. Tsirkin
2020-12-21  1:12       ` Jiahui Cen
2021-07-22  5:22 ` Guenter Roeck [this message]

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=20210722052237.GA327218@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=cenjiahui@huawei.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=xieyingtai@huawei.com \
    --subject='Re: [PATCH] acpi/gpex: Inform os to keep firmware resource map' \
    /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

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).