[Xen-devel] [RFC] pvops domain0 Cx/Px info parser patch

["Yu, Ke" <ke.yu@xxxxxxxxx>]

Hi, Jeremy

Since now the pv_ops domain0 is approaching, we are considering to port the 
dom0 power management related code, or more specifically, the Cx/Px ACPI info 
parsing code, to pv_ops domain0 tree, so that people can utilize Xen power 
management capability (Cx/PX) under pv_ops domain0. This RFC is a draft version 
for comments.

=== Overview ===

Requirement: Xen hypervisor need Cx/Px ACPI info to do the Cx/Px states power 
management. This info is provided by BIOS ACPI table. Since hypervisor has no 
ACPI parser, this info has to be parsed by domain0 kernel ACPI sub-system, and 
then passed to hypervisor by hypercall.

To make this happen, the key point is to add hook in the kernel ACPI 
sub-system. Fortunately, kernel already has good abstraction, and only several 
places need to add hook. To be more detail, there is an acpi_processor_driver 
(in drivers/acpi/processor_core.c) , which all the Cx/Px parsing event will go 
to. This driver will call its acpi processor event handler, e.g. add/remove, 
start/stop, notify to handle these events. These event handlers in turn will 
call some library functions (in drivers/acpi/processor_perflib.c), e.g. 
acpi_processor_ppc_has_changed, acpi_processor_ppc_has_changed, 
acpi_processor_cst_has_changed, to finish the acpi info parsing.

So the conclusion is: adding hooks in acpi_processor_driver and those related 
library functions will satisfy our requirement.

To make the added hook cleaner, we introduce an interface called external 
control operation (struct processor_extcntl_ops). All the hooks are 
encapsulated in this interface processor_extcntl_ops . Here the "external" 
means the acpi processor is controlled by external entity, e.g. VMM. Every kind 
of external entity can has its implementation of this interface. In this patch, 
the interface for Xen is implemented.

== Patch Set Description ==

This patch set is based the xen/dom0/hackery branch. It has three patches:

1.      acpi_parser_framework.patch
This patch introduces the interface of external control operation, and adds 
hooks to the acpi sub-system, including the acpi_processor_driver, and the 
related library functions.

2.      acpi_parser_xen_driver.patch
This patch implements the Xen version of the external control operation 
interface. 

3.      acpi_parser_platform_hypercall.patch
This patches implements the xen_platform_op hypercall, to pass the parsed ACPI 
info to hypervisor.

== Misc ==

To make this patch works correctly, there is a corner case need to consider: 
processor in domain0 is virtual CPU, while BIOS ACPI table provides the 
physical CPU info, since the vCPU and pCPU is not 1:1 mapped, this may caused 
unexpected result.  E.g. in UP domain0, Xen hypervisor may only get one 
physical processor info.  Current linux-2.6.18-xen.hg tree solve this issue by 
using acpi_id instead of processor_id. However, this code is a bit tricky and 
hacky. We are still trying to find a cleaner way to solve this issue.

Comments are welcome.

Best Regards
Yu Ke and Tian Kevin

Attachment: acpi_parser_framework.patch
Description: acpi_parser_framework.patch

Attachment: acpi_parser_platform_hypercall.patch
Description: acpi_parser_platform_hypercall.patch

Attachment: acpi_parser_xen_driver.patch
Description: acpi_parser_xen_driver.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel