Skip to content

Commit ec181b7

Browse files
committed
Merge tag 'x86-urgent-2020-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner: "Two fixes for x86: - Map EFI runtime service data as encrypted when SEV is enabled. Otherwise e.g. SMBIOS data cannot be properly decoded by dmidecode. - Remove the warning in the vector management code which triggered when a managed interrupt affinity changed outside of a CPU hotplug operation. The warning was correct until the recent core code change that introduced a CPU isolation feature which needs to migrate managed interrupts away from online CPUs under certain conditions to achieve the isolation" * tag 'x86-urgent-2020-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/vector: Remove warning on managed interrupt migration x86/ioremap: Map EFI runtime services data as encrypted for SEV
2 parents e99bc91 + 469ff20 commit ec181b7

File tree

2 files changed

+26
-6
lines changed

2 files changed

+26
-6
lines changed

arch/x86/kernel/apic/vector.c

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -838,13 +838,15 @@ static void free_moved_vector(struct apic_chip_data *apicd)
838838
bool managed = apicd->is_managed;
839839

840840
/*
841-
* This should never happen. Managed interrupts are not
842-
* migrated except on CPU down, which does not involve the
843-
* cleanup vector. But try to keep the accounting correct
844-
* nevertheless.
841+
* Managed interrupts are usually not migrated away
842+
* from an online CPU, but CPU isolation 'managed_irq'
843+
* can make that happen.
844+
* 1) Activation does not take the isolation into account
845+
* to keep the code simple
846+
* 2) Migration away from an isolated CPU can happen when
847+
* a non-isolated CPU which is in the calculated
848+
* affinity mask comes online.
845849
*/
846-
WARN_ON_ONCE(managed);
847-
848850
trace_vector_free_moved(apicd->irq, cpu, vector, managed);
849851
irq_matrix_free(vector_matrix, cpu, vector, managed);
850852
per_cpu(vector_irq, cpu)[vector] = VECTOR_UNUSED;

arch/x86/mm/ioremap.c

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -106,6 +106,19 @@ static unsigned int __ioremap_check_encrypted(struct resource *res)
106106
return 0;
107107
}
108108

109+
/*
110+
* The EFI runtime services data area is not covered by walk_mem_res(), but must
111+
* be mapped encrypted when SEV is active.
112+
*/
113+
static void __ioremap_check_other(resource_size_t addr, struct ioremap_desc *desc)
114+
{
115+
if (!sev_active())
116+
return;
117+
118+
if (efi_mem_type(addr) == EFI_RUNTIME_SERVICES_DATA)
119+
desc->flags |= IORES_MAP_ENCRYPTED;
120+
}
121+
109122
static int __ioremap_collect_map_flags(struct resource *res, void *arg)
110123
{
111124
struct ioremap_desc *desc = arg;
@@ -124,6 +137,9 @@ static int __ioremap_collect_map_flags(struct resource *res, void *arg)
124137
* To avoid multiple resource walks, this function walks resources marked as
125138
* IORESOURCE_MEM and IORESOURCE_BUSY and looking for system RAM and/or a
126139
* resource described not as IORES_DESC_NONE (e.g. IORES_DESC_ACPI_TABLES).
140+
*
141+
* After that, deal with misc other ranges in __ioremap_check_other() which do
142+
* not fall into the above category.
127143
*/
128144
static void __ioremap_check_mem(resource_size_t addr, unsigned long size,
129145
struct ioremap_desc *desc)
@@ -135,6 +151,8 @@ static void __ioremap_check_mem(resource_size_t addr, unsigned long size,
135151
memset(desc, 0, sizeof(struct ioremap_desc));
136152

137153
walk_mem_res(start, end, desc, __ioremap_collect_map_flags);
154+
155+
__ioremap_check_other(addr, desc);
138156
}
139157

140158
/*

0 commit comments

Comments
 (0)