public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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