diff mbox

[v6,12/12] docs: Describe PVHv2's VCPU hotplug procedure

Message ID 1483452256-2879-13-git-send-email-boris.ostrovsky@oracle.com (mailing list archive)
State New, archived
Headers show

Commit Message

Boris Ostrovsky Jan. 3, 2017, 2:04 p.m. UTC
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@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 v6:
* No GPE0 update is needed anymore.

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

Comments

Jan Beulich Jan. 3, 2017, 4:58 p.m. UTC | #1
>>> On 03.01.17 at 15:04, <boris.ostrovsky@oracle.com> wrote:
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,14 @@ 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.
> +
> +Updating VCPU number is achieved by having the toolstack issue a write to
> +ACPI's XEN_ACPI_CPU_MAP.

Is any of this valid anymore in the context of the recent discussion?
Perhaps even wider - how much of this series is applicable if pCPU
hotplug is to use the normal ACPI code path? I hope the plan is not
to have different vCPU hotplug for DomU and Dom0?

Jan
Stefano Stabellini Jan. 3, 2017, 6:19 p.m. UTC | #2
On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@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 v6:
> * No GPE0 update is needed anymore.
> 
>  docs/misc/hvmlite.markdown | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
> index 898b8ee..472edee 100644
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,14 @@ 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.
> +
> +Updating VCPU number is achieved by having the toolstack issue a write to
> +ACPI's XEN_ACPI_CPU_MAP.

Looking at 1483452256-2879-10-git-send-email-boris.ostrovsky@oracle.com,
this is done via domctl. I think it is worth documenting that.
Boris Ostrovsky Jan. 3, 2017, 7:33 p.m. UTC | #3
On 01/03/2017 11:58 AM, Jan Beulich wrote:
>>>> On 03.01.17 at 15:04, <boris.ostrovsky@oracle.com> wrote:
>> --- a/docs/misc/hvmlite.markdown
>> +++ b/docs/misc/hvmlite.markdown
>> @@ -75,3 +75,14 @@ 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.
>> +
>> +Updating VCPU number is achieved by having the toolstack issue a write to
>> +ACPI's XEN_ACPI_CPU_MAP.
> Is any of this valid anymore in the context of the recent discussion?
> Perhaps even wider - how much of this series is applicable if pCPU
> hotplug is to use the normal ACPI code path? 

pCPU hotplug is not going to use this path because it would not be
executing PRSC method that we (Xen toolstack) provide.


> I hope the plan is not
> to have different vCPU hotplug for DomU and Dom0?

That was not the plan. But I haven't thought of dom0 not being able to
execute PRSC.

-boris
Boris Ostrovsky Jan. 3, 2017, 8:31 p.m. UTC | #4
On 01/03/2017 01:19 PM, Stefano Stabellini wrote:
> On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@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 v6:
>> * No GPE0 update is needed anymore.
>>
>>  docs/misc/hvmlite.markdown | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
>> index 898b8ee..472edee 100644
>> --- a/docs/misc/hvmlite.markdown
>> +++ b/docs/misc/hvmlite.markdown
>> @@ -75,3 +75,14 @@ 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.
>> +
>> +Updating VCPU number is achieved by having the toolstack issue a write to
>> +ACPI's XEN_ACPI_CPU_MAP.
> Looking at 1483452256-2879-10-git-send-email-boris.ostrovsky@oracle.com,
> this is done via domctl. I think it is worth documenting that.

Will do.

-boirs
Jan Beulich Jan. 4, 2017, 9:26 a.m. UTC | #5
>>> On 03.01.17 at 20:33, <boris.ostrovsky@oracle.com> wrote:
> On 01/03/2017 11:58 AM, Jan Beulich wrote:
>>>>> On 03.01.17 at 15:04, <boris.ostrovsky@oracle.com> wrote:
>>> --- a/docs/misc/hvmlite.markdown
>>> +++ b/docs/misc/hvmlite.markdown
>>> @@ -75,3 +75,14 @@ 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.
>>> +
>>> +Updating VCPU number is achieved by having the toolstack issue a write to
>>> +ACPI's XEN_ACPI_CPU_MAP.
>> Is any of this valid anymore in the context of the recent discussion?
>> Perhaps even wider - how much of this series is applicable if pCPU
>> hotplug is to use the normal ACPI code path? 
> 
> pCPU hotplug is not going to use this path because it would not be
> executing PRSC method that we (Xen toolstack) provide.
> 
> 
>> I hope the plan is not
>> to have different vCPU hotplug for DomU and Dom0?
> 
> That was not the plan. But I haven't thought of dom0 not being able to
> execute PRSC.

Well - bottom line to me then is: This series needs to be deferred
until there is a plan for acceptable Dom0 behavior. In particular it
may well be that PVH needs to go the PV vCPU hotplug route instead,
in which case we'd need to evaluate which of the already committed
patches make no sense anymore.

Jan
diff mbox

Patch

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..472edee 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,14 @@  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.
+
+Updating VCPU number is achieved by having the toolstack issue a write to
+ACPI's XEN_ACPI_CPU_MAP.