On 11/18/2016 06:16 AM, Thomas Gleixner wrote:
> On Mon, 14 Nov 2016, Boris Ostrovsky wrote:
>> On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:
>>
>>> I found out that my domU kernels invoke the 'apic_disable' function
>>> because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
>>> wh
On Mon, 14 Nov 2016, Boris Ostrovsky wrote:
> On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:
>
> > I found out that my domU kernels invoke the 'apic_disable' function
> > because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
> > which would cause the 'smp_found_config' bit to be u
On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:
I found out that my domU kernels invoke the 'apic_disable' function
because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
which would cause the 'smp_found_config' bit to be unset at boot-up.
smp_found_config is not the problem,
On 11/13/2016 09:04 PM, Boris Ostrovsky wrote:
> On 11/12/2016 05:05 PM, M. Vefa Bicakci wrote:
>> On 11/10/2016 06:31 PM, Boris Ostrovsky wrote:
>>> On 11/10/2016 10:05 AM, Charles (Chas) Williams wrote:
On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
> On 11/10/2016 06:13 AM, Thomas
On 11/12/2016 05:05 PM, M. Vefa Bicakci wrote:
> On 11/10/2016 06:31 PM, Boris Ostrovsky wrote:
>> On 11/10/2016 10:05 AM, Charles (Chas) Williams wrote:
>>>
>>> On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, M. Vefa Bic
On 11/10/2016 01:50 PM, Charles (Chas) Williams wrote:
>
>
> On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote:
>> [0.002000] mvb: CPU: Physical Processor ID: 0
>> [0.002000] mvb: CPU: Processor Core ID: 0
>> [0.002000] mvb: identify_cpu:1112: c: 880013b0a040,
>> c->logical_proc_id: 6
On 11/10/2016 06:31 PM, Boris Ostrovsky wrote:
> On 11/10/2016 10:05 AM, Charles (Chas) Williams wrote:
>>
>>
>> On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
>>> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
> I have found that your patch
On 11/10/2016 12:13 PM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>> On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
By firmware you mean ACPI? It is most likely not available to PV guests.
>>> You either have to provide
On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> On 11/10/2016 10:05 AM, Charles (Chas) Williams wrote:
> For Xen, we recently added a6a198bc60e6 ("xen/x86: Update topology map
> for PV VCPUs") to at least temporarily work around some topology map
> problems that PV guests have with RAPL (which I thin
On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
> > On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> >> By firmware you mean ACPI? It is most likely not available to PV guests.
> > You either have to provide ACPI or MP tables. And either of those has to
> >
On 2016-11-10 10:31:20 [-0500], Boris Ostrovsky wrote:
> For Xen, we recently added a6a198bc60e6 ("xen/x86: Update topology map
> for PV VCPUs") to at least temporarily work around some topology map
> problems that PV guests have with RAPL (which I think is what Vefa's
> problem was).
I wouldn't b
On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
>>>
I have found that your patch unfortunately does not improve the situation
for me. Here is an e
On 11/10/2016 10:05 AM, Charles (Chas) Williams wrote:
>
>
> On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
>> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
>>>
I have found that your patch unfortunately does not improve the
situation
On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
> > On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
> >
> >> I have found that your patch unfortunately does not improve the situation
> >> for me. Here is an excerpt obtained from the dmesg of a kernel compile
On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
I have found that your patch unfortunately does not improve the situation
for me. Here is an excerpt obtained from the dmesg of a kernel compiled
with thi
On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
>
>> I have found that your patch unfortunately does not improve the situation
>> for me. Here is an excerpt obtained from the dmesg of a kernel compiled
>> with this patch *as well as* Sebastian's patch:
>
On Thu, Nov 10, 2016 at 12:13:04PM +0100, Thomas Gleixner wrote:
> What's so wrong with storing the fricking firmware supplied APICid as
> everybody else does and report it back when queried?
>
> This damned attitude of we just hack the code into submission and let
> everybody else deal with the o
On Thu, 10 Nov 2016, Charles (Chas) Williams wrote:
> On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote:
> > [0.002000] mvb: CPU: Physical Processor ID: 0
> > [0.002000] mvb: CPU: Processor Core ID: 0
> > [0.002000] mvb: identify_cpu:1112: c: 880013b0a040,
> > c->logical_proc_id: 65535
On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
> I have found that your patch unfortunately does not improve the situation
> for me. Here is an excerpt obtained from the dmesg of a kernel compiled
> with this patch *as well as* Sebastian's patch:
> [0.002561] CPU: Physical Processor ID: 0
> [
On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote:
[0.002000] mvb: CPU: Physical Processor ID: 0
[0.002000] mvb: CPU: Processor Core ID: 0
[0.002000] mvb: identify_cpu:1112: c: 880013b0a040, c->logical_proc_id:
65535
[0.002000] mvb: __default_cpu_present_to_apicid:612: Returnin
On 11/09/2016 06:35 PM, Thomas Gleixner wrote:
> Both ACPI and MP specifications require that the APIC id in the respective
> tables must be the same as the APIC id in CPUID.
>
> The kernel retrieves the physical package id from the APIC id during the
> ACPI/MP table scan and builds the physical
On Wed, 9 Nov 2016, Charles (Chas) Williams wrote:
> On 11/09/2016 11:03 AM, Peter Zijlstra wrote:
> > On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote:
> > > Both ACPI and MP specifications require that the APIC id in the respective
> > > tables must be the same as the APIC id in CP
On 11/09/2016 10:35 AM, Thomas Gleixner wrote:
Both ACPI and MP specifications require that the APIC id in the respective
tables must be the same as the APIC id in CPUID.
The kernel retrieves the physical package id from the APIC id during the
ACPI/MP table scan and builds the physical to logica
On 11/09/2016 11:03 AM, Peter Zijlstra wrote:
On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote:
Both ACPI and MP specifications require that the APIC id in the respective
tables must be the same as the APIC id in CPUID.
The kernel retrieves the physical package id from the APIC
On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote:
> Both ACPI and MP specifications require that the APIC id in the respective
> tables must be the same as the APIC id in CPUID.
>
> The kernel retrieves the physical package id from the APIC id during the
> ACPI/MP table scan and bu
On Wed, 9 Nov 2016, Thomas Gleixner wrote:
> + if (pkg != c->phys_proc_id) {
> + pr_err(FW_BUG "CPU%u: Using firmware package id %u instead of
> %u\n",
> +cpu, pkg, c->phys_proc_id);
> + c->phys_proc_id = pkg;
> + }
> + c->logical_proc_id = t
Both ACPI and MP specifications require that the APIC id in the respective
tables must be the same as the APIC id in CPUID.
The kernel retrieves the physical package id from the APIC id during the
ACPI/MP table scan and builds the physical to logical package map.
There exist Virtualbox and Xen i
27 matches
Mail list logo
