On Wed, Dec 25, 2013 at 10:33:16PM +0100, Alexander Graf wrote:
>
> On 25.12.2013, at 20:20, Michael S. Tsirkin <m...@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" <gso...@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.
