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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

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

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

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

Patchwork reflects mainline status.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]