Hi Tom, On Tue, 18 Mar 2025 at 00:05, Tom Rini <tr...@konsulko.com> wrote: > > [cc list trimmed and adding Rasmus] > > On Sat, Mar 15, 2025 at 02:38:29PM +0000, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 15 Mar 2025 at 13:57, Tom Rini <tr...@konsulko.com> wrote: > > > > > > 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 <tr...@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 <tr...@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. > > > > It doesn't affect this series. It is for future work. > > > > We'll see if the LTPC replies to my concerns. > > Well, I guess I'm going to regret choosing to not chime in there at the > time and say that no, working against your tree is the wrong direction. > There's certainly enough feedback in that thread for you to make a v2 > against mainline. Because to be clear, no, your v1 isn't going in > mainline.
Firstly it does not affect this series, so I hope you can pull this series in soon. This is the first I've heard of a v2 for membuf. From my side I don't want to rewrite it to use a different algorithm, nor force it to use a power-of-two size. That was not the point of my series. Here is the cover letter: >>>> The membuff implementation curently has no tests. It also assumes that head and tail can never correspond unless the buffer is empty. This series provides a compile-time flag to support a 'full' flag. It also adds some tests of the main routines. The data structure is also renamed to membuf which fits better with U-Boot. There may be some cases in the code which could be optimised a little, but the implementation is functional. <<<< As I said, I'm happy to drop the addition of a compile-time flag. It was mostly to see if anyone thought it was a good idea. So how about just applying the first 7 patches? I can do a revert of patch 8 in my tree. Then if Rasmus wants to rewrite it he can do so, so long as the power-of-two size isn't mandatory. Regards, Simon
