Re: [Xen-devel] [PATCH v2 2/4] x86/apic: force phys mode if interrupt remapping is disabled

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Dec 04, 2019 at 10:34:14AM +0100, Jan Beulich wrote:
> On 04.12.2019 10:17, Roger Pau Monné wrote:
> > On Tue, Dec 03, 2019 at 04:14:46PM +0100, Jan Beulich wrote:
> >> On 29.11.2019 12:38, Roger Pau Monné  wrote:
> >>> On Fri, Nov 29, 2019 at 12:28:49PM +0100, Roger Pau Monne wrote:
> >>>> Cluster mode can only be used with interrupt remapping support, since
> >>>> the top 16bits of the APIC ID are filled with the cluster ID, and
> >>>> hence on systems where the physical ID is still smaller than 255 the
> >>>> cluster ID is not. Force x2APIC to use physical mode if there's no
> >>>> interrupt remapping support.
> >>>>
> >>>> Note that this requires a further patch in order to enable x2APIC
> >>>> without interrupt remapping support.
> >>>>
> >>>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >>>
> >>> This is missing a command line doc update and the logic below ignores
> >>> a user-set x2apic_phys value.
> >>
> >> So what would the behavior be in your opinion when the user
> >> has requested cluster mode? I can't see you do much other
> >> than panic()-ing, perhaps it's better to override the request
> >> (as you already do)?
> > 
> > I think panic'ing is fine, a user shouldn't be setting x2apic_phys
> > unless they know what are doing, and then Xen changing it on the back
> > of the user also doesn't seem fine.
> > 
> > A panic explaining that x2apic_phys=false is not supported and that
> > the box can only be booted with x2apic phys mode should be fine IMO.
> 
> I can see this as a valid position to take. Personally, however, I
> do think we should avoid failing to boot if we easily can. (Yes, we
> should log the fact that we ignore a command line option in such a
> case.)

Ack, I don't have a strong opinion, so I would go this route.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel