On 01/24/2017 02:43 AM, Jan Beulich wrote:
On 23.01.17 at 19:36, wrote:
> I think this should be introduced in your DomU ACPI CPU hotplug series,
> and not
> set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0
> also.
>
Right, although my underst
>>> On 23.01.17 at 19:36, wrote:
I think this should be introduced in your DomU ACPI CPU hotplug series,
and not
set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0
also.
>>> Right, although my understanding is that the series is on hold until we
>>>
>>> I think this should be introduced in your DomU ACPI CPU hotplug series, and
>>> not
>>> set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0
>>> also.
>>>
>> Right, although my understanding is that the series is on hold until we
>> come to agreement about what to do about
On Mon, Jan 23, 2017 at 12:05:11PM -0500, Boris Ostrovsky wrote:
> On 01/23/2017 11:50 AM, Roger Pau Monné wrote:
> > On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote:
> >> On 01/23/2017 10:58 AM, Jan Beulich wrote:
> >> On 23.01.17 at 16:49, wrote:
> On 01/23/2017 10:43 AM
On 01/23/2017 11:50 AM, Roger Pau Monné wrote:
> On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote:
>> On 01/23/2017 10:58 AM, Jan Beulich wrote:
>> On 23.01.17 at 16:49, wrote:
On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
>>> From Linux perspective one option could be
On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote:
> On 01/23/2017 10:58 AM, Jan Beulich wrote:
> On 23.01.17 at 16:49, wrote:
> >> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
> > From Linux perspective one option could be to have domU with PV-style
> > vCPU on/offlin
On 01/23/2017 10:58 AM, Jan Beulich wrote:
On 23.01.17 at 16:49, wrote:
>> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
> From Linux perspective one option could be to have domU with PV-style
> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
> it becomes a
>>> On 23.01.17 at 16:49, wrote:
> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
From Linux perspective one option could be to have domU with PV-style
vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
it becomes available. This, however, will need an indication
>>> On 23.01.17 at 16:43, wrote:
>>> From Linux perspective one option could be to have domU with PV-style
>>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>>> it becomes available. This, however, will need an indication from the
>>> hypervisor. We could, for example, set
On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
>>> From Linux perspective one option could be to have domU with PV-style
>>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>>> it becomes available. This, however, will need an indication from the
>>> hypervisor. We could, for
>> From Linux perspective one option could be to have domU with PV-style
>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>> it becomes available. This, however, will need an indication from the
>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
>> discu
>>> On 23.01.17 at 15:28, wrote:
> On 01/23/2017 05:35 AM, Jan Beulich wrote:
> On 22.01.17 at 19:39, wrote:
>>> On 01/18/2017 08:25 AM, Jan Beulich wrote:
>>> On 18.01.17 at 12:54, wrote:
> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's
> returned
> f
On 01/23/2017 05:35 AM, Jan Beulich wrote:
On 22.01.17 at 19:39, wrote:
>> On 01/18/2017 08:25 AM, Jan Beulich wrote:
>> On 18.01.17 at 12:54, wrote:
So, would it be fine to start a PVH Dom0 with as many vCPUs as what's
returned
from dom0_max_vcpus, and mark them as enabl
>>> On 22.01.17 at 19:39, wrote:
> On 01/18/2017 08:25 AM, Jan Beulich wrote:
> On 18.01.17 at 12:54, wrote:
>>> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's
>>> returned
>>> from dom0_max_vcpus, and mark them as enabled in the MADT. That's basically
>>> all
>>> we
On 01/18/2017 08:25 AM, Jan Beulich wrote:
On 18.01.17 at 12:54, wrote:
So, would it be fine to start a PVH Dom0 with as many vCPUs as what's returned
from dom0_max_vcpus, and mark them as enabled in the MADT. That's basically all
we need in order to match current PV Dom0 functionality?
Yes,
On 01/18/2017 06:54 AM, Roger Pau Monné wrote:
> On Wed, Jan 18, 2017 at 03:44:19AM -0700, Jan Beulich wrote:
> On 18.01.17 at 11:34, wrote:
>>> On Tue, Jan 17, 2017 at 01:50:14PM -0500, Boris Ostrovsky wrote:
On 01/17/2017 12:45 PM, Roger Pau Monné wrote:
> On Tue, Jan 17, 2017 at 10
>>> On 18.01.17 at 12:54, wrote:
> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's returned
> from dom0_max_vcpus, and mark them as enabled in the MADT. That's basically
> all
> we need in order to match current PV Dom0 functionality?
Yes, I think so.
Jan
___
On Wed, Jan 18, 2017 at 03:44:19AM -0700, Jan Beulich wrote:
> >>> On 18.01.17 at 11:34, wrote:
> > On Tue, Jan 17, 2017 at 01:50:14PM -0500, Boris Ostrovsky wrote:
> >> On 01/17/2017 12:45 PM, Roger Pau Monné wrote:
> >> > On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote:
> >> >> P
>>> On 18.01.17 at 11:34, wrote:
> On Tue, Jan 17, 2017 at 01:50:14PM -0500, Boris Ostrovsky wrote:
>> On 01/17/2017 12:45 PM, Roger Pau Monné wrote:
>> > On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote:
>> >> Part of confusion I think is because PV hotplug is not hotplug, really,
On Tue, Jan 17, 2017 at 01:50:14PM -0500, Boris Ostrovsky wrote:
> On 01/17/2017 12:45 PM, Roger Pau Monné wrote:
> > On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote:
> >> On 01/17/2017 10:33 AM, Jan Beulich wrote:
> >> On 17.01.17 at 16:27, wrote:
> On 01/17/2017 09:44 AM
On 01/17/2017 12:45 PM, Roger Pau Monné wrote:
> On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote:
>> On 01/17/2017 10:33 AM, Jan Beulich wrote:
>> On 17.01.17 at 16:27, wrote:
On 01/17/2017 09:44 AM, Jan Beulich wrote:
On 17.01.17 at 15:13, wrote:
>> There's
On Tue, Jan 17, 2017 at 10:50:44AM -0500, Boris Ostrovsky wrote:
> On 01/17/2017 10:33 AM, Jan Beulich wrote:
> On 17.01.17 at 16:27, wrote:
> >> On 01/17/2017 09:44 AM, Jan Beulich wrote:
> >> On 17.01.17 at 15:13, wrote:
> There's only one kind of PVHv2 guest that doesn't require
On 01/17/2017 10:33 AM, Jan Beulich wrote:
On 17.01.17 at 16:27, wrote:
>> On 01/17/2017 09:44 AM, Jan Beulich wrote:
>> On 17.01.17 at 15:13, wrote:
There's only one kind of PVHv2 guest that doesn't require ACPI, and that
guest
type also doesn't have emulated local APICs
>>> On 17.01.17 at 16:27, wrote:
> On 01/17/2017 09:44 AM, Jan Beulich wrote:
> On 17.01.17 at 15:13, wrote:
>>> There's only one kind of PVHv2 guest that doesn't require ACPI, and that
>>> guest
>>> type also doesn't have emulated local APICs. We agreed that this model was
>>> interesting f
On 01/17/2017 09:44 AM, Jan Beulich wrote:
On 17.01.17 at 15:13, wrote:
>> On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote:
>> On 17.01.17 at 12:43, wrote:
If the PVH domain has access to an APIC and wants to use it it must parse
the
info from the MADT, or els
>>> On 17.01.17 at 15:13, wrote:
> On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote:
>> >>> On 17.01.17 at 12:43, wrote:
>> > If the PVH domain has access to an APIC and wants to use it it must parse
>> > the
>> > info from the MADT, or else it cannot get the APIC address or the APIC
On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote:
> >>> On 17.01.17 at 12:43, wrote:
> > On Tue, Jan 17, 2017 at 02:12:59AM -0700, Jan Beulich wrote:
> >> >>> On 16.01.17 at 18:44, wrote:
> >> > On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
> >> >> >>> On 16.01.17 at 17:
>>> On 17.01.17 at 12:43, wrote:
> On Tue, Jan 17, 2017 at 02:12:59AM -0700, Jan Beulich wrote:
>> >>> On 16.01.17 at 18:44, wrote:
>> > On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
>> >> >>> On 16.01.17 at 17:31, wrote:
>> >> > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beuli
On Tue, Jan 17, 2017 at 02:12:59AM -0700, Jan Beulich wrote:
> >>> On 16.01.17 at 18:44, wrote:
> > On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
> >> >>> On 16.01.17 at 17:31, wrote:
> >> > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> >> >> >>> On 16.01.17 at 16:
>>> On 16.01.17 at 18:44, wrote:
> On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
>> >>> On 16.01.17 at 17:31, wrote:
>> > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
>> >> >>> On 16.01.17 at 16:14, wrote:
>> >> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beuli
On Mon, 16 Jan 2017, Roger Pau Monné wrote:
> On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
> > >>> On 16.01.17 at 17:31, wrote:
> > > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> > >> >>> On 16.01.17 at 16:14, wrote:
> > >> > On Fri, Jan 13, 2017 at 08:51:57AM -0
On Mon, Jan 16, 2017 at 09:50:53AM -0700, Jan Beulich wrote:
> >>> On 16.01.17 at 17:31, wrote:
> > On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> >> >>> On 16.01.17 at 16:14, wrote:
> >> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
> >> >> >>> On 12.01.17 at 13:
>>> On 16.01.17 at 17:31, wrote:
> On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
>> >>> On 16.01.17 at 16:14, wrote:
>> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
>> >> >>> On 12.01.17 at 13:13, wrote:
>> >> > # Introduction
>> >> >
>> >> > One of the design g
On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> >>> On 16.01.17 at 16:14, wrote:
> > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
> >> >>> On 12.01.17 at 13:13, wrote:
> >> > # Introduction
> >> >
> >> > One of the design goals of PVH is to be able to remove as muc
>>> On 16.01.17 at 16:14, wrote:
> On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
>> >>> On 12.01.17 at 13:13, wrote:
>> > # Introduction
>> >
>> > One of the design goals of PVH is to be able to remove as much Xen PV
>> > specific
>> > code as possible, thus limiting the number o
On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
> >>> On 12.01.17 at 13:13, wrote:
> > # Introduction
> >
> > One of the design goals of PVH is to be able to remove as much Xen PV
> > specific
> > code as possible, thus limiting the number of Xen PV interfaces used by
> > guests,
>
On Fri, Jan 13, 2017 at 08:27:30AM -0700, Jan Beulich wrote:
> >>> On 12.01.17 at 20:00, wrote:
> > On 12/01/17 12:13, Roger Pau Monné wrote:
> >> Extra entries are going to be added for each vCPU available to the hardware
> >> domain, up to the maximum number of supported vCPUs. Note that support
On Thu, Jan 12, 2017 at 07:00:57PM +, Andrew Cooper wrote:
> On 12/01/17 12:13, Roger Pau Monné wrote:
[...]
> > ## QEMU CPU hotplug using ACPI
> >
> > The ACPI tables provided to HVM guests contain processor objects, as
> > created by
> > libacpi. The number of processor objects in the ACPI n
>>> On 14.01.17 at 02:44, wrote:
> On 01/13/2017 10:51 AM, Jan Beulich wrote:
> On 12.01.17 at 13:13, wrote:
>>> # Introduction
>>>
>>> One of the design goals of PVH is to be able to remove as much Xen PV
>>> specific
>>> code as possible, thus limiting the number of Xen PV interfaces used
On 01/13/2017 10:51 AM, Jan Beulich wrote:
On 12.01.17 at 13:13, wrote:
>> # Introduction
>>
>> One of the design goals of PVH is to be able to remove as much Xen PV
>> specific
>> code as possible, thus limiting the number of Xen PV interfaces used by
>> guests,
>> and tending to use nativ
On Fri, 13 Jan 2017, Jan Beulich wrote:
> >>> On 12.01.17 at 13:13, wrote:
> > # Introduction
> >
> > One of the design goals of PVH is to be able to remove as much Xen PV
> > specific
> > code as possible, thus limiting the number of Xen PV interfaces used by
> > guests,
> > and tending to use
>>> On 12.01.17 at 13:13, wrote:
> # Introduction
>
> One of the design goals of PVH is to be able to remove as much Xen PV specific
> code as possible, thus limiting the number of Xen PV interfaces used by
> guests,
> and tending to use native interfaces (as used by bare metal) as much as
> pos
>>> On 12.01.17 at 20:00, wrote:
> On 12/01/17 12:13, Roger Pau Monné wrote:
>> ## Proposed solution using the STAO
>>
>> The general idea of this method is to use the STAO in order to hide the pCPUs
>> from the hardware domain, and provide processor objects for vCPUs in an extra
>> SSDT table.
>>
On 01/12/2017 02:00 PM, Andrew Cooper wrote:
On 12/01/17 12:13, Roger Pau Monné wrote:
## Proposed solution using the STAO
The general idea of this method is to use the STAO in order to hide the pCPUs
from the hardware domain, and provide processor objects for vCPUs in an extra
SSDT table.
On 12/01/17 12:13, Roger Pau Monné wrote:
> 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
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 aim
46 matches
Mail list logo
