Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-02-22 Thread Al Stone
On 02/07/2017 05:21 AM, Roger Pau Monné wrote: > Hello Al, > > Thanks for your comments, please see below. > > On Mon, Feb 06, 2017 at 04:06:45PM -0700, Al Stone wrote: >> On 01/24/2017 07:20 AM, Boris Ostrovsky wrote: [snip] >> Then it gets messy :). The APIC and/or x2APIC subtables of

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-02-07 Thread Roger Pau Monné
Hello Al, Thanks for your comments, please see below. On Mon, Feb 06, 2017 at 04:06:45PM -0700, Al Stone wrote: > On 01/24/2017 07:20 AM, Boris Ostrovsky wrote: > > > >> Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT > >> there's > >> no way to reserve anything in there

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-02-06 Thread Al Stone
On 01/24/2017 07:20 AM, Boris Ostrovsky wrote: > >> Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT >> there's >> no way to reserve anything in there (mostly because it's assumed that ACPI >> tables will be created by a single entity I guess). >> >> I think that the chance

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-01-24 Thread Boris Ostrovsky
> Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT there's > no way to reserve anything in there (mostly because it's assumed that ACPI > tables will be created by a single entity I guess). > > I think that the chance of this happening is 0%, and that there's no single >

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-01-23 Thread Jan Beulich
>>> On 23.01.17 at 18:12, wrote: > On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote: >> >>> On 23.01.17 at 17:42, wrote: >> > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: >> >> >>> On 17.01.17 at 18:14,

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-01-23 Thread Roger Pau Monné
On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote: > >>> On 23.01.17 at 17:42, wrote: > > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: > >> >>> On 17.01.17 at 18:14, wrote: > >> > This can be solved by using a different ACPI

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-01-23 Thread Jan Beulich
>>> On 23.01.17 at 17:42, wrote: > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: >> >>> On 17.01.17 at 18:14, wrote: >> > This can be solved by using a different ACPI name in order to describe >> > vCPUs in >> > the ACPI namespace. Most

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-01-23 Thread Roger Pau Monné
On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote: > >>> On 17.01.17 at 18:14, wrote: > > This can be solved by using a different ACPI name in order to describe > > vCPUs in > > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for > > the

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-01-23 Thread Jan Beulich
>>> On 17.01.17 at 18:14, wrote: > This can be solved by using a different ACPI name in order to describe vCPUs > in > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for > the processor objects, so using a 'VP' (ie: Virtual Processor) prefix should

[Xen-devel] [DRAFT C] PVH CPU hotplug design document

2017-01-17 Thread Roger Pau Monné
Hello, Below is a draft of a design document for PVHv2 CPU hotplug. It should cover both vCPU and pCPU hotplug. It's mainly centered around the hardware domain, since for unprivileged PVH guests the vCPU hotplug mechanism is already described in Boris series [0], and it's shared with HVM. The