WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 2/2] Add physical CPU hotplug support in PV_ops d

To: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 2/2] Add physical CPU hotplug support in PV_ops dom0
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 24 Sep 2009 17:49:33 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Thu, 24 Sep 2009 17:49:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E2263E4A5B2284449EEBD0AAB751098418E423149F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E2263E4A5B2284449EEBD0AAB751098418E4231438@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4ABBA9FD.6030808@xxxxxxxx> <E2263E4A5B2284449EEBD0AAB751098418E423149F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel