From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eslFJ-0003fP-QV for qemu-devel@nongnu.org; Mon, 05 Mar 2018 03:13:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eslFE-0006Pr-O4 for qemu-devel@nongnu.org; Mon, 05 Mar 2018 03:13:21 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:35678 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eslFE-0006OS-Iv for qemu-devel@nongnu.org; Mon, 05 Mar 2018 03:13:16 -0500 Date: Mon, 5 Mar 2018 09:13:02 +0100 From: Kevin Wolf Message-ID: <20180305081302.GA4789@localhost.localdomain> References: <1513877118-3149-1-git-send-email-jack.schwartz@oracle.com> <20180115155413.GJ32271@localhost.localdomain> <45620ce8-23c6-3ad5-2393-a5f48c2a9f58@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <45620ce8-23c6-3ad5-2393-a5f48c2a9f58@oracle.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH QEMU v1 0/4] multiboot: bss_end_addr can be zero / cleanup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jack Schwartz Cc: ehabkost@redhat.com, Anatol Pomozov , konrad.wilk@oracle.com, daniel.kiper@oracle.com, mst@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net Am 02.03.2018 um 20:32 hat Jack Schwartz geschrieben: > Hi Kevin. >=20 > On 2018-01-15 07:54, Kevin Wolf wrote: > > Am 21.12.2017 um 18:25 hat Jack Schwartz geschrieben: > > > Properly account for the possibility of multiboot kernels with a ze= ro > > > bss_end_addr. The Multiboot Specification, section 3.1.3 allows fo= r > > > kernels without a bss section, by allowing a zeroed bss_end_addr mu= ltiboot > > > header field. > > >=20 > > > Do some cleanup to multiboot.c as well: > > > - Remove some unused variables. > > > - Use more intuitive header names when displaying fields in message= s. > > > - Change fprintf(stderr...) to error_report > > There are some conflicts with Anatol's (CCed) multiboot series: > > https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03003.htm= l > >=20 > > None if these should be hard to resolve, but it would be good if you > > could agree with each other whose patch series should come first, and > > then the other one should be rebased on top of that. > >=20 > > > Testing: > > > 1) Ran the "make check" test suite. > > > 2) Booted multiboot kernel with bss_end_addr=3D0. (I rolled my = own > > > grub multiboot.elf test "kernel" by modifying source.) Verif= ied > > > with gdb that new code that reads addresses/offsets from mult= iboot > > > header was accessed. > > > 3) Booted multiboot kernel with non-zero bss_end_addr. > > > 4) Uncommented DEBUG_MULTIBOOT in multiboot.c and verified messa= ges worked. > > > 5) Code has soaked in an internal repo for two months. > > Can you integrate your test kernel from 2) in tests/multiboot/ so we = can > > keep this as a regression test? > If need be, would you be willing to accept updated versions of these pa= tches > (with another review, of course) without the test file?=A0 I will deliv= er the > test file later once I get company approvals.=A0 I don't want the test = file to > continue holding everything up in the meantime. Sure, let's move forward with what we have now. Please keep me CCed when you send a new version and I'll give it a review and hopeuflly get it merged. Kevin