From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Jiang, Yunhong" <yunhong.jiang@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <keir.fraser@eu.citrix.com>,
"Yu, Ke" <ke.yu@intel.com>
Subject: Re: [PATCH 2/2] Add physical CPU hotplug support in PV_ops dom0
Date: Thu, 24 Sep 2009 17:49:33 -0700 [thread overview]
Message-ID: <4ABC139D.2050403@goop.org> (raw)
In-Reply-To: <E2263E4A5B2284449EEBD0AAB751098418E423149F@PDSMSX501.ccr.corp.intel.com>
On 09/24/09 17:27, Jiang, Yunhong wrote:
> Do you mean logical offlining or physical offlining? I think logical offlining is tested long before. For physical offlining, I implement it but I have no platform to test still.
>
> In fact , it is a tricky to physical offlining a cpu (or, more precisely speaking, socket) because that means we need offline all memory behind a socket. But it can be used for socket migration, i.e. put down the old CPU and bring up a spare CPU, in that situation, we need CPU offlining. We are still working on socket migration.
>
I see. I guess it makes it hard when the CPUs are also the memory
controllers.
> Yes, also MCE.
> And, are you sure currently the microcode driver really not called in hotplug of vcpus? Will vcpu online not trigger the CPU_online notifier?
>
I would expect vcpu hotplug will call the usual notifiers as expected,
but drivers which really care about pcpus don't have much use for those
notifications.
>> This could do with some clarification. Is this case that a newly
>> added pcpu already appears to be online?
>>
> Because the vIRQ notification for pcpu hotplug from xen hypervisor is async, so maybe it happens after the pcpu is onlined by user. (i.e., the online notification and hotplug notification is merged)
>
I'm not sure I follow. Are you saying this is an expected race, and
that this printk is just for debugging?
>> __init?
>>
>> Also I prefer names of the form subsystem_action, so
>> xen_pcpu_info_init().
>>
> Sorry, what do you mean of subsystem_action? I didn't find definition for it.
>
I meant "<subsystem>_<action>()".
>> So when does this interrupt get raised? Is the full flow:
>>
>> 1. ACPI raises SCI
>> 2. dom0 catches that and gets the new pcpu event
>> 3. dom0 notifies Xen that the pcpu exists
>> 4. xen interrupts dom0 saying that a new pcpu exists
>> 5. dom0 processes the list and adds it to sysfs
>> 6. usermode onlines the cpu for Xen's use
>>
> And there is also step 7, Xen interrupt dom0 saying a new pCPU is onlined. Through step 7, dom0 will have the life cycle of the pCPU.
>
OK, I see.
J
next prev parent reply other threads:[~2009-09-25 0:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 15:31 [PATCH 2/2] Add physical CPU hotplug support in PV_ops dom0 Jiang, Yunhong
2009-09-24 17:18 ` Jeremy Fitzhardinge
2009-09-25 0:27 ` Jiang, Yunhong
2009-09-25 0:49 ` Jeremy Fitzhardinge [this message]
2009-09-25 1:32 ` Jiang, Yunhong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ABC139D.2050403@goop.org \
--to=jeremy@goop.org \
--cc=ke.yu@intel.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
--cc=yunhong.jiang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.