On Thu, 16 Nov 2017, Jan Kiszka wrote:

> From: Jan Kiszka <jan.kis...@siemens.com>
> 
> As the comment already stated, there is no need for setting up LDR in

I prefer to have a proper reference to documentation why this is not
needed than to a comment which is technically dubious.

> physflat mode as it remains unused. flat_init_apic_ldr only served as a
> placeholder for a nop operation so far, causing no harm.
> 
> That will change when running over the Jailhouse hypervisor. Here we
> must not touch LDR in a way that destroys the mapping originally set up
> by the Linux root cell. Jailhouse enforces this setting in order to
> efficiently validate any IPI requests sent by a cell.
> 
> Avoid a needless clash caused by flat_init_apic_ldr by installing a true
> nop handler.
> 
> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
> ---
>  arch/x86/kernel/apic/apic_flat_64.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/apic/apic_flat_64.c 
> b/arch/x86/kernel/apic/apic_flat_64.c
> index aa85690e9b64..34bfdfe29a04 100644
> --- a/arch/x86/kernel/apic/apic_flat_64.c
> +++ b/arch/x86/kernel/apic/apic_flat_64.c
> @@ -218,6 +218,11 @@ static int physflat_acpi_madt_oem_check(char *oem_id, 
> char *oem_table_id)
>       return 0;
>  }
>  
> +void physflat_init_apic_ldr(void)

static ?

> +{
> +     /* LDR is not used in physflat mode. */

flat_init_apic_ldr() also fiddles with DFR ...

> +}
> +
>  static void physflat_send_IPI_allbutself(int vector)
>  {
>       default_send_IPI_mask_allbutself_phys(cpu_online_mask, vector);
> @@ -251,8 +256,7 @@ static struct apic apic_physflat __ro_after_init = {
>       .dest_logical                   = 0,
>       .check_apicid_used              = NULL,
>  
> -     /* not needed, but shouldn't hurt: */
> -     .init_apic_ldr                  = flat_init_apic_ldr,
> +     .init_apic_ldr                  = physflat_init_apic_ldr,
>  
>       .ioapic_phys_id_map             = NULL,
>       .setup_apic_routing             = NULL,
> -- 
> 2.12.3
> 
> 

Reply via email to