[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

        printk(KERN_WARNING "Container driver received %s event\n",
               (type == ACPI_NOTIFY_BUS_CHECK) ?
        status = acpi_bus_get_device(handle, &device);
        if (present) {
            if (ACPI_FAILURE(status) || !device) {
                result = container_device_add(&device, handle);
                if (!result)
                           "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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.