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 the
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
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
> 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
> syst
>>> 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, wrote:
>> >> > This can be solved by using a different ACPI name i
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 name in order to describe
> >> > vCPUs in
> >
>>> 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 hardware vendors tend to use CPU or PR prefi
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 processor objects, so us
>>> 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
> prevent clashes.
I
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
10 matches
Mail list logo