[PATCH v4 00/47] x86: Improve operation under QEMU

[Simon Glass]

Hi Tom,

On Fri, 14 Mar 2025 at 16:06, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Mar 14, 2025 at 02:44:35PM +0000, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 7 Mar 2025 at 14:23, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote:
> > >
> > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > > > is not perfect.
> > > >
> > > > With both builds, executing the VESA ROM causes an intermittent hang, at
> > > > least on some AMD CPUs.
> > > >
> > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
> > > > is done in a way that works on real hardware but not with QEMU. This
> > > > means that performance is 4-5x slower than it could be, at least on my
> > > > CPU.
> > > >
> > > > We can work around the first problem by using Bochs, which is anyway a
> > > > better choice than VESA for QEMU. The second can be addressed by using
> > > > the same descriptor across the jump to long mode.
> > > >
> > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
> > > >
> > > > In v3 some e820 patches are included to make booting reliable and avoid
> > > > ACPI tables being dropped. Also, several MTTR problems are addressed, to
> > > > support memory sizes above 4GB reliably.
> > >
> > > Do you plan to rebase the prerequisite series' this requires so that it
> > > can be merged?
> >
> > Here's my understanding of where things are:
> >
> > 1. You rejected the membuf series and my replies to try to resolve
> > that haven't gone anywhere yet. So your tree doesn't have any tests
> > for that code and still has the old naming.
>
> https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not
> gratuitous summary of why the series as it stands is a step in the wrong
> direction. Tests are good. They're not a reason to pull an otherwise bad
> series. This series should be rebased to not depend on that series. The
> tests from the other series should be split out.

It's not a bad series, unfortunately. I replied with my own comments
and I stand by them.

I don't mind if you want to drop the #ifdef (which shows how a flag
could be used and the code-size impact). But other than that, I am
firm on this for now. I've already applied it to my tree and a membuf
implementation with tests and without a power-of-two limitation is
important for my current work on distros and expo.

>
> > 2. I sent the first part of the PXE series so you could apply that.
>
> Yes, I should be applying that next week.
>
> > 3. You rejected the second part of this series because it didn't
> > include support for lwip without cmdline. I offered to handle that
> > case later but I'm pretty sure you rejected that too.
>
> That's not how I would characterize it, no. I said you should probably
> focus on sandbox + lwip, since you're the sandbox guru and ask Jerome to
> do the net_loop-alike thing, since he's one of the network custodians
> and the lwip person. I was trying to direct you to where your efforts
> might be most useful but if you insist on instead doing the
> net_loop-alike part and Jerome ack's it, that's fine.

As you know there have been many arguments from the EFI guys about
sandbox and you have already rejected my sandbox-focussed EFI-memory
series for your tree. If I were actually a guru, that wouldn't have
happened.

I see that Jerome has created some tests, which is good.

So really, you should consider applying the full PXE series so that
Jerome can build on that and add support for non-CMDLINE PXE in lwip
in a way that you would like.

>
> > 4. This series is now marked 'changes requested' but the only feedback
> > I see is in the RFC patch.
>
> Yes, rebase to something that can be applied is a change I've requested.
> Because my feedback was "Do you plan to rebase the prerequisite series'
> this requires so that it can be merged?". I would have otherwise merged
> it by now.

OK I sent a PR.

>
> Patchwork reflects mainline status.

OK. I am finding it more and more slow and painful. Since we are
talking about Patchwork, I noticed some patches assigned to me in
there, so I've assigned them to you. I'll try to look there more
often.

Regards,
Simon