From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Cc: devel@edk2.groups.io, Jordan Justen <jordan.l.justen@intel.com>,
Pawel Polawski <ppolawsk@redhat.com>,
Jiewen Yao <jiewen.yao@intel.com>,
Oliver Steffen <osteffen@redhat.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Thomas Lamprecht <t.lamprecht@proxmox.com>
Subject: Re: [edk2-devel] [PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size
Date: Mon, 22 May 2023 13:12:00 +0200 [thread overview]
Message-ID: <sr6qlgpp2zezngdkjgqewa2or3oqisqscnvkgrpiyj2mxxbmuo@j7fuwcgc42jc> (raw)
In-Reply-To: <d8f5be6d-1a79-5e34-d006-56e36bab2b3d@proxmox.com>
> The errors for the virtio devices are:
> > virtio_scsi virtio1: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
> > virtio_scsi: probe of virtio1 failed with error -22
> > virtio_net virtio2: virtio: device uses modern interface but does not have VIRTIO_F_VERSION_1
> > virtio_net: probe of virtio2 failed with error -22
I guess something goes wrong with accessing the mmio pci bars.
Seems to be a linux kernel bug in 4.15, when installing the hwe
kernel (5.4) it works fine for me.
> In the kern.log, I didn't really see any interesting differences, except
> for the errors above. The addresses are different and there is now a
> 64-bit bridge window, but I guess that's expected.
>
> > + pci 0000:00:1e.0: bridge window [mem 0x700000000000-0x700fffffffff 64bit pref]
Yes.
> Not sure if this is interesting either, but part of the diff between the
> lspci outputs (first with the call, second without the call):
>
> > ***************
> > *** 75,88 ****
> > 00:05.0 SCSI storage controller: Red Hat, Inc Virtio SCSI
> > Subsystem: Red Hat, Inc Virtio SCSI
> > Physical Slot: 5
> > ! Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
INTx enabled.
> > ! Capabilities: [98] MSI-X: Enable+ Count=7 Masked-
MSI-X enabled.
That probably comes from the driver exiting early (and not configuring
interrupts).
The patch below fixes it for me. Can you confirm this?
take care,
Gerd
>From 05fdf93b17decc42dde2ba89e935616eceb705c4 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon, 22 May 2023 13:04:35 +0200
Subject: [PATCH 1/1] [testing] older linux kernels seem to have problems with
phys-bits > 46
---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index acf90b4e93fd..0482d8906d5c 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -646,16 +646,19 @@ PlatformAddressWidthFromCpuid (
));
if (Valid) {
- if (PhysBits > 47) {
+ if (PhysBits > 46) {
/*
* Avoid 5-level paging altogether for now, which limits
* PhysBits to 48. Also avoid using address bit 48, due to sign
* extension we can't identity-map these addresses (and lots of
* places in edk2 assume we have everything identity-mapped).
* So the actual limit is 47.
+ *
+ * Also some older linux kernels apparently have problems handling
+ * phys-bits > 46 correctly, so use that as limit.
*/
- DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 47 (avoid 5-level paging)\n", __func__));
- PhysBits = 47;
+ DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 46 (avoid 5-level paging)\n", __func__));
+ PhysBits = 46;
}
if (!Page1GSupport && (PhysBits > 40)) {
--
2.40.1
next prev parent reply other threads:[~2023-05-22 11:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 13:47 [PATCH v2 0/4] OvmfPkg: make better use of physical address space Gerd Hoffmann
2022-10-04 13:47 ` [PATCH v2 1/4] OvmfPkg/PlatformInitLib: qemu cpuid physbits detection Gerd Hoffmann
2022-10-04 13:47 ` [PATCH v2 2/4] OvmfPkg/PlatformInitLib: detect physical address space Gerd Hoffmann
2023-03-16 13:58 ` f.ebner
2023-03-16 14:37 ` Gerd Hoffmann
2023-03-17 11:34 ` [edk2-devel] " Fiona Ebner
2023-03-17 14:01 ` Gerd Hoffmann
2023-03-20 14:20 ` Fiona Ebner
2023-03-20 15:58 ` Gerd Hoffmann
2022-10-04 13:47 ` [PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size Gerd Hoffmann
2023-03-15 8:54 ` [edk2-devel] " joeyli
2023-03-15 9:28 ` Gerd Hoffmann
2023-05-16 14:00 ` Fiona Ebner
2023-05-17 5:59 ` [edk2-devel] " Gerd Hoffmann
2023-05-17 13:38 ` Fiona Ebner
2023-05-22 11:12 ` Gerd Hoffmann [this message]
2023-05-22 13:36 ` Fiona Ebner
2022-10-04 13:47 ` [PATCH v2 4/4] OvmfPkg/PciHotPlugInitDxe: reserve more mmio space Gerd Hoffmann
2022-10-04 15:57 ` Laszlo Ersek
2022-10-05 5:01 ` Gerd Hoffmann
2022-10-06 8:50 ` Laszlo Ersek
2022-10-07 21:49 ` [edk2-devel] [PATCH v2 0/4] OvmfPkg: make better use of physical address space Ard Biesheuvel
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-list 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=sr6qlgpp2zezngdkjgqewa2or3oqisqscnvkgrpiyj2mxxbmuo@j7fuwcgc42jc \
--to=devel@edk2.groups.io \
/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