RE: [PATCH] xen/acpi-stub: Disable it b/c the acpi_processor_add isno longer called.

[Liu, Jinsong]

 Konrad Rzeszutek Wilk wrote:
> With the Xen ACPI stub code (CONFIG_XEN_STUB=y) enabled, the power
> C and P states are no longer uploaded to the hypervisor.
> 
> The reason is that the Xen CPU hotplug code: xen-acpi-cpuhotplug.c
> and the xen-acpi-stub.c register themselves as the "processor" type
> object. 
> 
> That means the generic processor (processor_driver.c) stops
> working and it does not call (acpi_processor_add) which populates the
> 
>          per_cpu(processors, pr->id) = pr;
> 
> structure. The 'pr' is gathered from the acpi_processor_get_info
> function which does the job of finding the C-states and figuring out
> PBLK address. 
> 
> The 'processors->pr' is then later used by xen-acpi-processor.c (the
> one that uploads C and P states to the hypervisor). Since it is NULL,
> we end 
> skip the gathering of _PSD, _PSS, _PCT, etc and never upload the power
> management data.
> 
> The end result is that enabling the CONFIG_XEN_STUB in the build
> means that xen-acpi-processor is not working anymore.
> 
> This temporary patch fixes it by marking the XEN_STUB driver as
> BROKEN until this can be properly fixed.
> 
> CC: jinsong.liu@xxxxxxxxx
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> ---
>  drivers/xen/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 5a32232..67af155 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -182,7 +182,7 @@ config XEN_PRIVCMD
> 
>  config XEN_STUB
>  	bool "Xen stub drivers"
> -	depends on XEN && X86_64
> +	depends on XEN && X86_64 && BROKEN
>  	default n
>  	help
>  	  Allow kernel to install stub drivers, to reserve space for Xen
> drivers, 


Yes, exactly.

With xen-cpu-hotplug logic added, it's not proper to make xen Px/Cx rely on native processor_driver anymore.
Reasonable solution is, hooking Px/Cx logic into xen hotplug path (say, ops.add --> acpi_processor_add), like what native side does currently.

So at Xen dom0 side, there are 2 issues need to be solved:
1. currently xen dom0 defaultly set cpu_possible_map equal to cpu_present_map, we need adjust it so that when cpu hotplug it can handle 'pr' properly;
2. hook Px/Cx parsing logic into cpu hotadd or cpu online logic, like what native side did;

Attached is a patch to solve issue 1, basically it generates possible map according to MADT entries, not trims according to hypervisor online cpus. With it, dom0 cpu possible map reserves space for Xen cpu hotplug and corresponding Px/Cx, and dom0 also get a unified possible map view just like it runs under native platform.

As for issue 2, it may be fixed later :-)
(BTW, your patch to temporarily disable xen-stub is necessary even with my patch, only would be reverted after issue 2 got solved)

Thanks,
Jinsong

========================