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

[Tom Rini]

On Sat, Mar 15, 2025 at 12:54:25PM +0000, Simon Glass wrote:
> 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.

Well, you need to rebase this series without that then as I'm not going
to take something another long time project contributor said was wrong
and offered lots of constructive feedback on.

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

I saw that Jerome posted sandbox for lwip as well and was pleased. You
can pickup whatever is left and move forward once both your current
series and his have been merged.

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

Eh? v4 as-is needs to be rebased to mainline. That you didn't make it
against mainline but instead your tree is why this wasn't merged
already.

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

I guess you missed the email where I told you what was assigned to you
in patchwork and could easily be put in a pull request by you to me to
get to mainline.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250315/2d4c0652/attachment.sig>