Re: [Qemu-devel] [PATCH v3] Add DSDT node for AppleSMC

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Dec 25, 2013 at 10:33:16PM +0100, Alexander Graf wrote:
> 
> On 25.12.2013, at 20:20, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
> > On Wed, Dec 25, 2013 at 08:11:56PM +0100, Alexander Graf wrote:
> >> 
> >> 
> >>> Am 23.12.2013 um 04:19 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>:
> >>> 
> >>> On Sun, Dec 22, 2013 at 11:21:00PM +0100, Laszlo Ersek wrote:
> >>>>>   2. Use "IRQNoFlags() { 5 }" with the SMC (or any other
> >>>>>      number that isn't already allocated.
> >>>> 
> >>>> I don't think there's anything left free:
> >>>> ...
> >>>> 
> >>>> I guess the "by the book" solution would be to really stop the FDC from
> >>>> being emulated when the AppleSMC is present, but I mention that idea
> >>>> only because I like to waste bandwidth.
> >>>> 
> >>>> Option 1 ("Do nothing") sounds appropriate to me.
> >>> 
> >>> So making the FDC optional (or at least allowing it to be left out)
> >>> sounds like it could be a fun project I could play with later (unless
> >>> anyone else beats me to it), but it would be nice if it didn't end up
> >>> a hard precondition for getting the SMC ACPI patch accepted :)
> >>> 
> >>> Once we can turn off the FDC, we can make it and the SMC mutually
> >>> exclusive and/or throw an error if both are enabled.
> >>> 
> >>> In reality (and Alex, please correct me if I'm wrong), the emulated
> >>> SMC will never generate an INT#6, unlike the real hardware chip. The
> >>> emulated SMC is just there to say "Yeah, boss, sure, let me get right
> >>> on that for you!" to OS X, to calm it down and make it think everything
> >>> is right with its little universe :) The real chip might trigger an
> >>> interrupt if something's getting too hot, or a fan stopped spinning
> >>> when it shouldn't have, but that's never going to happen on a VM guest.
> >> 
> >> Its main purpose is to signal you dropping your notebook, so the system can shut down your hard drive.
> >> 
> >> The main issue I can see with the irq line is that we now potentially have two edge triggered irq sources on a single line, so an OS may get confused.
> >> 
> >> But I agree, let's get that one solved later.
> >> 
> >>> 
> >>> OS X doesn't even assume the presence of an FDC, and any guest OS
> >>> which expects an FDC will never get unexpected conflicting interrupts
> >>> from the emulated SMC, should the latter be enabled, accidentally or
> >>> not. So in practice the risk for any trouble should be about zero...
> >> 
> >> It may assign the irq line to the applesmc driver, killing the fdc's functionality.
> >> 
> >> Speaking of which, does the q35 even have an fdc?
> >> 
> >> 
> >> Alex
> > 
> > I don't think it does but this device seems to be supported with piix as well -
> > or is this by mistake?
> 
> No, the device doesn't care whether the chipset is Q35 or PIIX. Back when I first got OSX working at all I was using PIIX because there was no Q35 emulation available, but the Q35 is a lot closer to what Mac OS X expects (the earliest chipset it runs on is an ICH6).
> 
> Either way, this whole thing is optional anyway, right? I don't think anyone will add the applesmc controller if he doesn't want to run an OSX guest, so we should be safe.
> 
> 
> Alex

Yes, seems pretty safe - that's why I took this patch.
If you like, send an incremental one with a comment so we remember
to look as this if we ever see issues.