All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	boris.ostrovsky@oracle.com
Cc: 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 09:53:26 +0000	[thread overview]
Message-ID: <54DB2696.30403@citrix.com> (raw)
In-Reply-To: <20150210203330.GA9806@l.oracle.com>

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):
> 
> 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?
 Do we need a mechanism to ensure that this one is tried before any for
real hardware?

> +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  9:53 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 [this message]
2015-02-11 18:37       ` Konrad Rzeszutek Wilk
  -- 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=54DB2696.30403@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=konrad.wilk@oracle.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.