Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

2017-01-04 Thread Jan Beulich 
>>> On 03.01.17 at 20:33,  wrote:
> On 01/03/2017 11:58 AM, Jan Beulich wrote:
> On 03.01.17 at 15:04,  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  ') 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


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

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

2017-01-03 Thread Boris Ostrovsky 
On 01/03/2017 01:19 PM, Stefano Stabellini wrote:
> On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
>> Signed-off-by: Boris Ostrovsky 
>> Reviewed-by: Konrad Rzeszutek Wilk 
>> ---
>> CC: George Dunlap 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Stefano Stabellini 
>> CC: Tim Deegan 
>> ---
>> 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  ') 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.ostrov...@oracle.com,
> this is done via domctl. I think it is worth documenting that.

Will do.

-boirs

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

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

2017-01-03 Thread Boris Ostrovsky 
On 01/03/2017 11:58 AM, Jan Beulich wrote:
 On 03.01.17 at 15:04,  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  ') 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



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

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

2017-01-03 Thread Stefano Stabellini 
On Tue, 3 Jan 2017, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> CC: George Dunlap 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> ---
> 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  ') 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.ostrov...@oracle.com,
this is done via domctl. I think it is worth documenting that.

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

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

2017-01-03 Thread Jan Beulich 
>>> On 03.01.17 at 15:04,  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  ') 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


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

[Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

2017-01-03 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Reviewed-by: Konrad Rzeszutek Wilk 
---
CC: George Dunlap 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
---
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  ') 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.
-- 
2.7.4


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