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
