From: Peter Maydell <peter.maydell@linaro.org>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: virtio-pci in qemu-system-arm is broken in 8.2
Date: Tue, 9 Jan 2024 16:31:21 +0000 [thread overview]
Message-ID: <CAFEAcA83r12Y6d5Ba-3v1eNe1TfA9kO-PLtkots8C1SzgDNeaA@mail.gmail.com> (raw)
In-Reply-To: <2a34bd5d-2997-48cf-bcb8-32d97e3f7690@tls.msk.ru>
On Tue, 9 Jan 2024 at 16:24, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> 09.01.2024 16:52, Peter Maydell:
> ..
> > Oh, your kernel isn't an LPAE one (i.e. CONFIG_LPAE is not
> > set). That will obviously never be able to access registers
> > above the 4GB mark (though the kernel's error message in this
> > situation is a bit unhelpful and could perhaps be improved).
> > If I set CONFIG_LPAE on the non-working config it starts working.
> >
> > I think then the answer is:
> > * if you want to use the (default) highmem setup, use an LPAE kernel
> > * if you want to use a non-LPAE kernel, tell QEMU to avoid
> > highmem using '-machine virt,highmem=off'
> >
> > It was just a bug that we were accidentally disabling highmem
> > for the 32-bit 'max' CPU before b8f7959f28c4f3.
>
> Wow wow wow. So it's a pebkac bug, not qemu bug.. :)
> I didn't even know about LPAE before this email, and knew very
> little about arm stuff too.
>
> Thank you very much for your work and time!
>
> The diagnostics here is definitely.. "interesting", so to say, it's
> very "obvious" what the problem is.. from the kernel messages :)
Yeah. I don't personally have the time to try to follow up
on improving the kernel handling of this, but if anybody else
does, I think the problem is that the function __of_address_to_resource()
which fills in a 'struct resource' from a DTB entry silently
truncates over-large values when it fills in r->start and r->end
(which are of type phys_addr_t, and so only 32 bits on non-LPAE
kernels). So that function seems like a good place to put some
if (taddr or taddr + size are above 4GB) {
warn("resource foo is too high in the address space to use
(did you forget to enable CONFIG_LPAE?)\n");
return -EINVAL;
}
type handling which would then catch this user error relatively
comprehensibly for most devices.
> And the author(s) of the tool used in debian to run arm guest (which
> triggered this issue with qemu 8.2) didn't know this thing either,
> obviously. Also, it seems to be a little-known fact that qemu has
> highmem enabled for 32bit arm by default and that one - unlike e.g
> i386 - actually breaks system (with pci bus being unaccessible),
> while on i386 the only outcome is not all memory is available.
> That feels like unfortunate decision to enable highmem by default
> on arm in qemu 2.12.
Yeah, in retrospect the other option might have been better.
But at this late date it doesn't seem worth revisiting.
> > The linux-image-6.6.9-armmp-lpae_6.6.9-1_armhf.deb kernel
> > will probably work (though I haven't tested it).
>
> Yes, it works. Also -machine virt,highmem=off works. There's
> no bug per se.
>
>
> Thank you for all the findings, Peter! Much appreciated!
No worries.
-- PMM
next prev parent reply other threads:[~2024-01-09 16:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 11:51 virtio-pci in qemu-system-arm is broken in 8.2 Michael Tokarev
2023-12-21 18:18 ` Alex Bennée
2023-12-21 22:00 ` Alex Bennée
2024-01-04 14:09 ` Peter Maydell
2024-01-04 14:31 ` Peter Maydell
2024-01-04 14:41 ` Peter Maydell
2024-01-04 16:25 ` Michael Tokarev
2024-01-04 17:17 ` Michael Tokarev
2024-01-05 14:09 ` Peter Maydell
2024-01-08 17:07 ` Peter Maydell
2024-01-08 17:38 ` Michael Tokarev
2024-01-09 11:33 ` Peter Maydell
2024-01-09 13:52 ` Peter Maydell
2024-01-09 14:21 ` Alex Bennée
2024-01-09 14:31 ` Peter Maydell
2024-01-09 15:03 ` Alex Bennée
2024-01-09 16:26 ` Eric Auger
2024-01-09 16:24 ` Michael Tokarev
2024-01-09 16:31 ` Peter Maydell [this message]
2024-01-09 16:41 ` Peter Maydell
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=CAFEAcA83r12Y6d5Ba-3v1eNe1TfA9kO-PLtkots8C1SzgDNeaA@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.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).