>-----Original Message-----
>From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>Sent: Thursday, May 13, 2010 12:27 AM
>To: Jiang, Yunhong
>Cc: Ian Campbell; xen-devel@xxxxxxxxxxxxxxxxxxx; Jan Beulich
>Subject: Re: [Xen-devel] cpu_down() but no cpu_up() in
>drivers/xen/cpu_hotplug.c ?
>
>On 05/11/2010 08:25 PM, Jiang, Yunhong wrote:
>>> Yes, it was to make it consistent with native physical CPU hotplug. It
>>> also replaced some other xen-specific mechanism to allow the domain to
>>> control when the cpu was actually added (I forget the details; something
>>> like "cpus allowed" vs "cpus active" or something?).
>>>
>> I remember for cpu remove, the xen's vcpu is different to native method. In
>> native,
>it will only trigger a uevent to user space (at least in version like 2.6.31),
>while for
>xen vcpu, it will remove the vcpu directly.
>>
>
>I would think that Xen and native are much the same; if you pull out a
I suspect if native has tested the CPU hotmove. But at least from the code in
container_notify_cb() at drivers/acpi/container.c, seems it will trigger a
uevent to user space and the user space will take action (mostly through eiject
entry under sysfs, I think). But still I don't know if this has been tested on
native environment. So maybe the difference from xen vcpu does not matter.
case ACPI_NOTIFY_DEVICE_CHECK:
printk(KERN_WARNING "Container driver received %s event\n",
(type == ACPI_NOTIFY_BUS_CHECK) ?
"ACPI_NOTIFY_BUS_CHECK" : "ACPI_NOTIFY_DEVICE_CHECK");
status = acpi_bus_get_device(handle, &device);
if (present) {
if (ACPI_FAILURE(status) || !device) {
result = container_device_add(&device, handle);
if (!result)
kobject_uevent(&device->dev.kobj,
KOBJ_ONLINE);
else
printk(KERN_WARNING
"Failed to add container\n");
}
} else {
if (ACPI_SUCCESS(status)) {
/* device exist and this is a remove request */
kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
}
}
>physical CPU from the system, that's in no way advisory ;) Similarly,
>if you remove a vcpu from a guest, that's an external policy being
>imposed onto the guest, and it doesn't get much say in the matter,
>beyond being able to clean up before the vcpu goes away.
>
>If the domain wants to stop using a vcpu, it can simply do that by
>soft-downing the vcpu, but it remains attached to the domain (again,
>analogous to the native case).
>
> J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home