On 03.03.2020 17:05, Jan Beulich wrote:
> On 28.02.2020 13:31, Roger Pau Monné wrote:
>> On Fri, Feb 28, 2020 at 01:12:03PM +0100, Jan Beulich wrote:
>>> --- a/xen/arch/x86/genapic/x2apic.c
>>> +++ b/xen/arch/x86/genapic/x2apic.c
>>> @@ -236,12 +236,21 @@ const struct genapic *__init apic_x2apic
>>> x2apic_phys = !iommu_intremap ||
>>> (acpi_gbl_FADT.flags & ACPI_FADT_APIC_PHYSICAL);
>>> }
>>> - else if ( !x2apic_phys && !iommu_intremap )
>>> - {
>>> - printk("WARNING: x2APIC cluster mode is not supported without
>>> interrupt remapping\n"
>>> - "x2APIC: forcing phys mode\n");
>>> - x2apic_phys = true;
>>> - }
>>> + else if ( !x2apic_phys )
>>> + switch ( iommu_intremap )
>>> + {
>>> + case iommu_intremap_off:
>>> + case iommu_intremap_restricted:
>>> + printk("WARNING: x2APIC cluster mode is not supported %s
>>> interrupt remapping\n"
>>> + "x2APIC: forcing phys mode\n",
>>> + iommu_intremap == iommu_intremap_off ? "without"
>>> + : "with
>>> restricted");
>>> + x2apic_phys = true;
>>
>> I think you also need to fixup the usage of iommu_intremap in __cpu_up
>> so that CPUs with APIC IDs > 255 are not brought up when in
>> iommu_intremap_restricted mode.
>
> I've looked around some (finding indications that, as one would
> suspect, broadcasting is also supported for IO-APIC based
> interrupts, and then by implication also for MSI) and then also
> thought about this some more. I think the corner case here
> resolves like this: Whether 0xff means "broadcast" exclusively
> depends on the local APIC. Hence in x2APIC mode, even without
> XT, 0xff does not mean "broadcast", and hence the code in
> __cpu_up() is fine as is. In this setup there simply is no way
> to encode broadcast at the IO-APIC or MSI level; luckily we
> also don't use this mode.
I'm talking rubbish - yes, the code needs adjusting as you and I
first thought. All that I'm now sure about is that the adjustment
doesn't need to be more complicated. I'll make a patch.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
