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
