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 Ross Philipson
> Sent: Monday, May 06, 2013 5:07 PM
> To: Konrad Rzeszutek Wilk; jinsong.liu@xxxxxxxxx; Stefano Stabellini;
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] PVHVM VCPU hotplug mechanism via ACPI hotplug
> doesn't work in Xen 4.[1, 2, 3]
> 
> > -----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...

Never mind, I missed the calls above to enable_processor
and disable_processor which seem to be doing the right
thing (long day on a plane). My sample code above had a
type-o but g->gpe0_sts[0] |= 4; looks right.

I still don't understand why it raises the SCI level then edge though.

Ross

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

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