On Mon, Sep 20, 2010 at 09:07:16PM -0400, Kevin O'Connor wrote:
> On Mon, Sep 20, 2010 at 08:50:17AM +0200, Gleb Natapov wrote:
> > On Sun, Sep 19, 2010 at 06:03:31PM -0400, Kevin O'Connor wrote:
> > > I was wrong. The "cpu_set x offline" does send an event to the guest
> > > OS. SeaBIOS even forwards the event along - as far as I can tell a
> > > Notify(CPxx, 3) event is generated by SeaBIOS.
> > >
> > > My Windows 7 ultimate beta seems to receive the event okay (it pops up
> > > a dialog box which says you can't unplug cpus).
> > >
> > It may react to Eject() method.
>
> The eject method is called by the OS to notify the host. Right now
> SeaBIOS's eject method doesn't do anything.
>
Yes. What I meant is it may react on presence of Eject() method. In my
experience Windows consider all devices with Eject() method as
hot-pluggable. But actually IIRC Windows 7 gave me this dialog box with
BOCHS BIOS too and there we didn't have Eject() method.
> > > Unfortunately, my test linux guest OS (FC13) doesn't seem to do
> > > anything with the unplug Notify event. I've tried with the original
> > > FC13 and with a fully updated version - no luck.
> > >
> > > So, I'm guessing this has something to do with the guest OS.
> > >
> > Can you verify that _STA() return zero after cpu unplug?
>
> I've verified that. I've also verified that Linux doesn't call the
> _STA method after Notify(CPxx, 3). It does call _STA on startup and
> after a Notify(CPxx, 1) event. So, the Linux kernel in my FC13 guest
> just seems to be ignoring Notify(3) events. (According to ACPI spec,
> the guest should shutdown the cpu and then call the eject method.)
>
In older kernels _STA was called on Notify(3), but recently cpu hot-plug
in Linux was changed. Can you check what happens if you'll call
Notify(1) on unplug? Spec says that the value is:
Device Check. Used to notify OSPM that the device either
appeared or disappeared.
so may be it should be called on hot-plug and hot-unplug.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
