> We can provide a crafted MADT that reflects the number of vCPUs available to
> Dom0 at boot time, let Dom0 find the Processor objects in the ACPI namespace
> and perform pCPU hotplug as it's been done until now. Then for Dom0 vCPU
> hotplug we would need to use the hypercall interface as it's us
On Fri, Dec 23, 2016 at 12:13:47PM -0500, Boris Ostrovsky wrote:
> On 12/23/2016 11:02 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote:
> >> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote:
> But this still assumes that dom0 handles ACPI
>>> On 22.12.16 at 19:19, wrote:
> On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
>> On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
>> On 22.12.16 at 17:17, wrote:
On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> Maybe Boris has some ideas about how to do CPU hotplug fo
On 12/23/2016 11:02 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote:
>> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote:
But this still assumes that dom0 handles ACPI event for a pCPUs as well,
right? And I am not sure this can work.
On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote:
> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote:
> >> But this still assumes that dom0 handles ACPI event for a pCPUs as well,
> >> right? And I am not sure this can work.
> >>
> >> Actually, how do we hotplug pCPUs now?
> > xen
On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote:
>> But this still assumes that dom0 handles ACPI event for a pCPUs as well,
>> right? And I am not sure this can work.
>>
>> Actually, how do we hotplug pCPUs now?
> xen-hptool
Yes, but this has nothing to do with an actual pCPU being hot-plugge
> But this still assumes that dom0 handles ACPI event for a pCPUs as well,
> right? And I am not sure this can work.
>
> Actually, how do we hotplug pCPUs now?
xen-hptool
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-deve
On Fri, Dec 23, 2016 at 10:27:46AM +, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 01:19:36PM -0500, Boris Ostrovsky wrote:
> > On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
> > > On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> > > On 22.12.16 at 17:17, wrote:
> > >>> O
On 12/23/2016 05:27 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 01:19:36PM -0500, Boris Ostrovsky wrote:
>> On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
>>> On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
>>> On 22.12.16 at 17:17, wrote:
> On 12/22/2016 07:17 AM, Ro
On Thu, Dec 22, 2016 at 01:19:36PM -0500, Boris Ostrovsky wrote:
> On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
> > On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> > On 22.12.16 at 17:17, wrote:
> >>> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> Maybe Boris has some i
On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> On 22.12.16 at 17:17, wrote:
>>> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
>>> Why would Xen need to be abl
On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> >>> On 22.12.16 at 17:17, wrote:
> > On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
> >
> > Why would Xen need to be able to parse the AML that is intended to be
>
>>> On 22.12.16 at 17:17, wrote:
> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
>> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
>
> Why would Xen need to be able to parse the AML that is intended to be
> executed by dom0? I'd think that all the hypervisor would need to do is
On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote:
> On 22.12.16 at 11:43, wrote:
>>> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> Since Xen is the one that sets the local APIC address in the MADT, and it
> al
On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote:
> >>> On 22.12.16 at 11:43, wrote:
> > On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> >> > Since Xen is the one that sets the local APIC address in the MADT, and it
> >> > always matches the position of the emulated local
>>> On 22.12.16 at 11:43, wrote:
> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
>> I'm not convinced these table entries are tied to >255 CPUs - I'm
>> seeing them on systems with far less. Hence I simply wonder what
>> functionality we may miss to offer to OSes with these tables
>
On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> >>> On 21.12.16 at 17:32, wrote:
> > On Mon, Dec 12, 2016 at 06:56:36AM -0700, Jan Beulich wrote:
> >> >>> On 30.11.16 at 17:49, wrote:
> >> > +static int __init hvm_setup_acpi_madt(struct domain *d, paddr_t *addr)
> >> > +{
> >> > +
>>> On 21.12.16 at 17:32, wrote:
> On Mon, Dec 12, 2016 at 06:56:36AM -0700, Jan Beulich wrote:
>> >>> On 30.11.16 at 17:49, wrote:
>> > +static int __init hvm_setup_acpi_madt(struct domain *d, paddr_t *addr)
>> > +{
>> > +struct acpi_table_madt *madt;
>> > +struct acpi_table_header *tabl
On Mon, Dec 12, 2016 at 06:56:36AM -0700, Jan Beulich wrote:
> >>> On 30.11.16 at 17:49, wrote:
> > @@ -567,7 +573,7 @@ static __init void hvm_setup_e820(struct domain *d,
> > unsigned long nr_pages)
> > /*
> > * Craft the e820 memory map for Dom0 based on the hardware e820 map.
> >
>>> On 30.11.16 at 17:49, wrote:
> @@ -567,7 +573,7 @@ static __init void hvm_setup_e820(struct domain *d,
> unsigned long nr_pages)
> /*
> * Craft the e820 memory map for Dom0 based on the hardware e820 map.
> */
> -d->arch.e820 = xzalloc_array(struct e820entry, e820.nr_map)
20 matches
Mail list logo