Re: [Xen-devel] PVHVM VCPU hotplug mechanism via ACPI hotplug doesn't work in Xen 4.[1, 2, 3]

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Monday, May 06, 2013 11:45 AM
> To: jinsong.liu@xxxxxxxxx; Stefano Stabellini; xen-
> devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] PVHVM VCPU hotplug mechanism via ACPI hotplug
> doesn't work in Xen 4.[1, 2, 3]
> 
> Which is probably the case b/c the Linux side implementation for
> such simple operation as :
> 
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo 1 > /sys/devices/system/cpu/cpu1/online
> 
> would have blown up so nobody tested it?
> 
> Now that is fixed (v3.10 + http://lists.xen.org/archives/html/xen-
> devel/2013-05/msg00503.html)
> I tried to do 'xm vcpu-set latest X' for a PVHVM guest.
> 
> The first iteration was using this simple guest config:
> builder='hvm'
> disk = [ 'file:/mnt/lab/latest/root_image.iso,hdc:cdrom,r']
> memory = 2048
> boot="d"
> maxvcpus=4
> vcpus=4
> serial='pty'
> vnclisten="0.0.0.0"
> name="latest"
> vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
> 
> And I tried simple combinations of 'x[m|l] vcpu-set latest 2|3|4' and
> none of them worked.
> 
> In Xen 4.1 (and Xen 4.3 if I use:device_model_version="qemu-xen-
> traditional")
> I saw that the qemu log does the right thing:
> .. snip..
> Remove vcpu 2
> Remove vcpu 1
> 
> and the guest's ACPI SCI is incrementing:
> # cat /proc/interrupts  |grep acpi
>    9:          1          0          0   IO-APIC-fasteoi   acpi
> # cat /proc/interrupts  |grep acpi
>    9:          2          0          0   IO-APIC-fasteoi   acpi
> 
> But nothing looks to be happening. Where should I look?
> The ACPI DSDT is a bit daunting. Has this ever worked in the past?
> If so, what code ran to hotplug CPUs?

I am looking at qemu-traditional (I believe it is traditional
here: http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=summary).

The code for raising the SCI for processor hotplug doesn't
look quite right to me. This is the code I see in
qemu_cpu_add_remove:

    if (gpe_state.gpe0_en[0] & 4) {
        qemu_set_irq(sci_irq, 1);
        qemu_set_irq(sci_irq, 0);
    }

I would expect the code to actually set the GPE status bit for
the GPE register in question (in this case bit 2 for _L02), maybe:

    if ((gpe_state.gpe0_en[0] & 4)&&
        ((gpe_state.gpe0_sts[0] & 4) == 0)) {
        gpe_state.gpe0_sts[0] &= 4;
        qemu_irq_raise(sci_irq);
    }

I also don't understand why it is raising the SCI as level and
then edge. That GPE is defined in the DSDT as level:

    /* Define GPE control method '_L02'. */
    push_block("Scope", "\\_GPE");
    push_block("Method", "_L02");
    stmt("Return", "\\_SB.PRSC()");

Maybe look at how the PCI hotplug GPE's occur (ACPI_PHP_GPE_BIT). Without
setting a status register the SCI may just be going in the bit bucket.

Anyway hope this is helpful at all...

Ross

> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel