| Message ID | 20140121181101.GB1323@ERROL.INI.CMU.EDU |
|---|---|
| State | New |
| Headers | show |
On Tue, Jan 21, 2014 at 01:11:01PM -0500, Gabriel L. Somlo wrote: > Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS, > and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags > is present. On the other hand, Windows XP bluescreens whenever > IRQNoFlags is present. This patch conditionally includes IRQNoFlags > only when detecting the presence of an AppleSMC (as a heuristic > predictor for running a Mac OS X guest). Querying _OS and/or _OSI > directly was considered and rejected because such queries MAY NOT > be stateless from the OSPM standpoint, leading to potentially > unpredictable behavior. > > Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Fine with me. Acked-by: Michael S. Tsirkin <mst@redhat.com> I'll pick this up if no one complains. > --- > > On Tue, Jan 21, 2014 at 01:38:26PM +0200, Michael S. Tsirkin wrote: > > So assuming people don't want to tie this to SMC > > (which I still like best) second best > > I like the idea of looking at the prefix of _OS - > > like code above does - then checking _OSI to make sure. > > This way this won't affect microsoft or linux guests. > > We probably call this in init though. > > Could you find out what are _OS values for OSX? > > > > > It's just that all DSDTs I have access to (apple and dell) already do > > > call _OSI with impunity, so I'm not sure just how bad the voodoo is... > > > > Not sure I trust what firmware developers do. From what I saw they > > basically ship it and then software has to find work arounds. > > So, after another closer look at the ACPI 5.0 spec, I indeed agree > that OSPM is allowed to maintain and alter state as a consequence of > being asked and replying to an _OSI("foo") query. > > Which IMHO is bathshit insane: As a firmware dev, you CAN'T ask OSPM > a bunch of innocent yes/no questions and be confident it won't go off > doing crazy things just because you asked the wrong question in the > wrong order... :( > > I had a look through the Linux source, and found that: > > 1. The default answer to _OSI("Linux") is "false", as of 2.6.22 > > 2. The value of _OS is "Microsoft Windows NT". Yes, on Linux... > > So, basically, the whole _OS* thing is treated as a joke. Well, not so > much a joke as a plea to the firmware to "Please Stop Trying To Help Me!" :) > > No idea what OS X does, but at this point I think I thoroughly talked > myself out of wanting to use it, and tying HPET._CRS IRQNoFlags to the > return value of SMC._STA sounds like the less insane thing to do :) > > Thanks, > Gabriel > > hw/i386/acpi-dsdt-hpet.dsl | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl > index dfde174..bdc1370 100644 > --- a/hw/i386/acpi-dsdt-hpet.dsl > +++ b/hw/i386/acpi-dsdt-hpet.dsl > @@ -38,14 +38,21 @@ Scope(\_SB) { > } > Return (0x0F) > } > - Name(_CRS, ResourceTemplate() { > -#if 0 /* This makes WinXP BSOD for not yet figured reasons. */ > - IRQNoFlags() {2, 8} > -#endif > + Name(RESP, ResourceTemplate() { > Memory32Fixed(ReadOnly, > 0xFED00000, // Address Base > 0x00000400, // Address Length > ) > }) > + Name(RESI, ResourceTemplate() { > + IRQNoFlags() {0, 8} // Mac OS X only > + }) > + Method(_CRS, 0) { > + If (LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B)) { > + Return (ConcatenateResTemplate(RESP, RESI)) > + } Else { > + Return (RESP) > + } > + } > } > } > -- > 1.8.1.4
On Tue, Jan 21, 2014 at 08:38:51PM +0200, Michael S. Tsirkin wrote: > On Tue, Jan 21, 2014 at 01:11:01PM -0500, Gabriel L. Somlo wrote: > > Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS, > > and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags > > is present. On the other hand, Windows XP bluescreens whenever > > IRQNoFlags is present. This patch conditionally includes IRQNoFlags > > only when detecting the presence of an AppleSMC (as a heuristic > > predictor for running a Mac OS X guest). Querying _OS and/or _OSI > > directly was considered and rejected because such queries MAY NOT > > be stateless from the OSPM standpoint, leading to potentially > > unpredictable behavior. > > > > Signed-off-by: Gabriel Somlo <somlo@cmu.edu> > > Fine with me. > Acked-by: Michael S. Tsirkin <mst@redhat.com> > > I'll pick this up if no one complains. In the mean time I updated the bootloader I was using (chameleon) to the latest svn (2345), and was able to bring up Lion in addition to SnowLeopard. On Lion, without this patch (i.e. without IRQNoFlags on the HPET), all four combinations (piix vs q35) X (up vs. smp) work fine. I'd like to hold off on having this applied for now, until I get a chance to figure out whether it matters moving forward (MountainLion, Mavericks, etc). I'm not sure it's worth polluting the HPET DSDT node with the "(LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B))" hack, only to support (piix + smp) on an old version of OS X. I'll follow up if anything new and interesting happens, but please ignore it it for now... Thanks, --Gabriel
> Am 24.01.2014 um 17:46 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>: > >> On Tue, Jan 21, 2014 at 08:38:51PM +0200, Michael S. Tsirkin wrote: >>> On Tue, Jan 21, 2014 at 01:11:01PM -0500, Gabriel L. Somlo wrote: >>> Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS, >>> and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags >>> is present. On the other hand, Windows XP bluescreens whenever >>> IRQNoFlags is present. This patch conditionally includes IRQNoFlags >>> only when detecting the presence of an AppleSMC (as a heuristic >>> predictor for running a Mac OS X guest). Querying _OS and/or _OSI >>> directly was considered and rejected because such queries MAY NOT >>> be stateless from the OSPM standpoint, leading to potentially >>> unpredictable behavior. >>> >>> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> >> >> Fine with me. >> Acked-by: Michael S. Tsirkin <mst@redhat.com> >> >> I'll pick this up if no one complains. > > In the mean time I updated the bootloader I was using (chameleon) to > the latest svn (2345), and was able to bring up Lion in addition to > SnowLeopard. Did Chameleon patch this up itself in the dsdt maybe? Alex > > On Lion, without this patch (i.e. without IRQNoFlags on the HPET), all > four combinations (piix vs q35) X (up vs. smp) work fine. > > I'd like to hold off on having this applied for now, until I get a > chance to figure out whether it matters moving forward (MountainLion, > Mavericks, etc). I'm not sure it's worth polluting the HPET DSDT node > with the "(LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B))" hack, only to > support (piix + smp) on an old version of OS X. > > I'll follow up if anything new and interesting happens, but please > ignore it it for now... > > Thanks, > --Gabriel
On Fri, Jan 24, 2014 at 10:18:04PM +0100, Alexander Graf wrote: > > In the mean time I updated the bootloader I was using (chameleon) to > > the latest svn (2345), and was able to bring up Lion in addition to > > SnowLeopard. > > Did Chameleon patch this up itself in the dsdt maybe? From a cursory pass through the Chameleon source, I don't think so. They do allow one to specify an alternate DSDT to load, but I'm not using that feature currently. Once I finish trying all versions of OSX against all combinations of piix vs. q35 and up vs. smp, I'll give the Chameleon source a closer look: ultimately, it would be nice if we had something Chameleon-like that could be built on Linux (get OSX+Xcode out of the equation). Maybe getting the interesting bits submitted as patches against SeaBIOS and QEMU, wherever appropriate. Currently, I have SnowLeopard, Lion, and MountainLion working fine. MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at boot). Mavericks 10.9.0 installer boots and works fine, but the resulting hdd image, while bootable, hangs during boot. I want to try the latest Mavericks installer before moving on to isolate the bits of Chameleon magic that are relevant to us (QEMU+KVM). That's about where things are right now :) Thanks, --Gabriel
> Am 25.01.2014 um 01:09 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>: > > On Fri, Jan 24, 2014 at 10:18:04PM +0100, Alexander Graf wrote: >>> In the mean time I updated the bootloader I was using (chameleon) to >>> the latest svn (2345), and was able to bring up Lion in addition to >>> SnowLeopard. >> >> Did Chameleon patch this up itself in the dsdt maybe? > > From a cursory pass through the Chameleon source, I don't think so. Ok :). I only barely remember what Chameleon did on top of the normal Apple BIOS bootloader. > > They do allow one to specify an alternate DSDT to load, but I'm not > using that feature currently. > > Once I finish trying all versions of OSX against all combinations > of piix vs. q35 and up vs. smp, I'll give the Chameleon source a > closer look: ultimately, it would be nice if we had something > Chameleon-like that could be built on Linux (get OSX+Xcode out of > the equation). Maybe getting the interesting bits submitted as patches > against SeaBIOS and QEMU, wherever appropriate. I disagree. Eventually we want to run TianoCore and just use Apple's EFI bootloader. With that we should be a lot more future proof. > > Currently, I have SnowLeopard, Lion, and MountainLion working fine. > MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at > boot). > > Mavericks 10.9.0 installer boots and works fine, but the resulting hdd > image, while bootable, hangs during boot. I want to try the latest > Mavericks installer before moving on to isolate the bits of Chameleon > magic that are relevant to us (QEMU+KVM). > > That's about where things are right now :) Nice progress :). Thanks a lot for taking care of all this! Alex > > Thanks, > --Gabriel
On Sat, Jan 25, 2014 at 10:08:37AM +0100, Alexander Graf wrote: > > Once I finish trying all versions of OSX against all combinations > > of piix vs. q35 and up vs. smp, I'll give the Chameleon source a > > closer look: ultimately, it would be nice if we had something > > Chameleon-like that could be built on Linux (get OSX+Xcode out of > > the equation). Maybe getting the interesting bits submitted as patches > > against SeaBIOS and QEMU, wherever appropriate. > > I disagree. Eventually we want to run TianoCore and just use Apple's EFI bootloader. With that we should be a lot more future proof. Long term, I'm with you. For now though, I'd like to know how Chameleon does what it does on the inside. I'd also like to be able to build a minimal subset needed to get QEMU to load XNU on Linux, and eliminate the requirement to "do stuff on OS X with Xcode". BTW, when you say "use Apple's EFI bootloader" what do you mean ? Is that some piece of software we'd have to download and build, like Chameleon? Or would TianoCore in theory be capable of doing what the Apple EFI Bios does and load XNU from the hard drive image directly, and there's some default bootloader placed there by the OS X installer, kinda like grub in the Linux world ? If the latter, I think understanding how Chameleon does that part would come in handy (for me at least, since I don't have a good mental map on how things work before the XNU kernel starts running). Thanks, --Gabriel
On Tue, 28 Jan 2014, Gabriel L. Somlo wrote: > BTW, when you say "use Apple's EFI bootloader" what do you mean ? > > Is that some piece of software we'd have to download and build, > like Chameleon? Or would TianoCore in theory be capable of doing > what the Apple EFI Bios does and load XNU from the hard drive > image directly, and there's some default bootloader placed there > by the OS X installer, kinda like grub in the Linux world ? > > If the latter, I think understanding how Chameleon does that part > would come in handy (for me at least, since I don't have a good > mental map on how things work before the XNU kernel starts running). Here are some pages that might help enlightening the boot process: https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/booting/booting.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html#Apple http://developer.apple.com./mac/library/DOCUMENTATION/Darwin/References/ManPages/man8/bless.8.html Regards, BALATON Zoltan
On Tue, Jan 28, 2014 at 11:51:25PM +0100, BALATON Zoltan wrote: > Here are some pages that might help enlightening the boot process: > > https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/booting/booting.html > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html#Apple > http://developer.apple.com./mac/library/DOCUMENTATION/Darwin/References/ManPages/man8/bless.8.html So, basically, every well-behaved OS will drop a (set of) files somewhere under /EFI/<vendor>/, except for OS X which expects the BIOS/firmware to bypass all that mundane stuff and go straight for /System/Library/CoreServices/boot.efi on a the selected boot partition, and only fall back to /EFI/* if that doesn't pan out :) But now I think it's starting to make sense. Chameleon's stage2 loader, named "boot" (which we're starting via "-kernel boot", and which is the only piece of Chameleon we need) is apparently equivalent to Apple's "boot.efi", which it bypasses, and which I think is what Alex was talking about (i.e., eventually getting TianoCore to pick up and run "boot.efi" as left behind by the vanilla OS X installer). Thanks again for the helpful links !!! --Gabriel
On Tue, 28 Jan 2014, Gabriel L. Somlo wrote: > But now I think it's starting to make sense. Chameleon's stage2 > loader, named "boot" (which we're starting via "-kernel boot", and > which is the only piece of Chameleon we need) is apparently equivalent > to Apple's "boot.efi", which it bypasses, and which I think is what AFAIK Chameleon's boot is based on Apple's older, pre-EFI boot loader (http://opensource.apple.com/source/boot/boot-132/) that performs similar functions but does not require EFI and works on BIOS based machines. It is updated to work with recent EFI-only releases, also provides some EFI stuff that's needed by OS X (fake_efi) and has some means of patching up non-Apple hardware to work with OS X. To make sure it's not trying to patch anything try to remove all modules (may need to recompile to get rid of built-in modules) and make sure all *Enabler options are disabled. > Alex was talking about (i.e., eventually getting TianoCore to pick > up and run "boot.efi" as left behind by the vanilla OS X installer). I've also found this: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OvmfPkg which might be what we need for using Apple's boot.efi but I don't know how ready is it and if it works with OS X. Regards, BALATON Zoltan
On Tue, 28 Jan 2014, Gabriel L. Somlo wrote:
> Thanks again for the helpful links !!!
Here are some more that can be helpful:
http://www.rodsbooks.com/refind/drivers.html
about some EFI drivers that can make an EFI implementation able to read an
HFS+ volume (rEFInd is a boot manager for EFI that can select and load os
boot loaders)
http://clover-wiki.zetam.org/What-is-what
about Clover boot process and components (Clover is similar to Chameleon
but with a different approach providing an EFI environment first and
having other functions in EFI programs thus if your firmware is EFI then
the first part is not needed.)
From these parts it should be possible to create a minimal boot loader for
Qemu that can load OS X but it may not be completely trivial.
Regards,
BALATON Zoltan
On 01/29/2014 04:07 AM, Gabriel L. Somlo wrote: > On Tue, Jan 28, 2014 at 11:51:25PM +0100, BALATON Zoltan wrote: >> Here are some pages that might help enlightening the boot process: >> >> https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/booting/booting.html >> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html#Apple >> http://developer.apple.com./mac/library/DOCUMENTATION/Darwin/References/ManPages/man8/bless.8.html > So, basically, every well-behaved OS will drop a (set of) files > somewhere under /EFI/<vendor>/, except for OS X which expects the > BIOS/firmware to bypass all that mundane stuff and go straight for > /System/Library/CoreServices/boot.efi on a the selected boot > partition, and only fall back to /EFI/* if that doesn't pan out :) > > But now I think it's starting to make sense. Chameleon's stage2 > loader, named "boot" (which we're starting via "-kernel boot", and > which is the only piece of Chameleon we need) is apparently equivalent > to Apple's "boot.efi", which it bypasses, and which I think is what > Alex was talking about (i.e., eventually getting TianoCore to pick > up and run "boot.efi" as left behind by the vanilla OS X installer). It's even better than that. The "boot.efi" is part of the installation meda as well, so we wouldn't have to rely on _any_ external code at all :). Alex
On Wed, Jan 29, 2014 at 12:29:17PM +0100, BALATON Zoltan wrote: > I've also found this: > http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OvmfPkg > which might be what we need for using Apple's boot.efi but I don't > know how ready is it and if it works with OS X. I managed to boot OVMF following their wiki; It seems to work with kvm enabled, but not with -M q35. My current command line is: bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo \ -usb -device usb-kbd -device usb-mouse \ -device isa-applesmc,osk="..." \ -hda mlion_hdd.img after having replaced bios.bin and vgabios-cirrus.bin with the OVMF files. It obviously fails to boot OS X (now THAT would have been a surprise!) but at least it detects the hard disk: fs0 :HardDisk - Alias hd12a1 blk0 PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,BA0DB2B5-2270-4749-B794-BC005BEC1863,0x28,0x64000) I poked around the "boot maintenance manager" a bit, and "boot from file" looked promising -- I was hoping to navigate straight to /System/Library/CoreServices/boot.efi and just hit "Enter", but was only able to see an empty folder hierarchy: EFI/ APPLE/ EXTENSIONS/ .Trashes/ 501/ So I guess I have a bit more RTFM ahead of me. Maybe I can find a way to copy boot.efi over to the actual EFI partition, which I assume is the only one I can explore with OVMF from the entire disk image... Thanks again, --Gabriel
On 01/29/2014 03:53 PM, Gabriel L. Somlo wrote: > On Wed, Jan 29, 2014 at 12:29:17PM +0100, BALATON Zoltan wrote: >> I've also found this: >> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OvmfPkg >> which might be what we need for using Apple's boot.efi but I don't >> know how ready is it and if it works with OS X. > I managed to boot OVMF following their wiki; It seems to work with kvm > enabled, but not with -M q35. My current command line is: > > bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo \ > -usb -device usb-kbd -device usb-mouse \ > -device isa-applesmc,osk="..." \ > -hda mlion_hdd.img > > after having replaced bios.bin and vgabios-cirrus.bin with the OVMF > files. > > It obviously fails to boot OS X (now THAT would have been a surprise!) > but at least it detects the hard disk: > > fs0 :HardDisk - Alias hd12a1 blk0 > PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,BA0DB2B5-2270-4749-B794-BC005BEC1863,0x28,0x64000) > > I poked around the "boot maintenance manager" a bit, and "boot from > file" looked promising -- I was hoping to navigate straight to > /System/Library/CoreServices/boot.efi and just hit "Enter", but was > only able to see an empty folder hierarchy: > > EFI/ > APPLE/ > EXTENSIONS/ > .Trashes/ > 501/ > > So I guess I have a bit more RTFM ahead of me. Maybe I can find a way > to copy boot.efi over to the actual EFI partition, which I assume is > the only one I can explore with OVMF from the entire disk image... You will need an EFI HFS+ driver (look at the refind pointer) because boot.efi will use EFI callbacks to read the kernel and kext cache. Alex
On Wed, 29 Jan 2014, Alexander Graf wrote: > On 01/29/2014 03:53 PM, Gabriel L. Somlo wrote: >> I managed to boot OVMF following their wiki; It seems to work with kvm >> enabled, but not with -M q35. My current command line is: Did you use the snapshots on the wiki or compiled the latest version from source? It seems the snapshots are quite old and there have been recent commits since. (I don't know if those fixed or broke things though.) >> So I guess I have a bit more RTFM ahead of me. Maybe I can find a way >> to copy boot.efi over to the actual EFI partition, which I assume is >> the only one I can explore with OVMF from the entire disk image... Linux can read hfs+ file systems and the EFI partition can also be mounted and written to on OS X from the command line so it's easy to copy boot.efi over to the EFI partition either on Linux or OS X. > You will need an EFI HFS+ driver (look at the refind pointer) because > boot.efi will use EFI callbacks to read the kernel and kext cache. Right. Hopefully it does not rely on Apple's specific HFS+ support in their firmware or that's compatible with what (at least one of) the EFI drivers provide. Regards, BALATON Zoltan
On Wed, 29 Jan 2014, Gabriel L. Somlo wrote: > I managed to boot OVMF following their wiki; It seems to work with kvm > enabled, but not with -M q35. My current command line is: I've tried with the version compiled from the edk2 HEAD and that also fails with -M q35. I've managed to get some debug output via the options described in OVMF's readme file and the error is around where initialising the graphics card. With q35 it stops with: ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(163): (Port & 3) == 0 This function is IoRead32 and it says the port must be 32-bit aligned. I've tried to find what port it tries to access but qemu -d ioport option generates no output for me. Any hints on how to use this debug option of qemu? Regards, BALATON Zoltan
> Am 01.02.2014 um 01:38 schrieb BALATON Zoltan <balaton@eik.bme.hu>: > >> On Wed, 29 Jan 2014, Gabriel L. Somlo wrote: >> I managed to boot OVMF following their wiki; It seems to work with kvm >> enabled, but not with -M q35. My current command line is: > > I've tried with the version compiled from the edk2 HEAD and that also fails with -M q35. I've managed to get some debug output via the options described in OVMF's readme file and the error is around where initialising the graphics card. With q35 it stops with: > > ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(163): (Port & 3) == 0 > > This function is IoRead32 and it says the port must be 32-bit aligned. I've tried to find what port it tries to access but qemu -d ioport option generates no output for me. Any hints on how to use this debug option of qemu? The assert happens inside the guest, so I'm afraid you'll have to add debugging output to edk2. Just print out the port number if port & 3 in the code path above. Alex > > Regards, > BALATON Zoltan
On Sat, 1 Feb 2014, Alexander Graf wrote: > The assert happens inside the guest, so I'm afraid you'll have to add > debugging output to edk2. Just print out the port number if port & 3 in > the code path above. I've come this same conclusion too after I managed to enable qemu iport debugging but it wasn't helpful. I've added logging to edk2 but I still don't know what's going on. This is what I got: Without -M q35 where it works: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 8086:1237 id "" Bus 0, device 1, function 0: ISA bridge: PCI device 8086:7000 id "" Bus 0, device 1, function 1: IDE controller: PCI device 8086:7010 BAR4: I/O at 0xffffffffffffffff [0x000e]. id "" Bus 0, device 1, function 3: Bridge: PCI device 8086:7113 IRQ 0. id "" Bus 0, device 2, function 0: VGA controller: PCI device 1013:00b8 BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe]. BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. id "" Bus 0, device 3, function 0: Ethernet controller: PCI device 8086:100e IRQ 0. BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe]. BAR1: I/O at 0xffffffffffffffff [0x003e]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. id "" PciBus: Resource Map for Root Bridge PciRoot(0x0) Type = Io16; Base = 0xC000; Length = 0x1000; Alignment = 0xFFF Base = 0xC000; Length = 0x40; Alignment = 0x3F; Owner = PCI [00|03|00:14] Base = 0xC040; Length = 0x10; Alignment = 0xF; Owner = PCI [00|01|01:20] Type = Mem32; Base = 0x80000000; Length = 0x2100000; Alignment = 0x1FFFFFF Base = 0x80000000; Length = 0x2000000; Alignment = 0x1FFFFFF; Owner = PCI [00|02|00:10] Base = 0x82000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [00|03|00:10] Base = 0x82020000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [00|02|00:14] [...] IoWrite32 CF8 80000820 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000824 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000828 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 8000082C IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000830 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000834 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000838 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 8000083C IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000804 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000804 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000B40 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 B008 IoRead32 CF8 IoWrite32 CF8 80000B40 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 B008 and so on repeating. With -M q35 where it stops at the assertion: (qemu) info pci Bus 0, device 0, function 0: Host bridge: PCI device 8086:29c0 id "" Bus 0, device 1, function 0: VGA controller: PCI device 1013:00b8 BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe]. BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. id "" Bus 0, device 2, function 0: Ethernet controller: PCI device 8086:100e IRQ 0. BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe]. BAR1: I/O at 0xffffffffffffffff [0x003e]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. id "" Bus 0, device 31, function 0: ISA bridge: PCI device 8086:2918 id "" Bus 0, device 31, function 2: SATA controller: PCI device 8086:2922 IRQ 0. BAR4: I/O at 0xffffffffffffffff [0x001e]. BAR5: 32 bit memory at 0xffffffffffffffff [0x00000ffe]. id "" Bus 0, device 31, function 3: SMBus: PCI device 8086:2930 IRQ 0. BAR4: I/O at 0xffffffffffffffff [0x003e]. id "" PciBus: Resource Map for Root Bridge PciRoot(0x0) Type = Io16; Base = 0xC000; Length = 0x1000; Alignment = 0xFFF Base = 0xC000; Length = 0x40; Alignment = 0x3F; Owner = PCI [00|1F|03:20] Base = 0xC040; Length = 0x40; Alignment = 0x3F; Owner = PCI [00|02|00:14] Base = 0xC080; Length = 0x20; Alignment = 0x1F; Owner = PCI [00|1F|02:20] Type = Mem32; Base = 0x80000000; Length = 0x2100000; Alignment = 0x1FFFFFF Base = 0x80000000; Length = 0x2000000; Alignment = 0x1FFFFFF; Owner = PCI [00|01|00:10] Base = 0x82000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [00|02|00:10] Base = 0x82020000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [00|1F|02:24] Base = 0x82021000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [00|01|00:14] [...] IoWrite32 CF8 80001020 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001024 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001004 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001004 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001004 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001004 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001004 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001004 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80001004 IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 8000100C IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 8000100C IoWrite32 CF8 00000000 IoRead32 CF8 IoWrite32 CF8 80000B40 IoRead32 CFC IoWrite32 CF8 00000000 IoRead32 6 ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(164): (Port & 3) == 0 Does anybody have any hints on why this fails or how to debug it further? Regards, BALATON Zoltan
> Am 01.02.2014 um 15:35 schrieb BALATON Zoltan <balaton@eik.bme.hu>: > >> On Sat, 1 Feb 2014, Alexander Graf wrote: >> The assert happens inside the guest, so I'm afraid you'll have to add debugging output to edk2. Just print out the port number if port & 3 in the code path above. > > I've come this same conclusion too after I managed to enable qemu iport debugging but it wasn't helpful. I've added logging to edk2 but I still don't know what's going on. This is what I got: > > Without -M q35 where it works: > > (qemu) info pci > Bus 0, device 0, function 0: > Host bridge: PCI device 8086:1237 > id "" > Bus 0, device 1, function 0: > ISA bridge: PCI device 8086:7000 > id "" > Bus 0, device 1, function 1: > IDE controller: PCI device 8086:7010 > BAR4: I/O at 0xffffffffffffffff [0x000e]. > id "" > Bus 0, device 1, function 3: > Bridge: PCI device 8086:7113 > IRQ 0. > id "" > Bus 0, device 2, function 0: > VGA controller: PCI device 1013:00b8 > BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe]. > BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe]. > BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. > id "" > Bus 0, device 3, function 0: > Ethernet controller: PCI device 8086:100e > IRQ 0. > BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe]. > BAR1: I/O at 0xffffffffffffffff [0x003e]. > BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. > id "" > > PciBus: Resource Map for Root Bridge PciRoot(0x0) > Type = Io16; Base = 0xC000; Length = 0x1000; Alignment = 0xFFF > Base = 0xC000; Length = 0x40; Alignment = 0x3F; Owner = PCI [00|03|00:14] > Base = 0xC040; Length = 0x10; Alignment = 0xF; Owner = PCI [00|01|01:20] > Type = Mem32; Base = 0x80000000; Length = 0x2100000; Alignment = 0x1FFFFFF > Base = 0x80000000; Length = 0x2000000; Alignment = 0x1FFFFFF; Owner = PCI [00|02|00:10] > Base = 0x82000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [00|03|00:10] > Base = 0x82020000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [00|02|00:14] > [...] > IoWrite32 CF8 80000820 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000824 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000828 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 8000082C > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000830 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000834 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000838 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 8000083C > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000804 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000804 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000B40 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 B008 > IoRead32 CF8 > IoWrite32 CF8 80000B40 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 B008 > > and so on repeating. With -M q35 where it stops at the assertion: > > (qemu) info pci > Bus 0, device 0, function 0: > Host bridge: PCI device 8086:29c0 > id "" > Bus 0, device 1, function 0: > VGA controller: PCI device 1013:00b8 > BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe]. > BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe]. > BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. > id "" > Bus 0, device 2, function 0: > Ethernet controller: PCI device 8086:100e > IRQ 0. > BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe]. > BAR1: I/O at 0xffffffffffffffff [0x003e]. > BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. > id "" > Bus 0, device 31, function 0: > ISA bridge: PCI device 8086:2918 > id "" > Bus 0, device 31, function 2: > SATA controller: PCI device 8086:2922 > IRQ 0. > BAR4: I/O at 0xffffffffffffffff [0x001e]. > BAR5: 32 bit memory at 0xffffffffffffffff [0x00000ffe]. > id "" > Bus 0, device 31, function 3: > SMBus: PCI device 8086:2930 > IRQ 0. > BAR4: I/O at 0xffffffffffffffff [0x003e]. > id "" > > PciBus: Resource Map for Root Bridge PciRoot(0x0) > Type = Io16; Base = 0xC000; Length = 0x1000; Alignment = 0xFFF > Base = 0xC000; Length = 0x40; Alignment = 0x3F; Owner = PCI [00|1F|03:20] > Base = 0xC040; Length = 0x40; Alignment = 0x3F; Owner = PCI [00|02|00:14] > Base = 0xC080; Length = 0x20; Alignment = 0x1F; Owner = PCI [00|1F|02:20] > Type = Mem32; Base = 0x80000000; Length = 0x2100000; Alignment = 0x1FFFFFF > Base = 0x80000000; Length = 0x2000000; Alignment = 0x1FFFFFF; Owner = PCI [00|01|00:10] > Base = 0x82000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [00|02|00:10] > Base = 0x82020000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [00|1F|02:24] > Base = 0x82021000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [00|01|00:14] > [...] > IoWrite32 CF8 80001020 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001024 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001004 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001004 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001004 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001004 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001004 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001004 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80001004 > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 8000100C > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 8000100C > IoWrite32 CF8 00000000 > IoRead32 CF8 > IoWrite32 CF8 80000B40 > IoRead32 CFC > IoWrite32 CF8 00000000 > IoRead32 6 > ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(164): (Port & 3) == 0 > > Does anybody have any hints on why this fails or how to debug it further? Easiest is probably to attach gdb and get a backtrace to see who accesses that port. Alex > > Regards, > BALATON Zoltan
On Sat, 1 Feb 2014, Alexander Graf wrote:
> Easiest is probably to attach gdb and get a backtrace to see who accesses that port.
Only if I knew how to do that... I can start qemu with -s and attach gdb
to it but how to get symbols for the OVMF.fd file and how to set the
breakpoint? I've tried gdb OVMF.fd but it cannot load it directly. I've
also found *.debug files in the edk2/Build directory but they are only for
parts of the whole fw image and none of them seems to be for the part
which defines the IoRead32 function. Does anyone know how to debug OVMF
firmware running in qemu?
Regards,
BALATON Zoltan
On Wed, 29 Jan 2014, Alexander Graf wrote: > You will need an EFI HFS+ driver (look at the refind pointer) because > boot.efi will use EFI callbacks to read the kernel and kext cache. Probably we will need more than that. I've copied boot.efi to the EFI partition and tried to start it from OMVF (without -M q35) but it only printed: Can not initialize console Boot failed, sleeping for 10 seconds before exiting... Regards, BALATON Zoltan
Il 01/02/2014 01:38, BALATON Zoltan ha scritto: > >> I managed to boot OVMF following their wiki; It seems to work with kvm >> enabled, but not with -M q35. My current command line is: > > I've tried with the version compiled from the edk2 HEAD and that also > fails with -M q35. I've managed to get some debug output via the options > described in OVMF's readme file and the error is around where > initialising the graphics card. With q35 it stops with: > > ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(163): (Port > & 3) == 0 > > This function is IoRead32 and it says the port must be 32-bit aligned. > I've tried to find what port it tries to access but qemu -d ioport > option generates no output for me. Any hints on how to use this debug > option of qemu? The firmware has to be ported to each new chipset. OVMF was never ported to anything but PIIX. Paolo
On Sat, 1 Feb 2014, Paolo Bonzini wrote: > The firmware has to be ported to each new chipset. > > OVMF was never ported to anything but PIIX. Looks like this is the case. Now I can see that OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c has hardcoded pci paths in it corresponding to the pc machine type with PIIX and it tries to access these devices unconditionally even if they do not exist (as on q35 machine). So this obviously won't work. I think I give up at this point because I don't know enough about Q35 and I don't see how could it be hacked into Ovmf. Additionally it seems that this alone would not be enough to use Apple's boot.efi verbatim but something more complex, very much resembling Clover would be needed to boot OS X with Ovmf EFI which is not much cleaner solution than using Chameleon with Seabios that already works now. Regards, BALATON Zoltan
On Sa, 2014-02-01 at 15:35 +0100, BALATON Zoltan wrote: > On Sat, 1 Feb 2014, Alexander Graf wrote: > > The assert happens inside the guest, so I'm afraid you'll have to add > > debugging output to edk2. Just print out the port number if port & 3 in > > the code path above. > > I've come this same conclusion too after I managed to enable qemu iport > debugging but it wasn't helpful. IIRC it is ovmf trying to access the piix4 pm timer, even when running on q35. cheers, Gerd
diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl index dfde174..bdc1370 100644 --- a/hw/i386/acpi-dsdt-hpet.dsl +++ b/hw/i386/acpi-dsdt-hpet.dsl @@ -38,14 +38,21 @@ Scope(\_SB) { } Return (0x0F) } - Name(_CRS, ResourceTemplate() { -#if 0 /* This makes WinXP BSOD for not yet figured reasons. */ - IRQNoFlags() {2, 8} -#endif + Name(RESP, ResourceTemplate() { Memory32Fixed(ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) + Name(RESI, ResourceTemplate() { + IRQNoFlags() {0, 8} // Mac OS X only + }) + Method(_CRS, 0) { + If (LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B)) { + Return (ConcatenateResTemplate(RESP, RESI)) + } Else { + Return (RESP) + } + } } }
Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS, and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags is present. On the other hand, Windows XP bluescreens whenever IRQNoFlags is present. This patch conditionally includes IRQNoFlags only when detecting the presence of an AppleSMC (as a heuristic predictor for running a Mac OS X guest). Querying _OS and/or _OSI directly was considered and rejected because such queries MAY NOT be stateless from the OSPM standpoint, leading to potentially unpredictable behavior. Signed-off-by: Gabriel Somlo <somlo@cmu.edu> --- On Tue, Jan 21, 2014 at 01:38:26PM +0200, Michael S. Tsirkin wrote: > So assuming people don't want to tie this to SMC > (which I still like best) second best > I like the idea of looking at the prefix of _OS - > like code above does - then checking _OSI to make sure. > This way this won't affect microsoft or linux guests. > We probably call this in init though. > Could you find out what are _OS values for OSX? > > > It's just that all DSDTs I have access to (apple and dell) already do > > call _OSI with impunity, so I'm not sure just how bad the voodoo is... > > Not sure I trust what firmware developers do. From what I saw they > basically ship it and then software has to find work arounds. So, after another closer look at the ACPI 5.0 spec, I indeed agree that OSPM is allowed to maintain and alter state as a consequence of being asked and replying to an _OSI("foo") query. Which IMHO is bathshit insane: As a firmware dev, you CAN'T ask OSPM a bunch of innocent yes/no questions and be confident it won't go off doing crazy things just because you asked the wrong question in the wrong order... :( I had a look through the Linux source, and found that: 1. The default answer to _OSI("Linux") is "false", as of 2.6.22 2. The value of _OS is "Microsoft Windows NT". Yes, on Linux... So, basically, the whole _OS* thing is treated as a joke. Well, not so much a joke as a plea to the firmware to "Please Stop Trying To Help Me!" :) No idea what OS X does, but at this point I think I thoroughly talked myself out of wanting to use it, and tying HPET._CRS IRQNoFlags to the return value of SMC._STA sounds like the less insane thing to do :) Thanks, Gabriel hw/i386/acpi-dsdt-hpet.dsl | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)