| Message ID | 1483452256-2879-13-git-send-email-boris.ostrovsky@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> 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
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.
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
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
>>> 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 --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.