All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: boris.ostrovsky@oracle.com, xen-devel@lists.xen.org
Subject: Re: [RFC PATCH] xen, apic: Setup our own APIC driver and validator for APIC IDs.
Date: Wed, 11 Feb 2015 13:37:43 -0500	[thread overview]
Message-ID: <20150211183743.GA23598@l.oracle.com> (raw)
In-Reply-To: <54DB2696.30403@citrix.com>

On Wed, Feb 11, 2015 at 09:53:26AM +0000, David Vrabel wrote:
> On 10/02/15 20:33, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 22, 2015 at 10:00:55AM +0000, David Vrabel wrote:
> >> On 21/01/15 21:56, Konrad Rzeszutek Wilk wrote:
> >>> +static struct apic xen_apic = {
> >>> +	.name = "Xen",
> >>> +	.probe = probe_xen,
> >>> +	/* The rest is copied from the default. */
> >>
> >> Explicitly initialize all required members here.  memcpy'ing from the
> >> default makes it far too unclear which ops this apic driver actually
> >> provides.
> > 
> > RFC (boots under PV, PVHVM, PV dom0):

And it boots under the 288 CPU machine (the original problem)
.. thought it exposes two other issues:


(XEN) SMP: Allowing 288 CPUs (0 hotplug CPUs)
(XEN) Brought up 288 CPUs
..
(XEN) Dom0 has maximum 255 VCPUs
(XEN) xentrace: p157 mfn 225524 offset 35896
(XEN) xentrace: p255 mfn 21fe3e offset 58142
[    0.000000] smpboot: Allowing 288 CPUs, 0 hotplug CPUs
[    0.000000] xen_filter_cpu_maps: CPU255 is not up!
..
[    0.000000] xen_filter_cpu_maps: CPU287 is not up!
[    0.000000] xen_filter_cpu_maps: nr_cpu_ids: 288, subtract: 33
[    0.000000] 	RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=255.

... with the result that we can't bring up the 256->287 CPUs up.

It looks as if we a limiting Dom0 to 255. That seems to be due to:

> > 
> > From 27702ef618af068736d13aeadcbcacd2a6780e82 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Fri, 9 Jan 2015 17:55:52 -0500
> > Subject: [PATCH] xen,apic: Setup our own APIC driver and validator for APIC
> >  IDs.
> > 
> > Via CPUID masking and the different apic-> overrides we
> > effectively make PV guests only but with the default APIC
> > driver. That is OK as an PV guest should never access any
> > APIC registers. However, the APIC is also used to limit the
> > amount of CPUs if the APIC IDs are incorrect - and since we
> > mask the x2APIC from the CPUID - any APIC IDs above 0xFF
> > are deemed incorrect by the default APIC routines.
> > 
> > As such add a new routine to check for APIC ID which will
> > be only used if the CPUID (native one) tells us the system
> > is using x2APIC.
> > 
> > This allows us to boot with more than 255 CPUs if running
> > as initial domain.
> 
> This looks quite reasonable to me.  What order are apic driver tried in?

No order. Or rather the order is based on how the compiler stashes
them in.

>  Do we need a mechanism to ensure that this one is tried before any for
> real hardware?

There are two probe mechanism - the .probe and then later it is:
x86_platform.apic_post_init which we can also utilize to make sure
the APIC is set to Xen.

Let me add that in.

> 
> > +static struct apic xen_apic = {
> > +	.name 				= "Xen PV",
> > +	.probe 				= probe_xen,
> > +	.acpi_madt_oem_check		= xen_madt_oem_check,
> > +	.apic_id_valid 			= xen_id_always_valid,
> > +	.apic_id_registered 		= xen_id_always_registered,
> > +
> > +	.irq_delivery_mode		= 0xbeef, /* used in native_compose_msi_msg only */
> > +	.irq_dest_mode			= 0xbeef, /* used in native_compose_msi_msg only */
> 
> Omit members that are unused, leaving them as 0 or NULL.
> 
> > +	.target_cpus			= default_target_cpus,
> > +	.disable_esr			= 0,
> > +	.dest_logical			= 0, /* default_send_IPI_ use it but we use our own. */
> > +	.check_apicid_used		= default_check_apicid_used, /* Used on 32-bit */
> > +
> > +	.vector_allocation_domain	= flat_vector_allocation_domain,
> > +	.init_apic_ldr			= xen_noop, /* setup_local_APIC calls it */
> > +
> > +	.ioapic_phys_id_map		= default_ioapic_phys_id_map, /* Used on 32-bit */
> > +	.setup_apic_routing		= NULL,
> > +	.cpu_present_to_apicid		= default_cpu_present_to_apicid,
> > +	.apicid_to_cpu_present		= physid_set_mask_of_physid, /* Used on 32-bit */
> > +	.check_phys_apicid_present	= default_check_phys_apicid_present, /* smp_sanity_check needs it */
> > +	.phys_pkg_id			= xen_phys_pkg_id, /* detect_ht */
> > +
> > +	.get_apic_id 			= xen_get_apic_id,
> > +	.set_apic_id 			= xen_set_apic_id, /* Can be NULL on 32-bit. */
> > +	.apic_id_mask			= 0xFF << 24, /* Used by verify_local_APIC. Match with what xen_get_apic_id does. */
> > +
> > +	.cpu_mask_to_apicid_and		= flat_cpu_mask_to_apicid_and,
> > +
> > +	.send_IPI_mask 			= xen_send_IPI_mask,
> > +	.send_IPI_mask_allbutself 	= xen_send_IPI_mask_allbutself,
> > +	.send_IPI_allbutself 		= xen_send_IPI_allbutself,
> > +	.send_IPI_all 			= xen_send_IPI_all,
> > +	.send_IPI_self 			= xen_send_IPI_self,
> > +
> > +	.wait_for_init_deassert		= false, /* Used by AP bootup - smp_callin which we don't use */
> 
> Omit.
> 
> David

  reply	other threads:[~2015-02-11 18:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 21:56 [RFC PATCH] xen,apic: Setup our own APIC driver and validator for APIC IDs Konrad Rzeszutek Wilk
2015-01-22 10:00 ` [RFC PATCH] xen, apic: " David Vrabel
2015-01-22 15:09   ` Konrad Rzeszutek Wilk
2015-01-22 15:14     ` David Vrabel
2015-01-22 19:22       ` Konrad Rzeszutek Wilk
2015-01-22 21:41         ` Konrad Rzeszutek Wilk
2015-02-10 20:33   ` Konrad Rzeszutek Wilk
2015-02-11  9:53     ` David Vrabel
2015-02-11 18:37       ` Konrad Rzeszutek Wilk [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-01-21 21:56 Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150211183743.GA23598@l.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.