On Thu, Sep 14, 2023 at 12:18 AM Stefano Stabellini
wrote:
>
> On Wed, 13 Sep 2023, George Dunlap wrote:
> > On Tue, Sep 12, 2023 at 8:57 AM Thomas Gleixner wrote:
> > >
> > > On Mon, Sep 11 2023 at 19:24, Andrew Cooper wrote:
> > > > Furthermore, cursory testing that Thomas did for the Linux top
On Wed, 13 Sep 2023, George Dunlap wrote:
> On Tue, Sep 12, 2023 at 8:57 AM Thomas Gleixner wrote:
> >
> > On Mon, Sep 11 2023 at 19:24, Andrew Cooper wrote:
> > > Furthermore, cursory testing that Thomas did for the Linux topology work
> > > demonstrates that it is broken anyway for reasons unrel
On Tue, Sep 12, 2023 at 8:57 AM Thomas Gleixner wrote:
>
> On Mon, Sep 11 2023 at 19:24, Andrew Cooper wrote:
> > Furthermore, cursory testing that Thomas did for the Linux topology work
> > demonstrates that it is broken anyway for reasons unrelated to ACPI parsing.
> >
> > Even furthermore, it's
On Mon, Sep 11, 2023 at 03:38:05PM -0700, Stefano Stabellini wrote:
> On Mon, 11 Sep 2023, Andrew Cooper wrote:
> > Physical CPU Hotplug does not pass the bar for being anything more than
> > experimental. It's absolutely not tech-preview level because the only
> > demo it has had in an environmen
On 12.09.2023 10:41, Jan Beulich wrote:
> On 11.09.2023 20:05, Simon Gaiser wrote:
>> You also commented about not logging the ignored entries. Until it's
>> clear if the change in general is accepted in the end, I considered it
>> pointless to address that detail. If you disagree and want a follow
On 11.09.2023 20:05, Simon Gaiser wrote:
> Jan Beulich:
>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux already has code to handle those
On 12.09.2023 10:33, Jan Beulich wrote:
> And note how I offered a compromise by someone (Simon, you, Roger, or yet
> someone else) sending a patch against SUPPORT.md. Yet that hasn't happened.
> I therefore continue to be of the opinion that I can rightfully revert the
> patch, based on process no
On 11.09.2023 20:24, Andrew Cooper wrote:
> On 06/09/2023 9:49 pm, Stefano Stabellini wrote:
>> On Fri, 1 Sep 2023, Jan Beulich wrote:
>>> On 07.08.2023 11:38, Simon Gaiser wrote:
It seems some firmwares put dummy entries in the ACPI MADT table for non
existing processors. On my NUC11TNHi
On Mon, Sep 11 2023 at 19:24, Andrew Cooper wrote:
> Furthermore, cursory testing that Thomas did for the Linux topology work
> demonstrates that it is broken anyway for reasons unrelated to ACPI parsing.
>
> Even furthermore, it's an area of the Xen / dom0 boundary which is
> fundamentally broken
On Mon, 11 Sep 2023, Andrew Cooper wrote:
> Physical CPU Hotplug does not pass the bar for being anything more than
> experimental. It's absolutely not tech-preview level because the only
> demo it has had in an environment (admittedly virtual) which does
> implement the spec in a usable way demon
On 06/09/2023 9:49 pm, Stefano Stabellini wrote:
> On Fri, 1 Sep 2023, Jan Beulich wrote:
>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux
Jan Beulich:
> On 07.08.2023 11:38, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both in
>> acpi_parse_lapic [1] as well a
Andrew Cooper:
> On 07/08/2023 3:45 pm, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 07/08/2023 10:38 am, Simon Gaiser wrote:
It seems some firmwares put dummy entries in the ACPI MADT table for non
existing processors. On my NUC11TNHi5 those have the invalid APIC ID
0xff. Linux alre
On Thu, 7 Sep 2023, Jan Beulich wrote:
> On 06.09.2023 22:49, Stefano Stabellini wrote:
> > On Fri, 1 Sep 2023, Jan Beulich wrote:
> >> On 07.08.2023 11:38, Simon Gaiser wrote:
> >>> It seems some firmwares put dummy entries in the ACPI MADT table for non
> >>> existing processors. On my NUC11TNHi5
On 06.09.2023 22:49, Stefano Stabellini wrote:
> On Fri, 1 Sep 2023, Jan Beulich wrote:
>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux a
On Fri, 1 Sep 2023, Jan Beulich wrote:
> On 07.08.2023 11:38, Simon Gaiser wrote:
> > It seems some firmwares put dummy entries in the ACPI MADT table for non
> > existing processors. On my NUC11TNHi5 those have the invalid APIC ID
> > 0xff. Linux already has code to handle those cases both in
> >
On 07.08.2023 11:38, Simon Gaiser wrote:
> It seems some firmwares put dummy entries in the ACPI MADT table for non
> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
> 0xff. Linux already has code to handle those cases both in
> acpi_parse_lapic [1] as well as in acpi_parse_x2a
Jan!
On Wed, Aug 30 2023 at 09:20, Jan Beulich wrote:
> On 30.08.2023 00:54, Thomas Gleixner wrote:
>> On Tue, Aug 29 2023 at 16:25, Roger Pau Monné wrote:
>>
>> Correct. These IDs are invalid independent of any flag value.
>
> What we apparently agree on is these special UID values to be invali
On 30.08.2023 00:54, Thomas Gleixner wrote:
> On Tue, Aug 29 2023 at 16:25, Roger Pau Monné wrote:
>> On Sun, Aug 27, 2023 at 05:44:15PM +0200, Thomas Gleixner wrote:
>>> The APIC/X2APIC description of MADT specifies flags:
>>>
>>> Enabled If this bit is set the processor is ready for u
On Tue, Aug 29 2023 at 16:25, Roger Pau Monné wrote:
> On Sun, Aug 27, 2023 at 05:44:15PM +0200, Thomas Gleixner wrote:
>> The APIC/X2APIC description of MADT specifies flags:
>>
>> Enabled If this bit is set the processor is ready for use. If
>> this bit is clear and the
On Sun, Aug 27, 2023 at 05:44:15PM +0200, Thomas Gleixner wrote:
> On Wed, Aug 23 2023 at 14:56, Jan Beulich wrote:
> > On 23.08.2023 11:21, Andrew Cooper wrote:
> >> In the spec, exactly where you'd expect to find them...
> >>
> >> "OSPM does not expect the information provided in this table to b
On Wed, Aug 23 2023 at 14:56, Jan Beulich wrote:
> On 23.08.2023 11:21, Andrew Cooper wrote:
>> In the spec, exactly where you'd expect to find them...
>>
>> "OSPM does not expect the information provided in this table to be
>> updated if the processor information changes during the lifespan of an
On 23.08.2023 11:21, Andrew Cooper wrote:
> On 07/08/2023 3:18 pm, Jan Beulich wrote:
>> On 07.08.2023 16:04, Andrew Cooper wrote:
>>> On 07/08/2023 2:17 pm, Jan Beulich wrote:
On 07.08.2023 14:55, Simon Gaiser wrote:
> Jan Beulich:
>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>> I
On 07/08/2023 3:45 pm, Simon Gaiser wrote:
> Andrew Cooper:
>> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux already has code to handle
On 07/08/2023 3:18 pm, Jan Beulich wrote:
> On 07.08.2023 16:04, Andrew Cooper wrote:
>> On 07/08/2023 2:17 pm, Jan Beulich wrote:
>>> On 07.08.2023 14:55, Simon Gaiser wrote:
Jan Beulich:
> On 07.08.2023 11:38, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the AC
On Mon, Aug 07, 2023 at 03:17:18PM +0200, Jan Beulich wrote:
> On 07.08.2023 14:55, Simon Gaiser wrote:
> > Jan Beulich:
> >> On 07.08.2023 11:38, Simon Gaiser wrote:
> >>> It seems some firmwares put dummy entries in the ACPI MADT table for non
> >>> existing processors. On my NUC11TNHi5 those hav
Jan Beulich:
> On 07.08.2023 14:55, Simon Gaiser wrote:
>> Jan Beulich:
>>> On 07.08.2023 11:38, Simon Gaiser wrote:
It seems some firmwares put dummy entries in the ACPI MADT table for non
existing processors. On my NUC11TNHi5 those have the invalid APIC ID
0xff. Linux already has c
Andrew Cooper:
> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both in
>> acpi_parse_lapic [1] as w
On 07.08.2023 16:04, Andrew Cooper wrote:
> On 07/08/2023 2:17 pm, Jan Beulich wrote:
>> On 07.08.2023 14:55, Simon Gaiser wrote:
>>> Jan Beulich:
On 07.08.2023 11:38, Simon Gaiser wrote:
> It seems some firmwares put dummy entries in the ACPI MADT table for non
> existing processors.
On 07/08/2023 2:17 pm, Jan Beulich wrote:
> On 07.08.2023 14:55, Simon Gaiser wrote:
>> Jan Beulich:
>>> On 07.08.2023 11:38, Simon Gaiser wrote:
It seems some firmwares put dummy entries in the ACPI MADT table for non
existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>
On 07.08.2023 14:55, Simon Gaiser wrote:
> Jan Beulich:
>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux already has code to handle those
Jan Beulich:
> On 07.08.2023 11:38, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both in
>> acpi_parse_lapic [1] as well a
Andrew Cooper:
> On 07/08/2023 11:01 am, Andrew Cooper wrote:
>> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux already has code to hand
On 07.08.2023 11:38, Simon Gaiser wrote:
> It seems some firmwares put dummy entries in the ACPI MADT table for non
> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
> 0xff. Linux already has code to handle those cases both in
> acpi_parse_lapic [1] as well as in acpi_parse_x2a
On 07/08/2023 11:01 am, Andrew Cooper wrote:
> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both i
On 07/08/2023 10:38 am, Simon Gaiser wrote:
> It seems some firmwares put dummy entries in the ACPI MADT table for non
> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
> 0xff. Linux already has code to handle those cases both in
> acpi_parse_lapic [1] as well as in acpi_parse_
It seems some firmwares put dummy entries in the ACPI MADT table for non
existing processors. On my NUC11TNHi5 those have the invalid APIC ID
0xff. Linux already has code to handle those cases both in
acpi_parse_lapic [1] as well as in acpi_parse_x2apic [2]. So add the
same check to Xen.
Note that
37 matches
Mail list logo
