Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure
>>> 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
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
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
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
>>> 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
Signed-off-by: Boris OstrovskyReviewed-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