[PATCH v4 15/15] docs: Describe PVHv2's VCPU hotplug procedure

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Tim Deegan <tim@xen.org>
---
Changes in v4:
* Updated text to reflect new interfaces.

 docs/misc/hvmlite.markdown | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..71c6bc2 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,16 @@ info structure that's passed at boot time (field rsdp_paddr).
 
 Description of paravirtualized devices will come from XenStore, just as it's
 done for HVM guests.
+
+## VCPU hotplug ##
+
+VCPU hotplug (e.g. 'xl vcpu-set <domain> <num_vcpus>') for PVHv2 guests
+follows ACPI model where change in domain's number of VCPUS (stored in
+domain.avail_vcpus) results in an SCI being sent to the guest. The guest
+then executes DSDT's PRSC method, updating MADT enable status for the
+affected VCPU.
+
+This is achieved by having the toolstack issue a write to ACPI's
+XEN_ACPI_CPU_MAP (thus updating the VCPU available map stored there),
+followed by a write to ACPI GPE0 status register, setting XEN_GPE0_CPUHP_BIT.
+The latter will cause an SCI to be generated.
-- 
2.7.4


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