From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlFdl-0001jk-FN for qemu-devel@nongnu.org; Tue, 26 Nov 2013 05:13:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlFdf-0007bc-GF for qemu-devel@nongnu.org; Tue, 26 Nov 2013 05:13:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlFdf-0007bK-7o for qemu-devel@nongnu.org; Tue, 26 Nov 2013 05:13:03 -0500 Date: Tue, 26 Nov 2013 12:16:17 +0200 From: "Michael S. Tsirkin" Message-ID: <20131126101617.GB19371@redhat.com> References: <20131111213933.GG13775@HEDWIG.INI.CMU.EDU> <20131111221821.GH13775@HEDWIG.INI.CMU.EDU> <528E4D83.6070708@redhat.com> <20131121220207.GO13775@HEDWIG.INI.CMU.EDU> <528F1D24.8070209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528F1D24.8070209@redhat.com> Subject: Re: [Qemu-devel] os x boot broken by commit 11948748495841bd54721b250d68c7b3cb0475ef List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: agraf@suse.de, "Gabriel L. Somlo" , seabios@seabios.org, kraxel@redhat.com, qemu-devel@nongnu.org On Fri, Nov 22, 2013 at 10:00:20AM +0100, Paolo Bonzini wrote: > Il 21/11/2013 23:02, Gabriel L. Somlo ha scritto: > > On Thu, Nov 21, 2013 at 07:14:27PM +0100, Paolo Bonzini wrote: > >> > Can you remind us about your DSDT modifications? It should be possible > >> > to patch the HPET and applesmc bits appropriately from QEMU (or to move > >> > them from the DSDT to an SSDT that is built entirely in QEMU). > >> > > >> > It actually isn't impossible that Mac OS X would boot just fine with 1.8... > > My current DSDT patch (against QEMU) is enclosed below. The HPET > > basically needs "IRQNoFlags() {2, 8}", which causes XP to bluescreen. > > The IRQNoFlags(){2,8} setting makes sense if the general configuration > register of the HPET has bits 0..1=1 (HPET enabled = 1 and HPET legacy > replacement route = 1). > > That would be something like > > Field(HPTM, DWordAcc, Lock, Preserve) { > VEND, 32, > PRD, 32, > UNUS, 32 > GCNF, 32 > } > > ... > > Method(_CRS, 0) { > Store(GCNF, Local0) > If (LEqual(LAnd(Local0, 3), 3)) { // Legacy replacement route > ConcatenateResTemplate(RESP, RESI, Local1) > Return (Local1) > } else { > Return (RESP) > } > } Which reminds me. We run C preprocessor over the source so there's no good reason to use 4-byte names anymore really (iasl also has an integrated preprocessor but that only appeared in 2012, not sure it's wise to rely on that). So simply #define HPET_MEMORY HPTM and use HPET_MEMORY everywhere. > If that doesn't work, there are various choices here... > > (1) Does Mac OS work if you add a _PRS with IRQNoFlags and > Memory32Fixed, but leave _CRS as it is? > > (2) does it work with -no-hpet? > > (3) you could also make that dependent on _OSI("Darwin"). It's unlikely > that Linux and/or Windows expose _OSI("Darwin"), and anyway the BSOD is > only there for Windows XP as I understand it. > > > So, I've made it conditional on the SMC STA method returning success > > (0x0B). > > That would mean that running Windows XP on "Mac OS X hardware" breaks, > though. > > > The SMC node's STA method returns 0x0B unconditionally on real > > hardware. So I was planning on figuring out what's easier in the > > context of the most recent QEMU code base: > > > > 1. dynamically generating (during qemu runtime initialization) > > a DSDT entry for SMC with hardcoded 0x0B STA method, whenever > > "--device isa-applesmc" is present on the qemu command line > > > > or > > > > 2. writing a static (compile-time) SMC node but with a slightly > > smarter _STA method, which returns 0x0B when "--device isa-applesmc" > > was given on the cmdline, or which returns 0x00 in the absence > > of "--device isa-applesmc". > > Either would work. See acpi_get_misc_info and patch_ssdt in > hw/i386/acpi-build.c. > > I think device-dependent ACPI stuff should become a QOM interface, but > you need not do that. > > Paolo