RE: [Xen-devel] cpu_down() but no cpu_up() in drivers/xen/cpu_hotplug.c ?

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----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