Re: [SeaBIOS] [PATCH v3] DSDT: Fix HPET _CRS Method

[Gabriel L. Somlo]

Hi Rene,

On Thu, Nov 08, 2012 at 06:41:42PM +0100, Rene Rebe wrote:
> Hi Gabriel,
> What did the Darwin kernel do before with -smp > 1?
>
> I ask, because for me it booted already, just was not stable.
> The question is: Is OS X stable for you with -smp > 1 under load?

I'm guessing your patched bios must have had the "IRQNoFlags" statement
in the HPET's DSDT entry, which is why OS X was willing to boot for you.

I was going for the least amount of change to current seabios git
master required to get it working, and got carried away (and forgot to
test on OS X + SMP) before submitting v2 of the patch :)

<offtopic>

As for stability, I think that has to do with the kernel (KVM) MWAIT
patch. I'm using this now:

http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-kmod-3.6-mac.patch

which emulates MONITOR and MWAIT as PAUSE, instead of preventing them
from causing VM exits and leaving them to be run from within the
guest's context.

So far, "-smp 8,cores=4" is rock solid (ran a few load tests I found
by googling).

</offtopic>

Cheers,
--Gabriel

[PATCH v3] DSDT: Fix HPET _CRS Method

[Rene Rebe]

Hi,

On 08.11.2012, at 19:17, Gabriel L. Somlo wrote:
> Hi Rene,
>
> On Thu, Nov 08, 2012 at 06:41:42PM +0100, Rene Rebe wrote:
> > Hi Gabriel,
> > What did the Darwin kernel do before with -smp > 1?
> >
> > I ask, because for me it booted already, just was not stable.
> > The question is: Is OS X stable for you with -smp > 1 under load?
>
> I'm guessing your patched bios must have had the "IRQNoFlags" statement
> in the HPET's DSDT entry, which is why OS X was willing to boot for you.
>
> I was going for the least amount of change to current seabios git
> master required to get it working, and got carried away (and forgot to
> test on OS X + SMP) before submitting v2 of the patch :)
>
> <offtopic>
>
> As for stability, I think that has to do with the kernel (KVM) MWAIT
> patch. I'm using this now:
>
> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-kmod-3.6-mac.patch
>
> which emulates MONITOR and MWAIT as PAUSE, instead of preventing them
> from causing VM exits and leaving them to be run from within the
> guest's context.
>
> So far, "-smp 8,cores=4" is rock solid (ran a few load tests I found
> by googling).
>
> </offtopic>

But with that patch the CPU does not wake on write access? I guess just with the next "spurious" interrupt?

René

[PATCH v3] DSDT: Fix HPET _CRS Method

[Gabriel L. Somlo]

On Thu, Nov 08, 2012 at 07:23:57PM +0100, Rene Rebe wrote:
> But with that patch the CPU does not wake on write access? I guess just with the next "spurious" interrupt?

No, PAUSE is emulated as trying to yield to another VCPU before
resuming the current one, just a "slow NOP".

I am planning to try emulating MWAIT as (something similar to) HLT,
which would pause the VCPU until the next interrupt. That should quiet
down the num_smp x 100% CPU utilization reported by qemu on the host
side, while the guest is just sitting idle... :)

Now that I have MONITOR and MWAIT trap into the host, I'm studying KVM
source for some more "intelligent" way of emulating them. Ideally, I'd
be able to trap on writes to the memory area set up with MONITOR that
MWAIT is sleeping on, but I worry that even if I could do that,
trapping on writes would have a serious performance downside.

As you may have guessed, I took up your suggestion of looking at
MONITOR/MWAIT for my project, so any ideas you may have for me are
much appreciated ! :)

Thanks much,
--Gabriel

P.S. Maybe we should trim the CC list back down to you, Alex, and myself,
I worry this is going beyond what e.g. the seabios list might want to hear
about...