[Xen-devel] [PATCH 5.1 279/405] block: avoid to break XEN by multi-page bvec
[ Upstream commit db5ebd6edd2627d7e81a031643cf43587f63e66c ] XEN has special page merge requirement, see xen_biovec_phys_mergeable(). We can't merge pages into one bvec simply for XEN. So move XEN's specific check on page merge into __bio_try_merge_page(), then abvoid to break XEN by multi-page bvec. Cc: ris Ostrovsky Cc: xen-devel@lists.xenproject.org Cc: Omar Sandoval Cc: Christoph Hellwig Reviewed-by: Juergen Gross Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- block/bio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/bio.c b/block/bio.c index 716510ecd7ffa..a3c80a6c1fe51 100644 --- a/block/bio.c +++ b/block/bio.c @@ -776,6 +776,8 @@ bool __bio_try_merge_page(struct bio *bio, struct page *page, if (vec_end_addr + 1 != page_addr + off) return false; + if (xen_domain() && !xen_biovec_phys_mergeable(bv, page)) + return false; if (same_page && (vec_end_addr & PAGE_MASK) != page_addr) return false; -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5.1 280/405] block: pass page to xen_biovec_phys_mergeable
[ Upstream commit 0383ad4374f7ad7edd925a2ee4753035c3f5508a ]
xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
for checking if the two bvecs can be merged, so pass page to
xen_biovec_phys_mergeable() directly.
No function change.
Cc: ris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Cc: Omar Sandoval
Cc: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
Signed-off-by: Ming Lei
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
block/blk.h| 2 +-
drivers/xen/biomerge.c | 5 +++--
include/xen/xen.h | 4 +++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/block/blk.h b/block/blk.h
index 5d636ee416630..e27fd1512e4bb 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -75,7 +75,7 @@ static inline bool biovec_phys_mergeable(struct request_queue
*q,
if (addr1 + vec1->bv_len != addr2)
return false;
- if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2))
+ if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2->bv_page))
return false;
if ((addr1 | mask) != ((addr2 + vec2->bv_len - 1) | mask))
return false;
diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
index f3fbb700f5697..05a286d24f148 100644
--- a/drivers/xen/biomerge.c
+++ b/drivers/xen/biomerge.c
@@ -4,12 +4,13 @@
#include
#include
+/* check if @page can be merged with 'vec1' */
bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
- const struct bio_vec *vec2)
+ const struct page *page)
{
#if XEN_PAGE_SIZE == PAGE_SIZE
unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page));
- unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page));
+ unsigned long bfn2 = pfn_to_bfn(page_to_pfn(page));
return bfn1 + PFN_DOWN(vec1->bv_offset + vec1->bv_len) == bfn2;
#else
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 19d032373de5a..19a72f591e2bd 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -43,8 +43,10 @@ extern struct hvm_start_info pvh_start_info;
#endif /* CONFIG_XEN_DOM0 */
struct bio_vec;
+struct page;
+
bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
- const struct bio_vec *vec2);
+ const struct page *page);
#if defined(CONFIG_MEMORY_HOTPLUG) && defined(CONFIG_XEN_BALLOON)
extern u64 xen_saved_max_mem_size;
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5.0 252/346] block: pass page to xen_biovec_phys_mergeable
[ Upstream commit 0383ad4374f7ad7edd925a2ee4753035c3f5508a ]
xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
for checking if the two bvecs can be merged, so pass page to
xen_biovec_phys_mergeable() directly.
No function change.
Cc: ris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Cc: Omar Sandoval
Cc: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
Signed-off-by: Ming Lei
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
block/blk.h| 2 +-
drivers/xen/biomerge.c | 5 +++--
include/xen/xen.h | 4 +++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/block/blk.h b/block/blk.h
index 848278c520306..a57bc90e44bb2 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -75,7 +75,7 @@ static inline bool biovec_phys_mergeable(struct request_queue
*q,
if (addr1 + vec1->bv_len != addr2)
return false;
- if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2))
+ if (xen_domain() && !xen_biovec_phys_mergeable(vec1, vec2->bv_page))
return false;
if ((addr1 | mask) != ((addr2 + vec2->bv_len - 1) | mask))
return false;
diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
index f3fbb700f5697..05a286d24f148 100644
--- a/drivers/xen/biomerge.c
+++ b/drivers/xen/biomerge.c
@@ -4,12 +4,13 @@
#include
#include
+/* check if @page can be merged with 'vec1' */
bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
- const struct bio_vec *vec2)
+ const struct page *page)
{
#if XEN_PAGE_SIZE == PAGE_SIZE
unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page));
- unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page));
+ unsigned long bfn2 = pfn_to_bfn(page_to_pfn(page));
return bfn1 + PFN_DOWN(vec1->bv_offset + vec1->bv_len) == bfn2;
#else
diff --git a/include/xen/xen.h b/include/xen/xen.h
index 0e2156786ad29..e1ba6921bc8eb 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -43,7 +43,9 @@ extern struct hvm_start_info pvh_start_info;
#endif /* CONFIG_XEN_DOM0 */
struct bio_vec;
+struct page;
+
bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
- const struct bio_vec *vec2);
+ const struct page *page);
#endif /* _XEN_XEN_H */
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 019/105] x86/dump_pagetables: Fix LDT remap address marker
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 254eb5505ca0ca749d3a491fc6668b6c16647a99 ]
The LDT remap placement has been changed. It's now placed before the direct
mapping in the kernel virtual address space for both paging modes.
Change address markers order accordingly.
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level
paging")
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Thomas Gleixner
Cc: b...@alien8.de
Cc: h...@zytor.com
Cc: dave.han...@linux.intel.com
Cc: l...@kernel.org
Cc: pet...@infradead.org
Cc: boris.ostrov...@oracle.com
Cc: jgr...@suse.com
Cc: b...@redhat.com
Cc: hans.van.kranenb...@mendix.com
Cc: linux...@kvack.org
Cc: xen-devel@lists.xenproject.org
Link:
https://lkml.kernel.org/r/20181130202328.65359-3-kirill.shute...@linux.intel.com
Signed-off-by: Sasha Levin
---
arch/x86/mm/dump_pagetables.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index cf403e057f3f..6bca45d06676 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -51,10 +51,10 @@ struct addr_marker {
enum address_markers_idx {
USER_SPACE_NR = 0,
KERNEL_SPACE_NR,
- LOW_KERNEL_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && defined(CONFIG_X86_5LEVEL)
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
LDT_NR,
#endif
+ LOW_KERNEL_NR,
VMALLOC_START_NR,
VMEMMAP_START_NR,
#ifdef CONFIG_KASAN
@@ -62,9 +62,6 @@ enum address_markers_idx {
KASAN_SHADOW_END_NR,
#endif
CPU_ENTRY_AREA_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && !defined(CONFIG_X86_5LEVEL)
- LDT_NR,
-#endif
#ifdef CONFIG_X86_ESPFIX64
ESPFIX_START_NR,
#endif
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 018/105] x86/mm: Fix guard hole handling
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 ]
There is a guard hole at the beginning of the kernel address space, also
used by hypervisors. It occupies 16 PGD entries.
This reserved range is not defined explicitely, it is calculated relative
to other entities: direct mapping and user space ranges.
The calculation got broken by recent changes of the kernel memory layout:
LDT remap range is now mapped before direct mapping and makes the
calculation invalid.
The breakage leads to crash on Xen dom0 boot[1].
Define the reserved range explicitely. It's part of kernel ABI (hypervisors
expect it to be stable) and must not depend on changes in the rest of
kernel memory layout.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level
paging")
Reported-by: Hans van Kranenburg
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Thomas Gleixner
Tested-by: Hans van Kranenburg
Reviewed-by: Juergen Gross
Cc: b...@alien8.de
Cc: h...@zytor.com
Cc: dave.han...@linux.intel.com
Cc: l...@kernel.org
Cc: pet...@infradead.org
Cc: boris.ostrov...@oracle.com
Cc: b...@redhat.com
Cc: linux...@kvack.org
Cc: xen-devel@lists.xenproject.org
Link:
https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shute...@linux.intel.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/pgtable_64_types.h | 5 +
arch/x86/mm/dump_pagetables.c | 8
arch/x86/xen/mmu_pv.c | 11 ++-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 7764617b8f9c..bf6d2692fc60 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -94,6 +94,11 @@ typedef struct { pteval_t pte; } pte_t;
# define __VMEMMAP_BASE_AC(0xea00, UL)
#endif
+#define GUARD_HOLE_PGD_ENTRY -256UL
+#define GUARD_HOLE_SIZE(16UL << PGDIR_SHIFT)
+#define GUARD_HOLE_BASE_ADDR (GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT)
+#define GUARD_HOLE_END_ADDR(GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE)
+
#define LDT_PGD_ENTRY -240UL
#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 2a4849e92831..cf403e057f3f 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -465,11 +465,11 @@ static inline bool is_hypervisor_range(int idx)
{
#ifdef CONFIG_X86_64
/*
-* 8000 - 87ff is reserved for
-* the hypervisor.
+* A hole in the beginning of kernel address space reserved
+* for a hypervisor.
*/
- return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
- (idx < pgd_index(__PAGE_OFFSET));
+ return (idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
+ (idx < pgd_index(GUARD_HOLE_END_ADDR));
#else
return false;
#endif
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index b33fa127a613..7631e6130d44 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -614,19 +614,20 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t
*pgd,
unsigned long limit)
{
int i, nr, flush = 0;
- unsigned hole_low, hole_high;
+ unsigned hole_low = 0, hole_high = 0;
/* The limit is the last byte to be touched */
limit--;
BUG_ON(limit >= FIXADDR_TOP);
+#ifdef CONFIG_X86_64
/*
* 64-bit has a great big hole in the middle of the address
-* space, which contains the Xen mappings. On 32-bit these
-* will end up making a zero-sized hole and so is a no-op.
+* space, which contains the Xen mappings.
*/
- hole_low = pgd_index(USER_LIMIT);
- hole_high = pgd_index(PAGE_OFFSET);
+ hole_low = pgd_index(GUARD_HOLE_BASE_ADDR);
+ hole_high = pgd_index(GUARD_HOLE_END_ADDR);
+#endif
nr = pgd_index(limit) + 1;
for (i = 0; i < nr; i++) {
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.19 030/148] x86/dump_pagetables: Fix LDT remap address marker
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 254eb5505ca0ca749d3a491fc6668b6c16647a99 ]
The LDT remap placement has been changed. It's now placed before the direct
mapping in the kernel virtual address space for both paging modes.
Change address markers order accordingly.
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level
paging")
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Thomas Gleixner
Cc: b...@alien8.de
Cc: h...@zytor.com
Cc: dave.han...@linux.intel.com
Cc: l...@kernel.org
Cc: pet...@infradead.org
Cc: boris.ostrov...@oracle.com
Cc: jgr...@suse.com
Cc: b...@redhat.com
Cc: hans.van.kranenb...@mendix.com
Cc: linux...@kvack.org
Cc: xen-devel@lists.xenproject.org
Link:
https://lkml.kernel.org/r/20181130202328.65359-3-kirill.shute...@linux.intel.com
Signed-off-by: Sasha Levin
---
arch/x86/mm/dump_pagetables.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 073755c89126..c05a818224bb 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -53,10 +53,10 @@ struct addr_marker {
enum address_markers_idx {
USER_SPACE_NR = 0,
KERNEL_SPACE_NR,
- LOW_KERNEL_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && defined(CONFIG_X86_5LEVEL)
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
LDT_NR,
#endif
+ LOW_KERNEL_NR,
VMALLOC_START_NR,
VMEMMAP_START_NR,
#ifdef CONFIG_KASAN
@@ -64,9 +64,6 @@ enum address_markers_idx {
KASAN_SHADOW_END_NR,
#endif
CPU_ENTRY_AREA_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && !defined(CONFIG_X86_5LEVEL)
- LDT_NR,
-#endif
#ifdef CONFIG_X86_ESPFIX64
ESPFIX_START_NR,
#endif
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.19 029/148] x86/mm: Fix guard hole handling
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 ]
There is a guard hole at the beginning of the kernel address space, also
used by hypervisors. It occupies 16 PGD entries.
This reserved range is not defined explicitely, it is calculated relative
to other entities: direct mapping and user space ranges.
The calculation got broken by recent changes of the kernel memory layout:
LDT remap range is now mapped before direct mapping and makes the
calculation invalid.
The breakage leads to crash on Xen dom0 boot[1].
Define the reserved range explicitely. It's part of kernel ABI (hypervisors
expect it to be stable) and must not depend on changes in the rest of
kernel memory layout.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level
paging")
Reported-by: Hans van Kranenburg
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Thomas Gleixner
Tested-by: Hans van Kranenburg
Reviewed-by: Juergen Gross
Cc: b...@alien8.de
Cc: h...@zytor.com
Cc: dave.han...@linux.intel.com
Cc: l...@kernel.org
Cc: pet...@infradead.org
Cc: boris.ostrov...@oracle.com
Cc: b...@redhat.com
Cc: linux...@kvack.org
Cc: xen-devel@lists.xenproject.org
Link:
https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shute...@linux.intel.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/pgtable_64_types.h | 5 +
arch/x86/mm/dump_pagetables.c | 8
arch/x86/xen/mmu_pv.c | 11 ++-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 84bd9bdc1987..88bca456da99 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -111,6 +111,11 @@ extern unsigned int ptrs_per_p4d;
*/
#define MAXMEM (1UL << MAX_PHYSMEM_BITS)
+#define GUARD_HOLE_PGD_ENTRY -256UL
+#define GUARD_HOLE_SIZE(16UL << PGDIR_SHIFT)
+#define GUARD_HOLE_BASE_ADDR (GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT)
+#define GUARD_HOLE_END_ADDR(GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE)
+
#define LDT_PGD_ENTRY -240UL
#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT)
#define LDT_END_ADDR (LDT_BASE_ADDR + PGDIR_SIZE)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index a12afff146d1..073755c89126 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -493,11 +493,11 @@ static inline bool is_hypervisor_range(int idx)
{
#ifdef CONFIG_X86_64
/*
-* 8000 - 87ff is reserved for
-* the hypervisor.
+* A hole in the beginning of kernel address space reserved
+* for a hypervisor.
*/
- return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
- (idx < pgd_index(__PAGE_OFFSET));
+ return (idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
+ (idx < pgd_index(GUARD_HOLE_END_ADDR));
#else
return false;
#endif
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2c84c6ad8b50..c8f011e07a15 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -640,19 +640,20 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t
*pgd,
unsigned long limit)
{
int i, nr, flush = 0;
- unsigned hole_low, hole_high;
+ unsigned hole_low = 0, hole_high = 0;
/* The limit is the last byte to be touched */
limit--;
BUG_ON(limit >= FIXADDR_TOP);
+#ifdef CONFIG_X86_64
/*
* 64-bit has a great big hole in the middle of the address
-* space, which contains the Xen mappings. On 32-bit these
-* will end up making a zero-sized hole and so is a no-op.
+* space, which contains the Xen mappings.
*/
- hole_low = pgd_index(USER_LIMIT);
- hole_high = pgd_index(PAGE_OFFSET);
+ hole_low = pgd_index(GUARD_HOLE_BASE_ADDR);
+ hole_high = pgd_index(GUARD_HOLE_END_ADDR);
+#endif
nr = pgd_index(limit) + 1;
for (i = 0; i < nr; i++) {
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 21/21] memblock: drop memblock_alloc_*_nopanic() variants
On Wed, Jan 16, 2019 at 03:44:21PM +0200, Mike Rapoport wrote: > As all the memblock allocation functions return NULL in case of error > rather than panic(), the duplicates with _nopanic suffix can be removed. > > Signed-off-by: Mike Rapoport > --- > arch/arc/kernel/unwind.c | 3 +-- > arch/sh/mm/init.c | 2 +- > arch/x86/kernel/setup_percpu.c | 10 +- > arch/x86/mm/kasan_init_64.c| 14 -- > drivers/firmware/memmap.c | 2 +- > drivers/usb/early/xhci-dbc.c | 2 +- > include/linux/memblock.h | 35 --- > kernel/dma/swiotlb.c | 2 +- > kernel/printk/printk.c | 17 +++-- > mm/memblock.c | 35 --- > mm/page_alloc.c| 10 +- > mm/page_ext.c | 2 +- > mm/percpu.c| 11 --- > mm/sparse.c| 6 ++ > 14 files changed, 37 insertions(+), 114 deletions(-) Acked-by: Greg Kroah-Hartman ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 6/6] x86: xen: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Cc:
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/debugfs.c | 7 +--
arch/x86/xen/p2m.c | 3 ---
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
index 13da87918b4f..532410998684 100644
--- a/arch/x86/xen/debugfs.c
+++ b/arch/x86/xen/debugfs.c
@@ -9,13 +9,8 @@ static struct dentry *d_xen_debug;
struct dentry * __init xen_init_debugfs(void)
{
- if (!d_xen_debug) {
+ if (!d_xen_debug)
d_xen_debug = debugfs_create_dir("xen", NULL);
-
- if (!d_xen_debug)
- pr_warning("Could not create 'xen' debugfs
directory\n");
- }
-
return d_xen_debug;
}
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 055e37e43541..9d3e29805b73 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -810,9 +810,6 @@ static int __init xen_p2m_debugfs(void)
{
struct dentry *d_xen = xen_init_debugfs();
- if (d_xen == NULL)
- return -ENOMEM;
-
d_mmu_debug = debugfs_create_dir("mmu", d_xen);
debugfs_create_file("p2m", 0600, d_mmu_debug, NULL, &p2m_dump_fops);
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.20 083/117] x86/entry/64/compat: Fix stack switching for XEN PV
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Beulich
commit fc24d75a7f91837d7918e40719575951820b2b8f upstream.
While in the native case entry into the kernel happens on the trampoline
stack, PV Xen kernels get entered with the current thread stack right
away. Hence source and destination stacks are identical in that case,
and special care is needed.
Other than in sync_regs() the copying done on the INT80 path isn't
NMI / #MC safe, as either of these events occurring in the middle of the
stack copying would clobber data on the (source) stack.
There is similar code in interrupt_entry() and nmi(), but there is no fixup
required because those code paths are unreachable in XEN PV guests.
[ tglx: Sanitized subject, changelog, Fixes tag and stable mail address. Sigh ]
Fixes: 7f2590a110b8 ("x86/entry/64: Use a per-CPU trampoline stack for IDT
entries")
Signed-off-by: Jan Beulich
Signed-off-by: Thomas Gleixner
Reviewed-by: Juergen Gross
Acked-by: Andy Lutomirski
Cc: Peter Anvin
Cc: xen-devel@lists.xenproject.org>
Cc: Boris Ostrovsky
Cc: sta...@vger.kernel.org
Link:
https://lkml.kernel.org/r/5c3e112802780020d...@prv1-mh.provo.novell.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/entry_64_compat.S |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -361,7 +361,8 @@ ENTRY(entry_INT80_compat)
/* Need to switch before accessing the thread stack. */
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
- movq%rsp, %rdi
+ /* In the Xen PV case we already run on the thread stack. */
+ ALTERNATIVE "movq %rsp, %rdi", "jmp .Lint80_keep_stack",
X86_FEATURE_XENPV
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
pushq 6*8(%rdi) /* regs->ss */
@@ -370,8 +371,9 @@ ENTRY(entry_INT80_compat)
pushq 3*8(%rdi) /* regs->cs */
pushq 2*8(%rdi) /* regs->ip */
pushq 1*8(%rdi) /* regs->orig_ax */
-
pushq (%rdi) /* pt_regs->di */
+.Lint80_keep_stack:
+
pushq %rsi/* pt_regs->si */
xorl%esi, %esi /* nospec si */
pushq %rdx/* pt_regs->dx */
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.19 075/103] x86/entry/64/compat: Fix stack switching for XEN PV
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Beulich
commit fc24d75a7f91837d7918e40719575951820b2b8f upstream.
While in the native case entry into the kernel happens on the trampoline
stack, PV Xen kernels get entered with the current thread stack right
away. Hence source and destination stacks are identical in that case,
and special care is needed.
Other than in sync_regs() the copying done on the INT80 path isn't
NMI / #MC safe, as either of these events occurring in the middle of the
stack copying would clobber data on the (source) stack.
There is similar code in interrupt_entry() and nmi(), but there is no fixup
required because those code paths are unreachable in XEN PV guests.
[ tglx: Sanitized subject, changelog, Fixes tag and stable mail address. Sigh ]
Fixes: 7f2590a110b8 ("x86/entry/64: Use a per-CPU trampoline stack for IDT
entries")
Signed-off-by: Jan Beulich
Signed-off-by: Thomas Gleixner
Reviewed-by: Juergen Gross
Acked-by: Andy Lutomirski
Cc: Peter Anvin
Cc: xen-devel@lists.xenproject.org>
Cc: Boris Ostrovsky
Cc: sta...@vger.kernel.org
Link:
https://lkml.kernel.org/r/5c3e112802780020d...@prv1-mh.provo.novell.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/entry_64_compat.S |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -356,7 +356,8 @@ ENTRY(entry_INT80_compat)
/* Need to switch before accessing the thread stack. */
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
- movq%rsp, %rdi
+ /* In the Xen PV case we already run on the thread stack. */
+ ALTERNATIVE "movq %rsp, %rdi", "jmp .Lint80_keep_stack",
X86_FEATURE_XENPV
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
pushq 6*8(%rdi) /* regs->ss */
@@ -365,8 +366,9 @@ ENTRY(entry_INT80_compat)
pushq 3*8(%rdi) /* regs->cs */
pushq 2*8(%rdi) /* regs->ip */
pushq 1*8(%rdi) /* regs->orig_ax */
-
pushq (%rdi) /* pt_regs->di */
+.Lint80_keep_stack:
+
pushq %rsi/* pt_regs->si */
xorl%esi, %esi /* nospec si */
pushq %rdx/* pt_regs->dx */
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/34] staging/vc04_services: convert put_page() to put_user_page*()
On Thu, Aug 01, 2019 at 07:19:46PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Eric Anholt
> Cc: Stefan Wahren
> Cc: Greg Kroah-Hartman
> Cc: Mihaela Muraru
> Cc: Suniel Mahesh
> Cc: Al Viro
> Cc: Sidong Yang
> Cc: Kishore KP
> Cc: linux-rpi-ker...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: John Hubbard
> ---
> .../vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 10 ++----
> 1 file changed, 2 insertions(+), 8 deletions(-)
Acked-by: Greg Kroah-Hartman
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 10/34] genwqe: convert put_page() to put_user_page*()
On Thu, Aug 01, 2019 at 07:19:41PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> This changes the release code slightly, because each page slot in the
> page_list[] array is no longer checked for NULL. However, that check
> was wrong anyway, because the get_user_pages() pattern of usage here
> never allowed for NULL entries within a range of pinned pages.
>
> Cc: Frank Haverkamp
> Cc: "Guilherme G. Piccoli"
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Signed-off-by: John Hubbard
> ---
> drivers/misc/genwqe/card_utils.c | 17 +++------
> 1 file changed, 3 insertions(+), 14 deletions(-)
Acked-by: Greg Kroah-Hartman
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen-netback: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Wei Liu
Cc: Paul Durrant
Cc: xen-devel@lists.xenproject.org
Cc: net...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netback/netback.c | 3 --
drivers/net/xen-netback/xenbus.c | 46 ---
2 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 1d9940d4e8c7..e018932abf49 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1653,9 +1653,6 @@ static int __init netback_init(void)
#ifdef CONFIG_DEBUG_FS
xen_netback_dbg_root = debugfs_create_dir("xen-netback", NULL);
- if (IS_ERR_OR_NULL(xen_netback_dbg_root))
- pr_warn("Init of debugfs returned %ld!\n",
- PTR_ERR(xen_netback_dbg_root));
#endif /* CONFIG_DEBUG_FS */
return 0;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 41034264bd34..f533b7372d59 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -170,50 +170,26 @@ DEFINE_SHOW_ATTRIBUTE(xenvif_ctrl);
static void xenvif_debugfs_addif(struct xenvif *vif)
{
- struct dentry *pfile;
int i;
- if (IS_ERR_OR_NULL(xen_netback_dbg_root))
- return;
-
vif->xenvif_dbg_root = debugfs_create_dir(vif->dev->name,
xen_netback_dbg_root);
- if (!IS_ERR_OR_NULL(vif->xenvif_dbg_root)) {
- for (i = 0; i < vif->num_queues; ++i) {
- char filename[sizeof("io_ring_q") + 4];
-
- snprintf(filename, sizeof(filename), "io_ring_q%d", i);
- pfile = debugfs_create_file(filename,
- 0600,
- vif->xenvif_dbg_root,
- &vif->queues[i],
-
&xenvif_dbg_io_ring_ops_fops);
- if (IS_ERR_OR_NULL(pfile))
- pr_warn("Creation of io_ring file returned
%ld!\n",
- PTR_ERR(pfile));
- }
+ for (i = 0; i < vif->num_queues; ++i) {
+ char filename[sizeof("io_ring_q") + 4];
- if (vif->ctrl_irq) {
- pfile = debugfs_create_file("ctrl",
- 0400,
- vif->xenvif_dbg_root,
- vif,
- &xenvif_ctrl_fops);
- if (IS_ERR_OR_NULL(pfile))
- pr_warn("Creation of ctrl file returned %ld!\n",
- PTR_ERR(pfile));
- }
- } else
- netdev_warn(vif->dev,
- "Creation of vif debugfs dir returned %ld!\n",
- PTR_ERR(vif->xenvif_dbg_root));
+ snprintf(filename, sizeof(filename), "io_ring_q%d", i);
+ debugfs_create_file(filename, 0600, vif->xenvif_dbg_root,
+ &vif->queues[i],
+ &xenvif_dbg_io_ring_ops_fops);
+ }
+
+ if (vif->ctrl_irq)
+ debugfs_create_file("ctrl", 0400, vif->xenvif_dbg_root, vif,
+ &xenvif_ctrl_fops);
}
static void xenvif_debugfs_delif(struct xenvif *vif)
{
- if (IS_ERR_OR_NULL(xen_netback_dbg_root))
- return;
-
debugfs_remove_recursive(vif->xenvif_dbg_root);
vif->xenvif_dbg_root = NULL;
}
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.19 054/152] pvcalls-front: Avoid get_free_pages(GFP_KERNEL) under spinlock
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The allocation is not allowed to sleep and
GFP_KERNEL is not sufficient.
This issue was detected by using the Coccinelle software.
v2: Add a function doing the allocations which is called
outside the lock and passing the allocated data to
create_active().
v3: Use the matching deallocators i.e., free_page()
and free_pages(), respectively.
v4: It would be better to pre-populate map (struct sock_mapping),
rather than introducing one more new struct.
v5: Since allocating the data outside of this call it should also
be freed outside, when create_active() fails.
Move kzalloc(sizeof(*map2), GFP_ATOMIC) outside spinlock and
use GFP_KERNEL instead.
v6: Drop the superfluous calls.
Suggested-by: Juergen Gross
Suggested-by: Boris Ostrovsky
Suggested-by: Stefano Stabellini
Signed-off-by: Wen Yang
Acked-by: Stefano Stabellini
CC: Julia Lawall
CC: Boris Ostrovsky
CC: Juergen Gross
CC: Stefano Stabellini
CC: xen-devel@lists.xenproject.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Boris Ostrovsky
Signed-off-by: Sasha Levin
---
drivers/xen/pvcalls-front.c | 81 +++--
1 file changed, 59 insertions(+), 22 deletions(-)
diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 01588582ae663..6357160d466ab 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -341,6 +341,39 @@ int pvcalls_front_socket(struct socket *sock)
return ret;
}
+static void free_active_ring(struct sock_mapping *map)
+{
+ free_pages((unsigned long)map->active.data.in,
+ map->active.ring->ring_order);
+ free_page((unsigned long)map->active.ring);
+}
+
+static int alloc_active_ring(struct sock_mapping *map)
+{
+ void *bytes;
+
+ map->active.ring = (struct pvcalls_data_intf *)
+ get_zeroed_page(GFP_KERNEL);
+ if (!map->active.ring)
+ goto out;
+
+ map->active.ring->ring_order = PVCALLS_RING_ORDER;
+ bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
+ PVCALLS_RING_ORDER);
+ if (!bytes)
+ goto out;
+
+ map->active.data.in = bytes;
+ map->active.data.out = bytes +
+ XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
+
+ return 0;
+
+out:
+ free_active_ring(map);
+ return -ENOMEM;
+}
+
static int create_active(struct sock_mapping *map, int *evtchn)
{
void *bytes;
@@ -349,15 +382,7 @@ static int create_active(struct sock_mapping *map, int
*evtchn)
*evtchn = -1;
init_waitqueue_head(&map->active.inflight_conn_req);
- map->active.ring = (struct pvcalls_data_intf *)
- __get_free_page(GFP_KERNEL | __GFP_ZERO);
- if (map->active.ring == NULL)
- goto out_error;
- map->active.ring->ring_order = PVCALLS_RING_ORDER;
- bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
- PVCALLS_RING_ORDER);
- if (bytes == NULL)
- goto out_error;
+ bytes = map->active.data.in;
for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
map->active.ring->ref[i] = gnttab_grant_foreign_access(
pvcalls_front_dev->otherend_id,
@@ -367,10 +392,6 @@ static int create_active(struct sock_mapping *map, int
*evtchn)
pvcalls_front_dev->otherend_id,
pfn_to_gfn(virt_to_pfn((void *)map->active.ring)), 0);
- map->active.data.in = bytes;
- map->active.data.out = bytes +
- XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
-
ret = xenbus_alloc_evtchn(pvcalls_front_dev, evtchn);
if (ret)
goto out_error;
@@ -391,8 +412,6 @@ static int create_active(struct sock_mapping *map, int
*evtchn)
out_error:
if (*evtchn >= 0)
xenbus_free_evtchn(pvcalls_front_dev, *evtchn);
- free_pages((unsigned long)map->active.data.in, PVCALLS_RING_ORDER);
- free_page((unsigned long)map->active.ring);
return ret;
}
@@ -412,17 +431,24 @@ int pvcalls_front_connect(struct socket *sock, struct
sockaddr *addr,
return PTR_ERR(map);
bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
+ ret = alloc_active_ring(map);
+ if (ret < 0) {
+ pvcalls_exit_sock(sock);
+ return ret;
+ }
spin_lock(&bedata->socket_lock);
ret = get_request(bedata, &req_id);
if (ret < 0) {
[Xen-devel] [PATCH 4.19 078/152] pvcalls-front: fix potential null dereference
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could be null
(see line 357)
drivers/xen/pvcalls-front.c
351 static int alloc_active_ring(struct sock_mapping *map)
352 {
353 void *bytes;
354
355 map->active.ring = (struct pvcalls_data_intf *)
356 get_zeroed_page(GFP_KERNEL);
357 if (!map->active.ring)
^
Check
358 goto out;
359
360 map->active.ring->ring_order = PVCALLS_RING_ORDER;
361 bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
362 PVCALLS_RING_ORDER);
363 if (!bytes)
364 goto out;
365
366 map->active.data.in = bytes;
367 map->active.data.out = bytes +
368 XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
369
370 return 0;
371
372 out:
--> 373 free_active_ring(map);
^^^
Add null check on map->active.ring before dereferencing it to avoid
any NULL pointer dereferences.
Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL) under
spinlock")
Reported-by: Dan Carpenter
Suggested-by: Boris Ostrovsky
Signed-off-by: Wen Yang
Reviewed-by: Boris Ostrovsky
CC: Boris Ostrovsky
CC: Juergen Gross
CC: Stefano Stabellini
CC: Dan Carpenter
CC: xen-devel@lists.xenproject.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Boris Ostrovsky
Signed-off-by: Sasha Levin
---
drivers/xen/pvcalls-front.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 6357160d466ab..91da7e44d5d4f 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -343,6 +343,9 @@ int pvcalls_front_socket(struct socket *sock)
static void free_active_ring(struct sock_mapping *map)
{
+ if (!map->active.ring)
+ return;
+
free_pages((unsigned long)map->active.data.in,
map->active.ring->ring_order);
free_page((unsigned long)map->active.ring);
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.20 096/183] pvcalls-front: fix potential null dereference
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could be null
(see line 357)
drivers/xen/pvcalls-front.c
351 static int alloc_active_ring(struct sock_mapping *map)
352 {
353 void *bytes;
354
355 map->active.ring = (struct pvcalls_data_intf *)
356 get_zeroed_page(GFP_KERNEL);
357 if (!map->active.ring)
^
Check
358 goto out;
359
360 map->active.ring->ring_order = PVCALLS_RING_ORDER;
361 bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
362 PVCALLS_RING_ORDER);
363 if (!bytes)
364 goto out;
365
366 map->active.data.in = bytes;
367 map->active.data.out = bytes +
368 XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
369
370 return 0;
371
372 out:
--> 373 free_active_ring(map);
^^^
Add null check on map->active.ring before dereferencing it to avoid
any NULL pointer dereferences.
Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL) under
spinlock")
Reported-by: Dan Carpenter
Suggested-by: Boris Ostrovsky
Signed-off-by: Wen Yang
Reviewed-by: Boris Ostrovsky
CC: Boris Ostrovsky
CC: Juergen Gross
CC: Stefano Stabellini
CC: Dan Carpenter
CC: xen-devel@lists.xenproject.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Boris Ostrovsky
Signed-off-by: Sasha Levin
---
drivers/xen/pvcalls-front.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 6357160d466ab..91da7e44d5d4f 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -343,6 +343,9 @@ int pvcalls_front_socket(struct socket *sock)
static void free_active_ring(struct sock_mapping *map)
{
+ if (!map->active.ring)
+ return;
+
free_pages((unsigned long)map->active.data.in,
map->active.ring->ring_order);
free_page((unsigned long)map->active.ring);
--
2.19.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.20 063/183] pvcalls-front: Avoid get_free_pages(GFP_KERNEL) under spinlock
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The allocation is not allowed to sleep and
GFP_KERNEL is not sufficient.
This issue was detected by using the Coccinelle software.
v2: Add a function doing the allocations which is called
outside the lock and passing the allocated data to
create_active().
v3: Use the matching deallocators i.e., free_page()
and free_pages(), respectively.
v4: It would be better to pre-populate map (struct sock_mapping),
rather than introducing one more new struct.
v5: Since allocating the data outside of this call it should also
be freed outside, when create_active() fails.
Move kzalloc(sizeof(*map2), GFP_ATOMIC) outside spinlock and
use GFP_KERNEL instead.
v6: Drop the superfluous calls.
Suggested-by: Juergen Gross
Suggested-by: Boris Ostrovsky
Suggested-by: Stefano Stabellini
Signed-off-by: Wen Yang
Acked-by: Stefano Stabellini
CC: Julia Lawall
CC: Boris Ostrovsky
CC: Juergen Gross
CC: Stefano Stabellini
CC: xen-devel@lists.xenproject.org
CC: linux-ker...@vger.kernel.org
Signed-off-by: Boris Ostrovsky
Signed-off-by: Sasha Levin
---
drivers/xen/pvcalls-front.c | 81 +++--
1 file changed, 59 insertions(+), 22 deletions(-)
diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 01588582ae663..6357160d466ab 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -341,6 +341,39 @@ int pvcalls_front_socket(struct socket *sock)
return ret;
}
+static void free_active_ring(struct sock_mapping *map)
+{
+ free_pages((unsigned long)map->active.data.in,
+ map->active.ring->ring_order);
+ free_page((unsigned long)map->active.ring);
+}
+
+static int alloc_active_ring(struct sock_mapping *map)
+{
+ void *bytes;
+
+ map->active.ring = (struct pvcalls_data_intf *)
+ get_zeroed_page(GFP_KERNEL);
+ if (!map->active.ring)
+ goto out;
+
+ map->active.ring->ring_order = PVCALLS_RING_ORDER;
+ bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
+ PVCALLS_RING_ORDER);
+ if (!bytes)
+ goto out;
+
+ map->active.data.in = bytes;
+ map->active.data.out = bytes +
+ XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
+
+ return 0;
+
+out:
+ free_active_ring(map);
+ return -ENOMEM;
+}
+
static int create_active(struct sock_mapping *map, int *evtchn)
{
void *bytes;
@@ -349,15 +382,7 @@ static int create_active(struct sock_mapping *map, int
*evtchn)
*evtchn = -1;
init_waitqueue_head(&map->active.inflight_conn_req);
- map->active.ring = (struct pvcalls_data_intf *)
- __get_free_page(GFP_KERNEL | __GFP_ZERO);
- if (map->active.ring == NULL)
- goto out_error;
- map->active.ring->ring_order = PVCALLS_RING_ORDER;
- bytes = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
- PVCALLS_RING_ORDER);
- if (bytes == NULL)
- goto out_error;
+ bytes = map->active.data.in;
for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
map->active.ring->ref[i] = gnttab_grant_foreign_access(
pvcalls_front_dev->otherend_id,
@@ -367,10 +392,6 @@ static int create_active(struct sock_mapping *map, int
*evtchn)
pvcalls_front_dev->otherend_id,
pfn_to_gfn(virt_to_pfn((void *)map->active.ring)), 0);
- map->active.data.in = bytes;
- map->active.data.out = bytes +
- XEN_FLEX_RING_SIZE(PVCALLS_RING_ORDER);
-
ret = xenbus_alloc_evtchn(pvcalls_front_dev, evtchn);
if (ret)
goto out_error;
@@ -391,8 +412,6 @@ static int create_active(struct sock_mapping *map, int
*evtchn)
out_error:
if (*evtchn >= 0)
xenbus_free_evtchn(pvcalls_front_dev, *evtchn);
- free_pages((unsigned long)map->active.data.in, PVCALLS_RING_ORDER);
- free_page((unsigned long)map->active.ring);
return ret;
}
@@ -412,17 +431,24 @@ int pvcalls_front_connect(struct socket *sock, struct
sockaddr *addr,
return PTR_ERR(map);
bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
+ ret = alloc_active_ring(map);
+ if (ret < 0) {
+ pvcalls_exit_sock(sock);
+ return ret;
+ }
spin_lock(&bedata->socket_lock);
ret = get_request(bedata, &req_id);
if (ret < 0) {
[Xen-devel] [PATCH 4.19 135/219] xen/gntdev: Use select for DMA_SHARED_BUFFER
From: Jason Gunthorpe
[ Upstream commit fa6614d8ef13c63aac52ad7c07c5e69ce4aba3dd ]
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
Cc: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Cc: Stefano Stabellini
Reviewed-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Signed-off-by: Jason Gunthorpe
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 90d387b50ab7..0505eeb593b5 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -158,7 +158,8 @@ config XEN_GNTDEV
config XEN_GNTDEV_DMABUF
bool "Add support for dma-buf grant access device driver extension"
- depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC
+ select DMA_SHARED_BUFFER
help
Allows userspace processes and kernel modules to use Xen backed
dma-buf implementation. With this extension grant references to
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5.4 259/434] xen/gntdev: Use select for DMA_SHARED_BUFFER
From: Jason Gunthorpe
[ Upstream commit fa6614d8ef13c63aac52ad7c07c5e69ce4aba3dd ]
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
Cc: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Cc: Stefano Stabellini
Reviewed-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Signed-off-by: Jason Gunthorpe
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 79cc75096f42..a50dadd01093 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -141,7 +141,8 @@ config XEN_GNTDEV
config XEN_GNTDEV_DMABUF
bool "Add support for dma-buf grant access device driver extension"
- depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER
+ depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC
+ select DMA_SHARED_BUFFER
help
Allows userspace processes and kernel modules to use Xen backed
dma-buf implementation. With this extension grant references to
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.4 29/86] x86/entry/64: Remove %ebx handling from error_entry/exit
4.4-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b3681dd548d06deb2e1573890829dff4b15abf46 ]
error_entry and error_exit communicate the user vs. kernel status of
the frame using %ebx. This is unnecessary -- the information is in
regs->cs. Just use regs->cs.
This makes error_entry simpler and makes error_exit more robust.
It also fixes a nasty bug. Before all the Spectre nonsense, the
xen_failsafe_callback entry point returned like this:
ALLOC_PT_GPREGS_ON_STACK
SAVE_C_REGS
SAVE_EXTRA_REGS
ENCODE_FRAME_POINTER
jmp error_exit
And it did not go through error_entry. This was bogus: RBX
contained garbage, and error_exit expected a flag in RBX.
Fortunately, it generally contained *nonzero* garbage, so the
correct code path was used. As part of the Spectre fixes, code was
added to clear RBX to mitigate certain speculation attacks. Now,
depending on kernel configuration, RBX got zeroed and, when running
some Wine workloads, the kernel crashes. This was introduced by:
commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
exceptions/interrupts, to reduce speculation attack surface")
With this patch applied, RBX is no longer needed as a flag, and the
problem goes away.
I suspect that malicious userspace could use this bug to crash the
kernel even without the offending patch applied, though.
[ Historical note: I wrote this patch as a cleanup before I was aware
of the bug it fixed. ]
[ Note to stable maintainers: this should probably get applied to all
kernels. If you're nervous about that, a more conservative fix to
add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should
also fix the problem. ]
Reported-and-tested-by: M. Vefa Bicakci
Signed-off-by: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Dominik Brodowski
Cc: Greg KH
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts,
to reduce speculation attack surface")
Link:
http://lkml.kernel.org/r/b5010a090d3586b2d6e06c7ad3ec5542d1241c45.1532282627.git.l...@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
---
arch/x86/entry/entry_64.S | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index b569b46660fc..375ed605c83d 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -856,7 +856,7 @@ ENTRY(\sym)
call\do_sym
- jmp error_exit /* %ebx: no swapgs flag */
+ jmp error_exit
.endif
END(\sym)
.endm
@@ -1118,7 +1118,6 @@ END(paranoid_exit)
/*
* Save all registers in pt_regs, and switch gs if needed.
- * Return: EBX=0: came from user mode; EBX=1: otherwise
*/
ENTRY(error_entry)
cld
@@ -1131,7 +1130,6 @@ ENTRY(error_entry)
* the kernel CR3 here.
*/
SWITCH_KERNEL_CR3
- xorl%ebx, %ebx
testb $3, CS+8(%rsp)
jz .Lerror_kernelspace
@@ -1165,7 +1163,6 @@ ENTRY(error_entry)
* for these here too.
*/
.Lerror_kernelspace:
- incl%ebx
leaqnative_irq_return_iret(%rip), %rcx
cmpq%rcx, RIP+8(%rsp)
je .Lerror_bad_iret
@@ -1196,28 +1193,19 @@ ENTRY(error_entry)
/*
* Pretend that the exception came from user mode: set up pt_regs
-* as if we faulted immediately after IRET and clear EBX so that
-* error_exit knows that we will be returning to user mode.
+* as if we faulted immediately after IRET.
*/
mov %rsp, %rdi
callfixup_bad_iret
mov %rax, %rsp
- decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
END(error_entry)
-
-/*
- * On entry, EBX is a "return to kernel mode" flag:
- * 1: already in kernel mode, don't need SWAPGS
- * 0: user gsbase is loaded, we need SWAPGS and standard preparation for
return to usermode
- */
ENTRY(error_exit)
- movl%ebx, %eax
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
- testl %eax, %eax
- jnz retint_kernel
+ testb $3, CS(%rsp)
+ jz retint_kernel
jmp retint_user
END(error_exit)
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.15 036/122] x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream.
Older Xen versions (4.5 and before) might have problems migrating pv
guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
suspending zero that MSR and restore it after being resumed.
Signed-off-by: Juergen Gross
Signed-off-by: Thomas Gleixner
Reviewed-by: Jan Beulich
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20180226140818.4849-1-jgr...@suse.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/suspend.c | 16
1 file changed, 16 insertions(+)
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -1,12 +1,15 @@
// SPDX-License-Identifier: GPL-2.0
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -15,6 +18,8 @@
#include "mmu.h"
#include "pmu.h"
+static DEFINE_PER_CPU(u64, spec_ctrl);
+
void xen_arch_pre_suspend(void)
{
xen_save_time_memory_area();
@@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled
static void xen_vcpu_notify_restore(void *data)
{
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
+ wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
+
/* Boot processor notified via generic timekeeping_resume() */
if (smp_processor_id() == 0)
return;
@@ -44,7 +52,15 @@ static void xen_vcpu_notify_restore(void
static void xen_vcpu_notify_suspend(void *data)
{
+ u64 tmp;
+
tick_suspend_local();
+
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
+ rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
+ this_cpu_write(spec_ctrl, tmp);
+ wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+ }
}
void xen_arch_resume(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 031/110] x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream.
Older Xen versions (4.5 and before) might have problems migrating pv
guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
suspending zero that MSR and restore it after being resumed.
Signed-off-by: Juergen Gross
Signed-off-by: Thomas Gleixner
Reviewed-by: Jan Beulich
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20180226140818.4849-1-jgr...@suse.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/suspend.c | 16
1 file changed, 16 insertions(+)
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -1,12 +1,15 @@
// SPDX-License-Identifier: GPL-2.0
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -15,6 +18,8 @@
#include "mmu.h"
#include "pmu.h"
+static DEFINE_PER_CPU(u64, spec_ctrl);
+
void xen_arch_pre_suspend(void)
{
if (xen_pv_domain())
@@ -31,6 +36,9 @@ void xen_arch_post_suspend(int cancelled
static void xen_vcpu_notify_restore(void *data)
{
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
+ wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
+
/* Boot processor notified via generic timekeeping_resume() */
if (smp_processor_id() == 0)
return;
@@ -40,7 +48,15 @@ static void xen_vcpu_notify_restore(void
static void xen_vcpu_notify_suspend(void *data)
{
+ u64 tmp;
+
tick_suspend_local();
+
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
+ rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
+ this_cpu_write(spec_ctrl, tmp);
+ wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+ }
}
void xen_arch_resume(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.9 15/65] x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream.
Older Xen versions (4.5 and before) might have problems migrating pv
guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
suspending zero that MSR and restore it after being resumed.
Signed-off-by: Juergen Gross
Signed-off-by: Thomas Gleixner
Reviewed-by: Jan Beulich
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20180226140818.4849-1-jgr...@suse.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/suspend.c | 16
1 file changed, 16 insertions(+)
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -1,11 +1,14 @@
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -68,6 +71,8 @@ static void xen_pv_post_suspend(int susp
xen_mm_unpin_all();
}
+static DEFINE_PER_CPU(u64, spec_ctrl);
+
void xen_arch_pre_suspend(void)
{
if (xen_pv_domain())
@@ -84,6 +89,9 @@ void xen_arch_post_suspend(int cancelled
static void xen_vcpu_notify_restore(void *data)
{
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
+ wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
+
/* Boot processor notified via generic timekeeping_resume() */
if (smp_processor_id() == 0)
return;
@@ -93,7 +101,15 @@ static void xen_vcpu_notify_restore(void
static void xen_vcpu_notify_suspend(void *data)
{
+ u64 tmp;
+
tick_suspend_local();
+
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
+ rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
+ this_cpu_write(spec_ctrl, tmp);
+ wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+ }
}
void xen_arch_resume(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.15 123/146] x86/xen: Calculate __max_logical_packages on PV domains
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Prarit Bhargava
commit 63e708f826bb21470155d37b103a75d8a9e25b18 upstream.
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava
Tested-and-reported-by: Simon Gaiser
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Dou Liyang
Cc: Prarit Bhargava
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: Andy Lutomirski
Cc: Andi Kleen
Cc: Vitaly Kuznetsov
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/smp.h |1 +
arch/x86/kernel/smpboot.c | 10 --
arch/x86/xen/smp.c |2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -129,6 +129,7 @@ static inline void arch_send_call_functi
void cpu_disable_common(void);
void native_smp_prepare_boot_cpu(void);
void native_smp_prepare_cpus(unsigned int max_cpus);
+void calculate_max_logical_packages(void);
void native_smp_cpus_done(unsigned int max_cpus);
void common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1282,11 +1282,10 @@ void __init native_smp_prepare_boot_cpu(
cpu_set_state_online(me);
}
-void __init native_smp_cpus_done(unsigned int max_cpus)
+void __init calculate_max_logical_packages(void)
{
int ncpus;
- pr_debug("Boot done\n");
/*
* Today neither Intel nor AMD support heterogenous systems so
* extrapolate the boot cpu's data to all packages.
@@ -1294,6 +1293,13 @@ void __init native_smp_cpus_done(unsigne
ncpus = cpu_data(0).booted_cores * topology_max_smt_threads();
__max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
pr_info("Max logical packages: %u\n", __max_logical_packages);
+}
+
+void __init native_smp_cpus_done(unsigned int max_cpus)
+{
+ pr_debug("Boot done\n");
+
+ calculate_max_logical_packages();
if (x86_has_numa_in_package)
set_sched_topology(x86_numa_in_package_topology);
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -122,6 +122,8 @@ void __init xen_smp_cpus_done(unsigned i
if (xen_hvm_domain())
native_smp_cpus_done(max_cpus);
+ else
+ calculate_max_logical_packages();
if (xen_have_vcpu_info_placement)
return;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 002/157] x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 74899d92e3dc7671a8017b3146dcd4735f3b upstream.
Commit:
1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
... added speculative_store_bypass_ht_init() to the per-CPU initialization
sequence.
speculative_store_bypass_ht_init() needs to be called on each CPU for
PV guests, too.
Reported-by: Brian Woods
Tested-by: Brian Woods
Signed-off-by: Juergen Gross
Cc:
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: boris.ostrov...@oracle.com
Cc: xen-devel@lists.xenproject.org
Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT
correctly on AMD")
Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/smp_pv.c |5 +
1 file changed, 5 insertions(+)
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
@@ -70,6 +71,8 @@ static void cpu_bringup(void)
cpu_data(cpu).x86_max_cores = 1;
set_cpu_sibling_map(cpu);
+ speculative_store_bypass_ht_init();
+
xen_setup_cpu_clockevents();
notify_cpu_starting(cpu);
@@ -250,6 +253,8 @@ static void __init xen_pv_smp_prepare_cp
}
set_cpu_sibling_map(0);
+ speculative_store_bypass_ht_init();
+
xen_pmu_init(0);
if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.17 002/220] x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 74899d92e3dc7671a8017b3146dcd4735f3b upstream.
Commit:
1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
... added speculative_store_bypass_ht_init() to the per-CPU initialization
sequence.
speculative_store_bypass_ht_init() needs to be called on each CPU for
PV guests, too.
Reported-by: Brian Woods
Tested-by: Brian Woods
Signed-off-by: Juergen Gross
Cc:
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: boris.ostrov...@oracle.com
Cc: xen-devel@lists.xenproject.org
Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT
correctly on AMD")
Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/smp_pv.c |5 +
1 file changed, 5 insertions(+)
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
@@ -70,6 +71,8 @@ static void cpu_bringup(void)
cpu_data(cpu).x86_max_cores = 1;
set_cpu_sibling_map(cpu);
+ speculative_store_bypass_ht_init();
+
xen_setup_cpu_clockevents();
notify_cpu_starting(cpu);
@@ -250,6 +253,8 @@ static void __init xen_pv_smp_prepare_cp
}
set_cpu_sibling_map(0);
+ speculative_store_bypass_ht_init();
+
xen_pmu_init(0);
if (xen_smp_intr_init(0) || xen_smp_intr_init_pv(0))
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.9 17/52] x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 74899d92e3dc7671a8017b3146dcd4735f3b upstream.
Commit:
1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
... added speculative_store_bypass_ht_init() to the per-CPU initialization
sequence.
speculative_store_bypass_ht_init() needs to be called on each CPU for
PV guests, too.
Reported-by: Brian Woods
Tested-by: Brian Woods
Signed-off-by: Juergen Gross
Cc:
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: boris.ostrov...@oracle.com
Cc: xen-devel@lists.xenproject.org
Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT
correctly on AMD")
Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/smp.c |5 +
1 file changed, 5 insertions(+)
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -87,6 +88,8 @@ static void cpu_bringup(void)
cpu_data(cpu).x86_max_cores = 1;
set_cpu_sibling_map(cpu);
+ speculative_store_bypass_ht_init();
+
xen_setup_cpu_clockevents();
notify_cpu_starting(cpu);
@@ -375,6 +378,8 @@ static void __init xen_smp_prepare_cpus(
}
set_cpu_sibling_map(0);
+ speculative_store_bypass_ht_init();
+
xen_pmu_init(0);
if (xen_smp_intr_init(0))
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.4 036/107] x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream.
Older Xen versions (4.5 and before) might have problems migrating pv
guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
suspending zero that MSR and restore it after being resumed.
Signed-off-by: Juergen Gross
Signed-off-by: Thomas Gleixner
Reviewed-by: Jan Beulich
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20180226140818.4849-1-jgr...@suse.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Srivatsa S. Bhat
Reviewed-by: Matt Helsley (VMware)
Reviewed-by: Alexey Makhalov
Reviewed-by: Bo Gan
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/suspend.c | 16
1 file changed, 16 insertions(+)
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -1,11 +1,14 @@
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -68,6 +71,8 @@ static void xen_pv_post_suspend(int susp
xen_mm_unpin_all();
}
+static DEFINE_PER_CPU(u64, spec_ctrl);
+
void xen_arch_pre_suspend(void)
{
if (xen_pv_domain())
@@ -84,6 +89,9 @@ void xen_arch_post_suspend(int cancelled
static void xen_vcpu_notify_restore(void *data)
{
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
+ wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
+
/* Boot processor notified via generic timekeeping_resume() */
if (smp_processor_id() == 0)
return;
@@ -93,7 +101,15 @@ static void xen_vcpu_notify_restore(void
static void xen_vcpu_notify_suspend(void *data)
{
+ u64 tmp;
+
tick_suspend_local();
+
+ if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
+ rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
+ this_cpu_write(spec_ctrl, tmp);
+ wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+ }
}
void xen_arch_resume(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.4 098/107] x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 74899d92e3dc7671a8017b3146dcd4735f3b upstream.
Commit:
1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
... added speculative_store_bypass_ht_init() to the per-CPU initialization
sequence.
speculative_store_bypass_ht_init() needs to be called on each CPU for
PV guests, too.
Reported-by: Brian Woods
Tested-by: Brian Woods
Signed-off-by: Juergen Gross
Cc:
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: boris.ostrov...@oracle.com
Cc: xen-devel@lists.xenproject.org
Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT
correctly on AMD")
Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/smp.c |5 +
1 file changed, 5 insertions(+)
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -87,6 +88,8 @@ static void cpu_bringup(void)
cpu_data(cpu).x86_max_cores = 1;
set_cpu_sibling_map(cpu);
+ speculative_store_bypass_ht_init();
+
xen_setup_cpu_clockevents();
notify_cpu_starting(cpu);
@@ -357,6 +360,8 @@ static void __init xen_smp_prepare_cpus(
}
set_cpu_sibling_map(0);
+ speculative_store_bypass_ht_init();
+
xen_pmu_init(0);
if (xen_smp_intr_init(0))
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.17 19/31] x86/entry/64: Remove %ebx handling from error_entry/exit
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
error_entry and error_exit communicate the user vs. kernel status of
the frame using %ebx. This is unnecessary -- the information is in
regs->cs. Just use regs->cs.
This makes error_entry simpler and makes error_exit more robust.
It also fixes a nasty bug. Before all the Spectre nonsense, the
xen_failsafe_callback entry point returned like this:
ALLOC_PT_GPREGS_ON_STACK
SAVE_C_REGS
SAVE_EXTRA_REGS
ENCODE_FRAME_POINTER
jmp error_exit
And it did not go through error_entry. This was bogus: RBX
contained garbage, and error_exit expected a flag in RBX.
Fortunately, it generally contained *nonzero* garbage, so the
correct code path was used. As part of the Spectre fixes, code was
added to clear RBX to mitigate certain speculation attacks. Now,
depending on kernel configuration, RBX got zeroed and, when running
some Wine workloads, the kernel crashes. This was introduced by:
commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
exceptions/interrupts, to reduce speculation attack surface")
With this patch applied, RBX is no longer needed as a flag, and the
problem goes away.
I suspect that malicious userspace could use this bug to crash the
kernel even without the offending patch applied, though.
[ Historical note: I wrote this patch as a cleanup before I was aware
of the bug it fixed. ]
[ Note to stable maintainers: this should probably get applied to all
kernels. If you're nervous about that, a more conservative fix to
add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should
also fix the problem. ]
Reported-and-tested-by: M. Vefa Bicakci
Signed-off-by: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Dominik Brodowski
Cc: Greg KH
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts,
to reduce speculation attack surface")
Link:
http://lkml.kernel.org/r/b5010a090d3586b2d6e06c7ad3ec5542d1241c45.1532282627.git.l...@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/entry_64.S | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -981,7 +981,7 @@ ENTRY(\sym)
call\do_sym
- jmp error_exit /* %ebx: no swapgs flag */
+ jmp error_exit
.endif
END(\sym)
.endm
@@ -1222,7 +1222,6 @@ END(paranoid_exit)
/*
* Save all registers in pt_regs, and switch GS if needed.
- * Return: EBX=0: came from user mode; EBX=1: otherwise
*/
ENTRY(error_entry)
UNWIND_HINT_FUNC
@@ -1269,7 +1268,6 @@ ENTRY(error_entry)
* for these here too.
*/
.Lerror_kernelspace:
- incl%ebx
leaqnative_irq_return_iret(%rip), %rcx
cmpq%rcx, RIP+8(%rsp)
je .Lerror_bad_iret
@@ -1303,28 +1301,20 @@ ENTRY(error_entry)
/*
* Pretend that the exception came from user mode: set up pt_regs
-* as if we faulted immediately after IRET and clear EBX so that
-* error_exit knows that we will be returning to user mode.
+* as if we faulted immediately after IRET.
*/
mov %rsp, %rdi
callfixup_bad_iret
mov %rax, %rsp
- decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
END(error_entry)
-
-/*
- * On entry, EBX is a "return to kernel mode" flag:
- * 1: already in kernel mode, don't need SWAPGS
- * 0: user gsbase is loaded, we need SWAPGS and standard preparation for
return to usermode
- */
ENTRY(error_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
- testl %ebx, %ebx
- jnz retint_kernel
+ testb $3, CS(%rsp)
+ jz retint_kernel
jmp retint_user
END(error_exit)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 15/23] x86/entry/64: Remove %ebx handling from error_entry/exit
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
error_entry and error_exit communicate the user vs. kernel status of
the frame using %ebx. This is unnecessary -- the information is in
regs->cs. Just use regs->cs.
This makes error_entry simpler and makes error_exit more robust.
It also fixes a nasty bug. Before all the Spectre nonsense, the
xen_failsafe_callback entry point returned like this:
ALLOC_PT_GPREGS_ON_STACK
SAVE_C_REGS
SAVE_EXTRA_REGS
ENCODE_FRAME_POINTER
jmp error_exit
And it did not go through error_entry. This was bogus: RBX
contained garbage, and error_exit expected a flag in RBX.
Fortunately, it generally contained *nonzero* garbage, so the
correct code path was used. As part of the Spectre fixes, code was
added to clear RBX to mitigate certain speculation attacks. Now,
depending on kernel configuration, RBX got zeroed and, when running
some Wine workloads, the kernel crashes. This was introduced by:
commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
exceptions/interrupts, to reduce speculation attack surface")
With this patch applied, RBX is no longer needed as a flag, and the
problem goes away.
I suspect that malicious userspace could use this bug to crash the
kernel even without the offending patch applied, though.
[ Historical note: I wrote this patch as a cleanup before I was aware
of the bug it fixed. ]
[ Note to stable maintainers: this should probably get applied to all
kernels. If you're nervous about that, a more conservative fix to
add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should
also fix the problem. ]
Reported-and-tested-by: M. Vefa Bicakci
Signed-off-by: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Dominik Brodowski
Cc: Greg KH
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts,
to reduce speculation attack surface")
Link:
http://lkml.kernel.org/r/b5010a090d3586b2d6e06c7ad3ec5542d1241c45.1532282627.git.l...@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/entry_64.S | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -933,7 +933,7 @@ ENTRY(\sym)
call\do_sym
- jmp error_exit /* %ebx: no swapgs flag */
+ jmp error_exit
.endif
END(\sym)
.endm
@@ -1166,7 +1166,6 @@ END(paranoid_exit)
/*
* Save all registers in pt_regs, and switch GS if needed.
- * Return: EBX=0: came from user mode; EBX=1: otherwise
*/
ENTRY(error_entry)
UNWIND_HINT_FUNC
@@ -1213,7 +1212,6 @@ ENTRY(error_entry)
* for these here too.
*/
.Lerror_kernelspace:
- incl%ebx
leaqnative_irq_return_iret(%rip), %rcx
cmpq%rcx, RIP+8(%rsp)
je .Lerror_bad_iret
@@ -1247,28 +1245,20 @@ ENTRY(error_entry)
/*
* Pretend that the exception came from user mode: set up pt_regs
-* as if we faulted immediately after IRET and clear EBX so that
-* error_exit knows that we will be returning to user mode.
+* as if we faulted immediately after IRET.
*/
mov %rsp, %rdi
callfixup_bad_iret
mov %rax, %rsp
- decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
END(error_entry)
-
-/*
- * On entry, EBX is a "return to kernel mode" flag:
- * 1: already in kernel mode, don't need SWAPGS
- * 0: user gsbase is loaded, we need SWAPGS and standard preparation for
return to usermode
- */
ENTRY(error_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF
- testl %ebx, %ebx
- jnz retint_kernel
+ testb $3, CS(%rsp)
+ jz retint_kernel
jmp retint_user
END(error_exit)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.16 201/279] x86/xen: Reset VCPU0 info pointer after shared_info remap
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: "van der Linden, Frank"
[ Upstream commit d1ecfa9d1f402366b1776fbf84e635678a51414f ]
This patch fixes crashes during boot for HVM guests on older (pre HVM
vector callback) Xen versions. Without this, current kernels will always
fail to boot on those Xen versions.
Sample stack trace:
BUG: unable to handle kernel paging request at ff20
IP: __xen_evtchn_do_upcall+0x1e/0x80
PGD 1e0e067 P4D 1e0e067 PUD 1e10067 PMD 235c067 PTE 0
Oops: 0002 [#1] SMP PTI
Modules linked in:
CPU: 0 PID: 512 Comm: kworker/u2:0 Not tainted 4.14.33-52.13.amzn1.x86_64 #1
Hardware name: Xen HVM domU, BIOS 3.4.3.amazon 11/11/2016
task: 88002531d700 task.stack: c948
RIP: 0010:__xen_evtchn_do_upcall+0x1e/0x80
RSP: :880025403ef0 EFLAGS: 00010046
RAX: 813cc760 RBX: ff20 RCX: c9483ef0
RDX: 880020540a00 RSI: 880023c78000 RDI: 001c
RBP: 0001 R08: R09:
R10: R11: R12:
R13: 880025403f5c R14: R15:
FS: () GS:88002540() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: ff20 CR3: 01e0a000 CR4: 06f0
Call Trace:
do_hvm_evtchn_intr+0xa/0x10
__handle_irq_event_percpu+0x43/0x1a0
handle_irq_event_percpu+0x20/0x50
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x80/0x140
handle_irq+0xaf/0x120
do_IRQ+0x41/0xd0
common_interrupt+0x7d/0x7d
During boot, the HYPERVISOR_shared_info page gets remapped to make it work
with KASLR. This means that any pointer derived from it needs to be
adjusted.
The only value that this applies to is the vcpu_info pointer for VCPU 0.
For PV and HVM with the callback vector feature, this gets done via the
smp_ops prepare_boot_cpu callback. Older Xen versions do not support the
HVM callback vector, so there is no Xen-specific smp_ops set up in that
scenario. So, the vcpu_info pointer for VCPU 0 never gets set to the proper
value, and the first reference of it will be bad. Fix this by resetting it
immediately after the remap.
Signed-off-by: Frank van der Linden
Reviewed-by: Eduardo Valentin
Reviewed-by: Alakesh Haloi
Reviewed-by: Vallish Vaidyeshwara
Reviewed-by: Boris Ostrovsky
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Boris Ostrovsky
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/enlighten_hvm.c | 13 +
1 file changed, 13 insertions(+)
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -65,6 +65,19 @@ static void __init xen_hvm_init_mem_mapp
{
early_memunmap(HYPERVISOR_shared_info, PAGE_SIZE);
HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
+
+ /*
+* The virtual address of the shared_info page has changed, so
+* the vcpu_info pointer for VCPU 0 is now stale.
+*
+* The prepare_boot_cpu callback will re-initialize it via
+* xen_vcpu_setup, but we can't rely on that to be called for
+* old Xen versions (xen_have_vector_callback == 0).
+*
+* It is, in any case, bad to have a stale vcpu_info pointer
+* so reset it now.
+*/
+ xen_vcpu_info_reset(0);
}
static void __init init_hvm_pv_info(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 131/189] x86/xen: Reset VCPU0 info pointer after shared_info remap
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: "van der Linden, Frank"
[ Upstream commit d1ecfa9d1f402366b1776fbf84e635678a51414f ]
This patch fixes crashes during boot for HVM guests on older (pre HVM
vector callback) Xen versions. Without this, current kernels will always
fail to boot on those Xen versions.
Sample stack trace:
BUG: unable to handle kernel paging request at ff20
IP: __xen_evtchn_do_upcall+0x1e/0x80
PGD 1e0e067 P4D 1e0e067 PUD 1e10067 PMD 235c067 PTE 0
Oops: 0002 [#1] SMP PTI
Modules linked in:
CPU: 0 PID: 512 Comm: kworker/u2:0 Not tainted 4.14.33-52.13.amzn1.x86_64 #1
Hardware name: Xen HVM domU, BIOS 3.4.3.amazon 11/11/2016
task: 88002531d700 task.stack: c948
RIP: 0010:__xen_evtchn_do_upcall+0x1e/0x80
RSP: :880025403ef0 EFLAGS: 00010046
RAX: 813cc760 RBX: ff20 RCX: c9483ef0
RDX: 880020540a00 RSI: 880023c78000 RDI: 001c
RBP: 0001 R08: R09:
R10: R11: R12:
R13: 880025403f5c R14: R15:
FS: () GS:88002540() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: ff20 CR3: 01e0a000 CR4: 06f0
Call Trace:
do_hvm_evtchn_intr+0xa/0x10
__handle_irq_event_percpu+0x43/0x1a0
handle_irq_event_percpu+0x20/0x50
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x80/0x140
handle_irq+0xaf/0x120
do_IRQ+0x41/0xd0
common_interrupt+0x7d/0x7d
During boot, the HYPERVISOR_shared_info page gets remapped to make it work
with KASLR. This means that any pointer derived from it needs to be
adjusted.
The only value that this applies to is the vcpu_info pointer for VCPU 0.
For PV and HVM with the callback vector feature, this gets done via the
smp_ops prepare_boot_cpu callback. Older Xen versions do not support the
HVM callback vector, so there is no Xen-specific smp_ops set up in that
scenario. So, the vcpu_info pointer for VCPU 0 never gets set to the proper
value, and the first reference of it will be bad. Fix this by resetting it
immediately after the remap.
Signed-off-by: Frank van der Linden
Reviewed-by: Eduardo Valentin
Reviewed-by: Alakesh Haloi
Reviewed-by: Vallish Vaidyeshwara
Reviewed-by: Boris Ostrovsky
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Boris Ostrovsky
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/enlighten_hvm.c | 13 +
1 file changed, 13 insertions(+)
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -64,6 +64,19 @@ static void __init xen_hvm_init_mem_mapp
{
early_memunmap(HYPERVISOR_shared_info, PAGE_SIZE);
HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
+
+ /*
+* The virtual address of the shared_info page has changed, so
+* the vcpu_info pointer for VCPU 0 is now stale.
+*
+* The prepare_boot_cpu callback will re-initialize it via
+* xen_vcpu_setup, but we can't rely on that to be called for
+* old Xen versions (xen_have_vector_callback == 0).
+*
+* It is, in any case, bad to have a stale vcpu_info pointer
+* so reset it now.
+*/
+ xen_vcpu_info_reset(0);
}
static void __init init_hvm_pv_info(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.17 05/21] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: M. Vefa Bicakci
commit 405c018a25fe464dc68057bbc8014a58f2bd4422 upstream.
Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
adjustment corruption") has moved the query and calculation of the
x86_virt_bits and x86_phys_bits fields of the cpuinfo_x86 struct
from the get_cpu_cap function to a new function named
get_cpu_address_sizes.
One of the call sites related to Xen PV VMs was unfortunately missed
in the aforementioned commit. This prevents successful boot-up of
kernel versions 4.17 and up in Xen PV VMs if CONFIG_DEBUG_VIRTUAL
is enabled, due to the following code path:
enlighten_pv.c::xen_start_kernel
mmu_pv.c::xen_reserve_special_pages
page.h::__pa
physaddr.c::__phys_addr
physaddr.h::phys_addr_valid
phys_addr_valid uses boot_cpu_data.x86_phys_bits to validate physical
addresses. boot_cpu_data.x86_phys_bits is no longer populated before
the call to xen_reserve_special_pages due to the aforementioned commit
though, so the validation performed by phys_addr_valid fails, which
causes __phys_addr to trigger a BUG, preventing boot-up.
Signed-off-by: M. Vefa Bicakci
Reviewed-by: Thomas Gleixner
Reviewed-by: Boris Ostrovsky
Cc: "Kirill A. Shutemov"
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org # for v4.17 and up
Fixes: d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits adjustment
corruption")
Signed-off-by: Boris Ostrovsky
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/common.c |2 +-
arch/x86/kernel/cpu/cpu.h|1 +
arch/x86/xen/enlighten_pv.c |3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -883,7 +883,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
apply_forced_caps(c);
}
-static void get_cpu_address_sizes(struct cpuinfo_x86 *c)
+void get_cpu_address_sizes(struct cpuinfo_x86 *c)
{
u32 eax, ebx, ecx, edx;
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -46,6 +46,7 @@ extern const struct cpu_dev *const __x86
*const __x86_cpu_dev_end[];
extern void get_cpu_cap(struct cpuinfo_x86 *c);
+extern void get_cpu_address_sizes(struct cpuinfo_x86 *c);
extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c);
extern int detect_extended_topology_early(struct cpuinfo_x86 *c);
extern int detect_ht_early(struct cpuinfo_x86 *c);
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1258,6 +1258,9 @@ asmlinkage __visible void __init xen_sta
get_cpu_cap(&boot_cpu_data);
x86_configure_nx();
+ /* Determine virtual and physical address sizes */
+ get_cpu_address_sizes(&boot_cpu_data);
+
/* Let's presume PV guests always boot on vCPU with id 0. */
per_cpu(xen_vcpu_id, 0) = 0;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.18 06/22] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: M. Vefa Bicakci
commit 405c018a25fe464dc68057bbc8014a58f2bd4422 upstream.
Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
adjustment corruption") has moved the query and calculation of the
x86_virt_bits and x86_phys_bits fields of the cpuinfo_x86 struct
from the get_cpu_cap function to a new function named
get_cpu_address_sizes.
One of the call sites related to Xen PV VMs was unfortunately missed
in the aforementioned commit. This prevents successful boot-up of
kernel versions 4.17 and up in Xen PV VMs if CONFIG_DEBUG_VIRTUAL
is enabled, due to the following code path:
enlighten_pv.c::xen_start_kernel
mmu_pv.c::xen_reserve_special_pages
page.h::__pa
physaddr.c::__phys_addr
physaddr.h::phys_addr_valid
phys_addr_valid uses boot_cpu_data.x86_phys_bits to validate physical
addresses. boot_cpu_data.x86_phys_bits is no longer populated before
the call to xen_reserve_special_pages due to the aforementioned commit
though, so the validation performed by phys_addr_valid fails, which
causes __phys_addr to trigger a BUG, preventing boot-up.
Signed-off-by: M. Vefa Bicakci
Reviewed-by: Thomas Gleixner
Reviewed-by: Boris Ostrovsky
Cc: "Kirill A. Shutemov"
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org # for v4.17 and up
Fixes: d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits adjustment
corruption")
Signed-off-by: Boris Ostrovsky
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/common.c |2 +-
arch/x86/kernel/cpu/cpu.h|1 +
arch/x86/xen/enlighten_pv.c |3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -905,7 +905,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
apply_forced_caps(c);
}
-static void get_cpu_address_sizes(struct cpuinfo_x86 *c)
+void get_cpu_address_sizes(struct cpuinfo_x86 *c)
{
u32 eax, ebx, ecx, edx;
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -46,6 +46,7 @@ extern const struct cpu_dev *const __x86
*const __x86_cpu_dev_end[];
extern void get_cpu_cap(struct cpuinfo_x86 *c);
+extern void get_cpu_address_sizes(struct cpuinfo_x86 *c);
extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c);
extern void init_scattered_cpuid_features(struct cpuinfo_x86 *c);
extern u32 get_scattered_cpuid_leaf(unsigned int level,
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1259,6 +1259,9 @@ asmlinkage __visible void __init xen_sta
get_cpu_cap(&boot_cpu_data);
x86_configure_nx();
+ /* Determine virtual and physical address sizes */
+ get_cpu_address_sizes(&boot_cpu_data);
+
/* Let's presume PV guests always boot on vCPU with id 0. */
per_cpu(xen_vcpu_id, 0) = 0;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug
On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
> From: Vitaly Kuznetsov
>
> Well require to call add_memory()/add_memory_resource() with
> device_hotplug_lock held, to avoid a lock inversion. Allow external modules
> (e.g. hv_balloon) that make use of add_memory()/add_memory_resource() to
> lock device hotplug.
>
> Signed-off-by: Vitaly Kuznetsov
> [modify patch description]
> Signed-off-by: David Hildenbrand
> ---
> drivers/base/core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 04bbcd779e11..9010b9e942b5 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -700,11 +700,13 @@ void lock_device_hotplug(void)
> {
> mutex_lock(&device_hotplug_lock);
> }
> +EXPORT_SYMBOL_GPL(lock_device_hotplug);
>
> void unlock_device_hotplug(void)
> {
> mutex_unlock(&device_hotplug_lock);
> }
> +EXPORT_SYMBOL_GPL(unlock_device_hotplug);
If these are going to be "global" symbols, let's properly name them.
device_hotplug_lock/unlock would be better. But I am _really_ nervous
about letting stuff outside of the driver core mess with this, as people
better know what they are doing.
Can't we just "lock" the memory stuff instead? Why does the entirety of
the driver core need to be messed with here?
thanks,
greg k-h
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug
On Fri, Aug 17, 2018 at 11:41:24AM +0200, David Hildenbrand wrote:
> On 17.08.2018 11:03, Rafael J. Wysocki wrote:
> > On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote:
> >>
> >> On 17.08.2018 10:41, Greg Kroah-Hartman wrote:
> >>> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
> >>>> From: Vitaly Kuznetsov
> >>>>
> >>>> Well require to call add_memory()/add_memory_resource() with
> >>>> device_hotplug_lock held, to avoid a lock inversion. Allow external
> >>>> modules
> >>>> (e.g. hv_balloon) that make use of add_memory()/add_memory_resource() to
> >>>> lock device hotplug.
> >>>>
> >>>> Signed-off-by: Vitaly Kuznetsov
> >>>> [modify patch description]
> >>>> Signed-off-by: David Hildenbrand
> >>>> ---
> >>>> drivers/base/core.c | 2 ++
> >>>> 1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/drivers/base/core.c b/drivers/base/core.c
> >>>> index 04bbcd779e11..9010b9e942b5 100644
> >>>> --- a/drivers/base/core.c
> >>>> +++ b/drivers/base/core.c
> >>>> @@ -700,11 +700,13 @@ void lock_device_hotplug(void)
> >>>> {
> >>>> mutex_lock(&device_hotplug_lock);
> >>>> }
> >>>> +EXPORT_SYMBOL_GPL(lock_device_hotplug);
> >>>>
> >>>> void unlock_device_hotplug(void)
> >>>> {
> >>>> mutex_unlock(&device_hotplug_lock);
> >>>> }
> >>>> +EXPORT_SYMBOL_GPL(unlock_device_hotplug);
> >>>
> >>> If these are going to be "global" symbols, let's properly name them.
> >>> device_hotplug_lock/unlock would be better. But I am _really_ nervous
> >>> about letting stuff outside of the driver core mess with this, as people
> >>> better know what they are doing.
> >>
> >> The only "problem" is that we have kernel modules (for paravirtualized
> >> devices) that call add_memory(). This is Hyper-V right now, but we might
> >> have other ones in the future. Without them we would not have to export
> >> it. We might also get kernel modules that want to call remove_memory() -
> >> which will require the device_hotplug_lock as of now.
> >>
> >> What we could do is
> >>
> >> a) add_memory() -> _add_memory() and don't export it
> >> b) add_memory() takes the device_hotplug_lock and calls _add_memory() .
> >> We export that one.
> >> c) Use add_memory() in external modules only
> >>
> >> Similar wrapper would be needed e.g. for remove_memory() later on.
> >
> > That would be safer IMO, as it would prevent developers from using
> > add_memory() without the lock, say.
> >
> > If the lock is always going to be required for add_memory(), make it
> > hard (or event impossible) to use the latter without it.
> >
>
> If there are no objections, I'll go into that direction. But I'll wait
> for more comments regarding the general concept first.
It is the middle of the merge window, and maintainers are really busy
right now. I doubt you will get many review comments just yet...
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug
On Fri, Aug 17, 2018 at 01:56:35PM +0200, David Hildenbrand wrote: > E.g. When adding the memory block devices, we know that there won't be a > driver to attach to (as there are no drivers for the "memory" subsystem) > - the bus_probe_device() function that takes the device_lock() could > pretty much be avoided for that case. But burying such special cases > down in core driver code definitely won't make locking related to memory > hotplug easier. You don't have to have a driver for a device if you don't want to, or you can just have a default one for all memory devices if you somehow need it. No reason to not do this if it makes things easier for you. thanks, greg k-h ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.9 001/130] x86/entry/64: Remove %ebx handling from error_entry/exit
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
error_entry and error_exit communicate the user vs. kernel status of
the frame using %ebx. This is unnecessary -- the information is in
regs->cs. Just use regs->cs.
This makes error_entry simpler and makes error_exit more robust.
It also fixes a nasty bug. Before all the Spectre nonsense, the
xen_failsafe_callback entry point returned like this:
ALLOC_PT_GPREGS_ON_STACK
SAVE_C_REGS
SAVE_EXTRA_REGS
ENCODE_FRAME_POINTER
jmp error_exit
And it did not go through error_entry. This was bogus: RBX
contained garbage, and error_exit expected a flag in RBX.
Fortunately, it generally contained *nonzero* garbage, so the
correct code path was used. As part of the Spectre fixes, code was
added to clear RBX to mitigate certain speculation attacks. Now,
depending on kernel configuration, RBX got zeroed and, when running
some Wine workloads, the kernel crashes. This was introduced by:
commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
exceptions/interrupts, to reduce speculation attack surface")
With this patch applied, RBX is no longer needed as a flag, and the
problem goes away.
I suspect that malicious userspace could use this bug to crash the
kernel even without the offending patch applied, though.
[ Historical note: I wrote this patch as a cleanup before I was aware
of the bug it fixed. ]
[ Note to stable maintainers: this should probably get applied to all
kernels. If you're nervous about that, a more conservative fix to
add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should
also fix the problem. ]
Reported-and-tested-by: M. Vefa Bicakci
Signed-off-by: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Dominik Brodowski
Cc: Greg KH
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for exceptions/interrupts,
to reduce speculation attack surface")
Link:
http://lkml.kernel.org/r/b5010a090d3586b2d6e06c7ad3ec5542d1241c45.1532282627.git.l...@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Sarah Newman
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/entry_64.S | 20
1 file changed, 4 insertions(+), 16 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -774,7 +774,7 @@ ENTRY(\sym)
call\do_sym
- jmp error_exit /* %ebx: no swapgs flag */
+ jmp error_exit
.endif
END(\sym)
.endm
@@ -1043,7 +1043,6 @@ END(paranoid_exit)
/*
* Save all registers in pt_regs, and switch gs if needed.
- * Return: EBX=0: came from user mode; EBX=1: otherwise
*/
ENTRY(error_entry)
cld
@@ -1056,7 +1055,6 @@ ENTRY(error_entry)
* the kernel CR3 here.
*/
SWITCH_KERNEL_CR3
- xorl%ebx, %ebx
testb $3, CS+8(%rsp)
jz .Lerror_kernelspace
@@ -1087,7 +1085,6 @@ ENTRY(error_entry)
* for these here too.
*/
.Lerror_kernelspace:
- incl%ebx
leaqnative_irq_return_iret(%rip), %rcx
cmpq%rcx, RIP+8(%rsp)
je .Lerror_bad_iret
@@ -1119,28 +1116,19 @@ ENTRY(error_entry)
/*
* Pretend that the exception came from user mode: set up pt_regs
-* as if we faulted immediately after IRET and clear EBX so that
-* error_exit knows that we will be returning to user mode.
+* as if we faulted immediately after IRET.
*/
mov %rsp, %rdi
callfixup_bad_iret
mov %rax, %rsp
- decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
END(error_entry)
-
-/*
- * On entry, EBX is a "return to kernel mode" flag:
- * 1: already in kernel mode, don't need SWAPGS
- * 0: user gsbase is loaded, we need SWAPGS and standard preparation for
return to usermode
- */
ENTRY(error_exit)
- movl%ebx, %eax
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
- testl %eax, %eax
- jnz retint_kernel
+ testb $3, CS(%rsp)
+ jz retint_kernel
jmp retint_user
END(error_exit)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 105/173] x86/EISA: Dont probe EISA bus for Xen PV guests
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 6a92b11169a65b3f8cc512c75a252cbd0d096ba0 upstream.
For unprivileged Xen PV guests this is normal memory and ioremap will
not be able to properly map it.
While at it, since ioremap may return NULL, add a test for pointer's
validity.
Reported-by: Andy Smith
Signed-off-by: Boris Ostrovsky
Signed-off-by: Thomas Gleixner
Cc: h...@zytor.com
Cc: xen-devel@lists.xenproject.org
Cc: jgr...@suse.com
Cc: sta...@vger.kernel.org
Link:
https://lkml.kernel.org/r/20180911195538.23289-1-boris.ostrov...@oracle.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/eisa.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/eisa.c
+++ b/arch/x86/kernel/eisa.c
@@ -7,11 +7,17 @@
#include
#include
+#include
+
static __init int eisa_bus_probe(void)
{
- void __iomem *p = ioremap(0x0FFFD9, 4);
+ void __iomem *p;
+
+ if (xen_pv_domain() && !xen_initial_domain())
+ return 0;
- if (readl(p) == 'E' + ('I'<<8) + ('S'<<16) + ('A'<<24))
+ p = ioremap(0x0FFFD9, 4);
+ if (p && readl(p) == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
EISA_bus = 1;
iounmap(p);
return 0;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.18 141/235] x86/EISA: Dont probe EISA bus for Xen PV guests
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 6a92b11169a65b3f8cc512c75a252cbd0d096ba0 upstream.
For unprivileged Xen PV guests this is normal memory and ioremap will
not be able to properly map it.
While at it, since ioremap may return NULL, add a test for pointer's
validity.
Reported-by: Andy Smith
Signed-off-by: Boris Ostrovsky
Signed-off-by: Thomas Gleixner
Cc: h...@zytor.com
Cc: xen-devel@lists.xenproject.org
Cc: jgr...@suse.com
Cc: sta...@vger.kernel.org
Link:
https://lkml.kernel.org/r/20180911195538.23289-1-boris.ostrov...@oracle.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/eisa.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/eisa.c
+++ b/arch/x86/kernel/eisa.c
@@ -7,11 +7,17 @@
#include
#include
+#include
+
static __init int eisa_bus_probe(void)
{
- void __iomem *p = ioremap(0x0FFFD9, 4);
+ void __iomem *p;
+
+ if (xen_pv_domain() && !xen_initial_domain())
+ return 0;
- if (readl(p) == 'E' + ('I'<<8) + ('S'<<16) + ('A'<<24))
+ p = ioremap(0x0FFFD9, 4);
+ if (p && readl(p) == 'E' + ('I' << 8) + ('S' << 16) + ('A' << 24))
EISA_bus = 1;
iounmap(p);
return 0;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.4 01/74] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes
Signed-off-by: Andy Lutomirski
Cc: Juergen Gross
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Matthew Whitehead
Cc: Borislav Petkov
Cc: Henrique de Moraes Holschuh
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: xen-devel
Link:
http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.l...@kernel.org
Signed-off-by: Thomas Gleixner
Cc: "Zhang, Ning A"
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/processor.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -574,7 +574,7 @@ static inline void sync_core(void)
{
int tmp;
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
* Do a CPUID if available, otherwise do a jump. The jump
* can conveniently enough be the jump around CPUID.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3.18 20/52] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes
Signed-off-by: Andy Lutomirski
Cc: Juergen Gross
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Matthew Whitehead
Cc: Borislav Petkov
Cc: Henrique de Moraes Holschuh
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: xen-devel
Link:
http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.l...@kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/processor.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -669,7 +669,7 @@ static inline void sync_core(void)
{
int tmp;
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
* Do a CPUID if available, otherwise do a jump. The jump
* can conveniently enough be the jump around CPUID.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.9 01/66] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes
Signed-off-by: Andy Lutomirski
Cc: Juergen Gross
Cc: Peter Zijlstra
Cc: Brian Gerst
Cc: Matthew Whitehead
Cc: Borislav Petkov
Cc: Henrique de Moraes Holschuh
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: xen-devel
Link:
http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.l...@kernel.org
Signed-off-by: Thomas Gleixner
Cc: "Zhang, Ning A"
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/processor.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -596,7 +596,7 @@ static inline void sync_core(void)
{
int tmp;
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
* Do a CPUID if available, otherwise do a jump. The jump
* can conveniently enough be the jump around CPUID.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 124/156] x86/xen: Support early interrupts in xen pv guests
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
[ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ]
Add early interrupt handlers activated by idt_setup_early_handler() to
the handlers supported by Xen pv guests. This will allow for early
WARN() calls not crashing the guest.
Suggested-by: Andy Lutomirski
Signed-off-by: Juergen Gross
Signed-off-by: Thomas Gleixner
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20171124084221.30172-1-jgr...@suse.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/segment.h | 12
arch/x86/mm/extable.c |4 +++-
arch/x86/xen/enlighten_pv.c| 37 -
arch/x86/xen/xen-asm_64.S | 14 ++
4 files changed, 53 insertions(+), 14 deletions(-)
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -236,11 +236,23 @@
*/
#define EARLY_IDT_HANDLER_SIZE 9
+/*
+ * xen_early_idt_handler_array is for Xen pv guests: for each entry in
+ * early_idt_handler_array it contains a prequel in the form of
+ * pop %rcx; pop %r11; jmp early_idt_handler_array[i]; summing up to
+ * max 8 bytes.
+ */
+#define XEN_EARLY_IDT_HANDLER_SIZE 8
+
#ifndef __ASSEMBLY__
extern const char
early_idt_handler_array[NUM_EXCEPTION_VECTORS][EARLY_IDT_HANDLER_SIZE];
extern void early_ignore_irq(void);
+#if defined(CONFIG_X86_64) && defined(CONFIG_XEN_PV)
+extern const char
xen_early_idt_handler_array[NUM_EXCEPTION_VECTORS][XEN_EARLY_IDT_HANDLER_SIZE];
+#endif
+
/*
* Load a segment. Fall back on loading the zero segment if something goes
* wrong. This variant assumes that loading zero fully clears the segment.
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
#include
#include
@@ -212,8 +213,9 @@ void __init early_fixup_exception(struct
* Old CPUs leave the high bits of CS on the stack
* undefined. I'm not sure which CPUs do this, but at least
* the 486 DX works this way.
+* Xen pv domains are not using the default __KERNEL_CS.
*/
- if (regs->cs != __KERNEL_CS)
+ if (!xen_pv_domain() && regs->cs != __KERNEL_CS)
goto fail;
/*
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -622,7 +622,7 @@ static struct trap_array_entry trap_arra
{ simd_coprocessor_error, xen_simd_coprocessor_error, false },
};
-static bool get_trap_addr(void **addr, unsigned int ist)
+static bool __ref get_trap_addr(void **addr, unsigned int ist)
{
unsigned int nr;
bool ist_okay = false;
@@ -644,6 +644,14 @@ static bool get_trap_addr(void **addr, u
}
}
+ if (nr == ARRAY_SIZE(trap_array) &&
+ *addr >= (void *)early_idt_handler_array[0] &&
+ *addr < (void *)early_idt_handler_array[NUM_EXCEPTION_VECTORS]) {
+ nr = (*addr - (void *)early_idt_handler_array[0]) /
+EARLY_IDT_HANDLER_SIZE;
+ *addr = (void *)xen_early_idt_handler_array[nr];
+ }
+
if (WARN_ON(ist != 0 && !ist_okay))
return false;
@@ -1261,6 +1269,21 @@ asmlinkage __visible void __init xen_sta
xen_setup_gdt(0);
xen_init_irq_ops();
+
+ /* Let's presume PV guests always boot on vCPU with id 0. */
+ per_cpu(xen_vcpu_id, 0) = 0;
+
+ /*
+* Setup xen_vcpu early because idt_setup_early_handler needs it for
+* local_irq_disable(), irqs_disabled().
+*
+* Don't do the full vcpu_info placement stuff until we have
+* the cpu_possible_mask and a non-dummy shared_info.
+*/
+ xen_vcpu_info_reset(0);
+
+ idt_setup_early_handler();
+
xen_init_capabilities();
#ifdef CONFIG_X86_LOCAL_APIC
@@ -1294,18 +1317,6 @@ asmlinkage __visible void __init xen_sta
*/
acpi_numa = -1;
#endif
- /* Let's presume PV guests always boot on vCPU with id 0. */
- per_cpu(xen_vcpu_id, 0) = 0;
-
- /*
-* Setup xen_vcpu early because start_kernel needs it for
-* local_irq_disable(), irqs_disabled().
-*
-* Don't do the full vcpu_info placement stuff until we have
-* the cpu_possible_mask and a non-dummy shared_info.
-*/
- xen_vcpu_info_reset(0);
-
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv));
local_irq_disable();
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -15,6 +15,7 @@
#include
+#include
#include
.macro xen_pv_trap name
@@ -54,6 +55,19 @@ xen_pv_trap entry_INT80_compat
#endif
xen_pv_trap hypervisor_callback
+ __INIT
+ENTRY(xen_early_idt_handler_array)
+
[Xen-devel] [PATCH 4.19 042/361] x86/xen: Fix boot loader version reported for PVH guests
4.19-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -75,7 +75,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ x86_init.acpi.get_root_pointer = pvh_get_root_pointer; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.18 037/350] x86/xen: Fix boot loader version reported for PVH guests
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -75,7 +75,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ x86_init.acpi.get_root_pointer = pvh_get_root_pointer; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 020/222] x86/xen: Fix boot loader version reported for PVH guests
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Juergen Gross commit 357d291ce035d1b757568058f3c9898c60d125b1 upstream. The boot loader version reported via sysfs is wrong in case of the kernel being booted via the Xen PVH boot entry. it should be 2.12 (0x020c), but it is reported to be 2.18 (0x0212). As the current way to set the version is error prone use the more readable variant (2 << 8) | 12. Signed-off-by: Juergen Gross Cc: # 4.12 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrov...@oracle.com Cc: b...@alien8.de Cc: cor...@lwn.net Cc: linux-...@vger.kernel.org Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/20181010061456.22238-2-jgr...@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pvh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -76,7 +76,7 @@ static void __init init_pvh_bootparams(v * Version 2.12 supports Xen entry point but we will use default x86/PC * environment (i.e. hardware_subarch 0). */ - pvh_bootparams.hdr.version = 0x212; + pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ } ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4.14 065/159] x86/virt: Add enum for hypervisors to replace x86_hyper
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 03b2a320b19f1424e9ac9c21696be9c60b6d0d93 upstream.
The x86_hyper pointer is only used for checking whether a virtual
device is supporting the hypervisor the system is running on.
Use an enum for that purpose instead and drop the x86_hyper pointer.
Signed-off-by: Juergen Gross
Acked-by: Thomas Gleixner
Acked-by: Xavier Deguillard
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: akata...@vmware.com
Cc: a...@arndb.de
Cc: boris.ostrov...@oracle.com
Cc: de...@linuxdriverproject.org
Cc: dmitry.torok...@gmail.com
Cc: gre...@linuxfoundation.org
Cc: haiya...@microsoft.com
Cc: k...@vger.kernel.org
Cc: k...@microsoft.com
Cc: linux-graphics-maintai...@vmware.com
Cc: linux-in...@vger.kernel.org
Cc: moltm...@vmware.com
Cc: pbonz...@redhat.com
Cc: pv-driv...@vmware.com
Cc: rkrc...@redhat.com
Cc: sthem...@microsoft.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20171109132739.23465-3-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/hyperv/hv_init.c |2 +-
arch/x86/include/asm/hypervisor.h | 23 ++-
arch/x86/kernel/cpu/hypervisor.c | 12 +---
arch/x86/kernel/cpu/mshyperv.c|4 ++--
arch/x86/kernel/cpu/vmware.c |4 ++--
arch/x86/kernel/kvm.c |4 ++--
arch/x86/xen/enlighten_hvm.c |4 ++--
arch/x86/xen/enlighten_pv.c |4 ++--
drivers/hv/vmbus_drv.c|2 +-
drivers/input/mouse/vmmouse.c | 10 --
drivers/misc/vmw_balloon.c|2 +-
11 files changed, 40 insertions(+), 31 deletions(-)
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -113,7 +113,7 @@ void hyperv_init(void)
u64 guest_id;
union hv_x64_msr_hypercall_contents hypercall_msr;
- if (x86_hyper != &x86_hyper_ms_hyperv)
+ if (x86_hyper_type != X86_HYPER_MS_HYPERV)
return;
/* Allocate percpu VP index */
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -29,6 +29,16 @@
/*
* x86 hypervisor information
*/
+
+enum x86_hypervisor_type {
+ X86_HYPER_NATIVE = 0,
+ X86_HYPER_VMWARE,
+ X86_HYPER_MS_HYPERV,
+ X86_HYPER_XEN_PV,
+ X86_HYPER_XEN_HVM,
+ X86_HYPER_KVM,
+};
+
struct hypervisor_x86 {
/* Hypervisor name */
const char *name;
@@ -36,6 +46,9 @@ struct hypervisor_x86 {
/* Detection routine */
uint32_t(*detect)(void);
+ /* Hypervisor type */
+ enum x86_hypervisor_type type;
+
/* init time callbacks */
struct x86_hyper_init init;
@@ -43,15 +56,7 @@ struct hypervisor_x86 {
struct x86_hyper_runtime runtime;
};
-extern const struct hypervisor_x86 *x86_hyper;
-
-/* Recognized hypervisors */
-extern const struct hypervisor_x86 x86_hyper_vmware;
-extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen_pv;
-extern const struct hypervisor_x86 x86_hyper_xen_hvm;
-extern const struct hypervisor_x86 x86_hyper_kvm;
-
+extern enum x86_hypervisor_type x86_hyper_type;
extern void init_hypervisor_platform(void);
#else
static inline void init_hypervisor_platform(void) { }
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -26,6 +26,12 @@
#include
#include
+extern const struct hypervisor_x86 x86_hyper_vmware;
+extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_xen_hvm;
+extern const struct hypervisor_x86 x86_hyper_kvm;
+
static const __initconst struct hypervisor_x86 * const hypervisors[] =
{
#ifdef CONFIG_XEN_PV
@@ -41,8 +47,8 @@ static const __initconst struct hypervis
#endif
};
-const struct hypervisor_x86 *x86_hyper;
-EXPORT_SYMBOL(x86_hyper);
+enum x86_hypervisor_type x86_hyper_type;
+EXPORT_SYMBOL(x86_hyper_type);
static inline const struct hypervisor_x86 * __init
detect_hypervisor_vendor(void)
@@ -87,6 +93,6 @@ void __init init_hypervisor_platform(voi
copy_array(&h->init, &x86_init.hyper, sizeof(h->init));
copy_array(&h->runtime, &x86_platform.hyper, sizeof(h->runtime));
- x86_hyper = h;
+ x86_hyper_type = h->type;
x86_init.hyper.init_platform();
}
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -254,9 +254,9 @@ static void __init ms_hyperv_init_platfo
#endif
}
-const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
+const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
.name = "Microsoft Hyper-V",
.detect = ms_hyperv_platform,
+ .type = X86_HYPER_MS_HYPERV,
.ini
[Xen-devel] [PATCH 4.14 064/159] x86/virt, x86/platform: Merge struct x86_hyper into struct x86_platform and struct x86_init
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit f72e38e8ec8869ac0ba5a75d7d2f897d98a1454e upstream.
Instead of x86_hyper being either NULL on bare metal or a pointer to a
struct hypervisor_x86 in case of the kernel running as a guest merge
the struct into x86_platform and x86_init.
This will remove the need for wrappers making it hard to find out what
is being called. With dummy functions added for all callbacks testing
for a NULL function pointer can be removed, too.
Suggested-by: Ingo Molnar
Signed-off-by: Juergen Gross
Acked-by: Thomas Gleixner
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: akata...@vmware.com
Cc: boris.ostrov...@oracle.com
Cc: de...@linuxdriverproject.org
Cc: haiya...@microsoft.com
Cc: k...@vger.kernel.org
Cc: k...@microsoft.com
Cc: pbonz...@redhat.com
Cc: rkrc...@redhat.com
Cc: ru...@rustcorp.com.au
Cc: sthem...@microsoft.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20171109132739.23465-2-jgr...@suse.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/hypervisor.h | 25 +++-
arch/x86/include/asm/x86_init.h | 24
arch/x86/kernel/apic/apic.c |2 -
arch/x86/kernel/cpu/hypervisor.c | 56 ++
arch/x86/kernel/cpu/mshyperv.c|2 -
arch/x86/kernel/cpu/vmware.c |4 +-
arch/x86/kernel/kvm.c |2 -
arch/x86/kernel/x86_init.c|9 ++
arch/x86/mm/init.c|2 -
arch/x86/xen/enlighten_hvm.c |8 ++---
arch/x86/xen/enlighten_pv.c |2 -
include/linux/hypervisor.h|8 -
12 files changed, 82 insertions(+), 62 deletions(-)
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -23,6 +23,7 @@
#ifdef CONFIG_HYPERVISOR_GUEST
#include
+#include
#include
/*
@@ -35,17 +36,11 @@ struct hypervisor_x86 {
/* Detection routine */
uint32_t(*detect)(void);
- /* Platform setup (run once per boot) */
- void(*init_platform)(void);
+ /* init time callbacks */
+ struct x86_hyper_init init;
- /* X2APIC detection (run once per boot) */
- bool(*x2apic_available)(void);
-
- /* pin current vcpu to specified physical cpu (run rarely) */
- void(*pin_vcpu)(int);
-
- /* called during init_mem_mapping() to setup early mappings. */
- void(*init_mem_mapping)(void);
+ /* runtime callbacks */
+ struct x86_hyper_runtime runtime;
};
extern const struct hypervisor_x86 *x86_hyper;
@@ -58,17 +53,7 @@ extern const struct hypervisor_x86 x86_h
extern const struct hypervisor_x86 x86_hyper_kvm;
extern void init_hypervisor_platform(void);
-extern bool hypervisor_x2apic_available(void);
-extern void hypervisor_pin_vcpu(int cpu);
-
-static inline void hypervisor_init_mem_mapping(void)
-{
- if (x86_hyper && x86_hyper->init_mem_mapping)
- x86_hyper->init_mem_mapping();
-}
#else
static inline void init_hypervisor_platform(void) { }
-static inline bool hypervisor_x2apic_available(void) { return false; }
-static inline void hypervisor_init_mem_mapping(void) { }
#endif /* CONFIG_HYPERVISOR_GUEST */
#endif /* _ASM_X86_HYPERVISOR_H */
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -115,6 +115,18 @@ struct x86_init_pci {
};
/**
+ * struct x86_hyper_init - x86 hypervisor init functions
+ * @init_platform: platform setup
+ * @x2apic_available: X2APIC detection
+ * @init_mem_mapping: setup early mappings during init_mem_mapping()
+ */
+struct x86_hyper_init {
+ void (*init_platform)(void);
+ bool (*x2apic_available)(void);
+ void (*init_mem_mapping)(void);
+};
+
+/**
* struct x86_init_ops - functions for platform specific setup
*
*/
@@ -127,6 +139,7 @@ struct x86_init_ops {
struct x86_init_timers timers;
struct x86_init_iommu iommu;
struct x86_init_pci pci;
+ struct x86_hyper_init hyper;
};
/**
@@ -200,6 +213,15 @@ struct x86_legacy_features {
};
/**
+ * struct x86_hyper_runtime - x86 hypervisor specific runtime callbacks
+ *
+ * @pin_vcpu: pin current vcpu to specified physical cpu (run rarely)
+ */
+struct x86_hyper_runtime {
+ void (*pin_vcpu)(int cpu);
+};
+
+/**
* struct x86_platform_ops - platform specific runtime functions
* @calibrate_cpu: calibrate CPU
* @calibrate_tsc: calibrate TSC, if different from CPU
@@ -218,6 +240,7 @@ struct x86_legacy_features {
* possible in x86_early_init_platform_quirks() by
* only using the current x86_hardware_subarch
*
[Xen-devel] [PATCH 4.14 074/159] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit e17f8234538d1ff708673f287a42457c4dee720d upstream.
Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make them
NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses eflags
using 'pushfq' instruction when testing for IF bit. On PV Xen guests
looking at IF flag directly will always see it set, resulting in 'ud2'.
Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op when
running paravirt.
Signed-off-by: Boris Ostrovsky
Signed-off-by: Thomas Gleixner
Reviewed-by: Juergen Gross
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Dave Hansen
Cc: David Laight
Cc: Denys Vlasenko
Cc: Eduardo Valentin
Cc: Greg KH
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Will Deacon
Cc: aligu...@amazon.com
Cc: daniel.gr...@iaik.tugraz.at
Cc: hu...@google.com
Cc: keesc...@google.com
Cc: xen-devel@lists.xenproject.org
Link: https://lkml.kernel.org/r/20171204150604.899457...@linutronix.de
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/entry_64.S|7 ---
arch/x86/include/asm/irqflags.h |3 +++
arch/x86/include/asm/paravirt.h |9 +
arch/x86/kernel/asm-offsets_64.c |3 +++
4 files changed, 19 insertions(+), 3 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -462,12 +462,13 @@ END(irq_entries_start)
.macro DEBUG_ENTRY_ASSERT_IRQS_OFF
#ifdef CONFIG_DEBUG_ENTRY
- pushfq
- testl $X86_EFLAGS_IF, (%rsp)
+ pushq %rax
+ SAVE_FLAGS(CLBR_RAX)
+ testl $X86_EFLAGS_IF, %eax
jz .Lokay_\@
ud2
.Lokay_\@:
- addq $8, %rsp
+ popq %rax
#endif
.endm
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -142,6 +142,9 @@ static inline notrace unsigned long arch
swapgs; \
sysretl
+#ifdef CONFIG_DEBUG_ENTRY
+#define SAVE_FLAGS(x) pushfq; popq %rax
+#endif
#else
#define INTERRUPT_RETURN iret
#define ENABLE_INTERRUPTS_SYSEXIT sti; sysexit
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -927,6 +927,15 @@ extern void default_banner(void);
PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64), \
CLBR_NONE,\
jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret64))
+
+#ifdef CONFIG_DEBUG_ENTRY
+#define SAVE_FLAGS(clobbers)\
+ PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_save_fl), clobbers, \
+ PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE);\
+ call PARA_INDIRECT(pv_irq_ops+PV_IRQ_save_fl);\
+ PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);)
+#endif
+
#endif /* CONFIG_X86_32 */
#endif /* __ASSEMBLY__ */
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -23,6 +23,9 @@ int main(void)
#ifdef CONFIG_PARAVIRT
OFFSET(PV_CPU_usergs_sysret64, pv_cpu_ops, usergs_sysret64);
OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
+#ifdef CONFIG_DEBUG_ENTRY
+ OFFSET(PV_IRQ_save_fl, pv_irq_ops, save_fl);
+#endif
BLANK();
#endif
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED
On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote:
> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
> always set to 0 by hardware. This is far from beautiful (and confusing),
> and the bit only applies to SYSRAM. So let's move it out of the
> bus-specific (PnP) defined bits.
>
> We'll add another SYSRAM specific bit soon. If we ever need more bits for
> other purposes, we can steal some from "desc", or reshuffle/regroup what we
> have.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Dan Williams
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Ard Biesheuvel
> Cc: Pankaj Gupta
> Cc: Baoquan He
> Cc: Wei Yang
> Cc: Eric Biederman
> Cc: Thomas Gleixner
> Cc: Greg Kroah-Hartman
> Cc: ke...@lists.infradead.org
> Signed-off-by: David Hildenbrand
> ---
> include/linux/ioport.h | 4 +++-
> kernel/kexec_file.c| 2 +-
> mm/memory_hotplug.c| 4 ++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 52a91f5fa1a36..d7620d7c941a0 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -58,6 +58,9 @@ struct resource {
> #define IORESOURCE_EXT_TYPE_BITS 0x0100 /* Resource extended types */
> #define IORESOURCE_SYSRAM0x0100 /* System RAM (modifier) */
>
> +/* IORESOURCE_SYSRAM specific bits. */
> +#define IORESOURCE_SYSRAM_DRIVER_MANAGED 0x0200 /* Always detected
> via a driver. */
> +
Can't you use BIT() here?
thanks,
greg k-h
Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added System RAM resources. > mergeable. Prepare for that. What are these random "flags", and how do we know what should be passed to them? Why not make this an enumerated type so that we know it all works properly, like the GPF_* flags are? Passing around a random unsigned long feels very odd/broken... thanks, greg k-h
[PATCH 4.4 67/86] x86/paravirt: Remove the unused irq_enable_sysexit pv op
From: Boris Ostrovsky
commit 88c15ec90ff16880efab92b519436ee17b198477 upstream.
As result of commit "x86/xen: Avoid fast syscall path for Xen PV
guests", the irq_enable_sysexit pv op is not called by Xen PV guests
anymore and since they were the only ones who used it we can
safely remove it.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Borislav Petkov
Acked-by: Andy Lutomirski
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: david.vra...@citrix.com
Cc: konrad.w...@oracle.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Link:
http://lkml.kernel.org/r/1447970147-1733-3-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/entry_32.S |8 ++--
arch/x86/include/asm/paravirt.h |7 ---
arch/x86/include/asm/paravirt_types.h |9 -
arch/x86/kernel/asm-offsets.c |3 ---
arch/x86/kernel/paravirt.c|7 ---
arch/x86/kernel/paravirt_patch_32.c |2 --
arch/x86/kernel/paravirt_patch_64.c |1 -
arch/x86/xen/enlighten.c |3 ---
arch/x86/xen/xen-asm_32.S | 14 --
arch/x86/xen/xen-ops.h|3 ---
10 files changed, 2 insertions(+), 55 deletions(-)
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -331,7 +331,8 @@ sysenter_past_esp:
* Return back to the vDSO, which will pop ecx and edx.
* Don't bother with DS and ES (they already contain __USER_DS).
*/
- ENABLE_INTERRUPTS_SYSEXIT
+ sti
+ sysexit
.pushsection .fixup, "ax"
2: movl$0, PT_FS(%esp)
@@ -554,11 +555,6 @@ ENTRY(native_iret)
iret
_ASM_EXTABLE(native_iret, iret_exc)
END(native_iret)
-
-ENTRY(native_irq_enable_sysexit)
- sti
- sysexit
-END(native_irq_enable_sysexit)
#endif
ENTRY(overflow)
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -938,13 +938,6 @@ extern void default_banner(void);
push %ecx; push %edx; \
call PARA_INDIRECT(pv_cpu_ops+PV_CPU_read_cr0); \
pop %edx; pop %ecx
-
-#define ENABLE_INTERRUPTS_SYSEXIT \
- PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_irq_enable_sysexit),\
- CLBR_NONE,\
- jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_irq_enable_sysexit))
-
-
#else /* !CONFIG_X86_32 */
/*
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -162,15 +162,6 @@ struct pv_cpu_ops {
u64 (*read_pmc)(int counter);
-#ifdef CONFIG_X86_32
- /*
-* Atomically enable interrupts and return to userspace. This
-* is only used in 32-bit kernels. 64-bit kernels use
-* usergs_sysret32 instead.
-*/
- void (*irq_enable_sysexit)(void);
-#endif
-
/*
* Switch to usermode gs and return to 64-bit usermode using
* sysret. Only used in 64-bit kernels to return to 64-bit
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -65,9 +65,6 @@ void common(void) {
OFFSET(PV_IRQ_irq_disable, pv_irq_ops, irq_disable);
OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
-#ifdef CONFIG_X86_32
- OFFSET(PV_CPU_irq_enable_sysexit, pv_cpu_ops, irq_enable_sysexit);
-#endif
OFFSET(PV_CPU_read_cr0, pv_cpu_ops, read_cr0);
OFFSET(PV_MMU_read_cr2, pv_mmu_ops, read_cr2);
#endif
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -168,9 +168,6 @@ unsigned paravirt_patch_default(u8 type,
ret = paravirt_patch_ident_64(insnbuf, len);
else if (type == PARAVIRT_PATCH(pv_cpu_ops.iret) ||
-#ifdef CONFIG_X86_32
-type == PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit) ||
-#endif
type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret32) ||
type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret64))
/* If operation requires a jmp, then jmp */
@@ -226,7 +223,6 @@ static u64 native_steal_clock(int cpu)
/* These are in entry.S */
extern void native_iret(void);
-extern void native_irq_enable_sysexit(void);
extern void native_usergs_sysret32(void);
extern void native_usergs_sysret64(void);
@@ -385,9 +381,6 @@ __visible struct pv_cpu_ops pv_cpu_ops =
.load_sp0 = native_load_sp0,
-#if defined(CONFIG_X86_32)
- .irq_enable_sysexit = native_irq_enable_sysexit,
-#endif
#ifdef CONFIG_X86_64
#ifdef CONFIG_IA32_EMULATION
.usergs_sysret32 = native_usergs_sysret32,
--- a/arch/x86/kernel/paravirt_patch_32.c
+++ b/arch/x86/kernel/paravirt_patch_32.c
@@ -5,7 +5,6 @@ DEF_NATIVE(pv_
Re: [PATCH v2 20/39] docs: ABI: testing: make the files compatible with ReST output
On Mon, Nov 02, 2020 at 12:04:36PM +0100, Fabrice Gasnier wrote: > On 10/30/20 11:09 AM, Mauro Carvalho Chehab wrote: > > Em Fri, 30 Oct 2020 10:19:12 +0100 > > Fabrice Gasnier escreveu: > > > >> Hi Mauro, > >> > >> [...] > >> > >>> > >>> +What: > >>> /sys/bus/iio/devices/iio:deviceX/in_count_quadrature_mode_available > >>> +KernelVersion: 4.12 > >>> +Contact: benjamin.gaign...@st.com > >>> +Description: > >>> + Reading returns the list possible quadrature modes. > >>> + > >>> +What: > >>> /sys/bus/iio/devices/iio:deviceX/in_count0_quadrature_mode > >>> +KernelVersion: 4.12 > >>> +Contact: benjamin.gaign...@st.com > >>> +Description: > >>> + Configure the device counter quadrature modes: > >>> + > >>> + channel_A: > >>> + Encoder A input servers as the count input and B as > >>> + the UP/DOWN direction control input. > >>> + > >>> + channel_B: > >>> + Encoder B input serves as the count input and A as > >>> + the UP/DOWN direction control input. > >>> + > >>> + quadrature: > >>> + Encoder A and B inputs are mixed to get direction > >>> + and count with a scale of 0.25. > >>> + > >> > > > > Hi Fabrice, > > > >> I just noticed that since Jonathan question in v1. > >> > >> Above ABI has been moved in the past as discussed in [1]. You can take a > >> look at: > >> b299d00 IIO: stm32: Remove quadrature related functions from trigger driver > >> > >> Could you please remove the above chunk ? > >> > >> With that, for the stm32 part: > >> Acked-by: Fabrice Gasnier > > > > > > Hmm... probably those were re-introduced due to a rebase. This > > series were originally written about 1,5 years ago. > > > > I'll drop those hunks. > > Hi Mauro, Greg, > > I just figured out this patch has been applied with above hunk. > > This should be dropped: is there a fix on its way already ? > (I may have missed it) Can you send a fix for just this hunk? thanks, greg k-h
[PATCH 5.4 05/85] linkage: Introduce new macros for assembler symbols
From: Jiri Slaby commit ffedeeb780dc554eff3d3b16e6a462a26a41d7ec upstream. Introduce new C macros for annotations of functions and data in assembly. There is a long-standing mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support macros for the ones below SYM_T_FUNC -- type used by assembler to mark functions SYM_T_OBJECT -- type used by assembler to mark data SYM_T_NONE -- type used by assembler to mark entries of unknown type They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE respectively. According to the gas manual, this is the most portable way. I am not sure about other assemblers, so this can be switched back to %function and %object if this turns into a problem. Architectures can also override them by something like ", @function" if they need. SYM_A_ALIGN, SYM_A_NONE -- align the symbol? SYM_L_GLOBAL, SYM_L_WEAK, SYM_L_LOCAL -- linkage of symbols b) Mostly internal annotations, used by the ones below SYM_ENTRY -- use only if you have to (for non-paired symbols) SYM_START -- use only if you have to (for paired symbols) SYM_END -- use only if you have to (for paired symbols) c) Annotations for code SYM_INNER_LABEL_ALIGN -- only for labels in the middle of code SYM_INNER_LABEL -- only for labels in the middle of code SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for one function SYM_FUNC_START_ALIAS -- use where there are two global names for one function SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function SYM_FUNC_START -- use for global functions SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment SYM_FUNC_START_LOCAL -- use for local functions SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o alignment SYM_FUNC_START_WEAK -- use for weak functions SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START, SYM_FUNC_START_WEAK, ... For functions with special (non-C) calling conventions: SYM_CODE_START -- use for non-C (special) functions SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o alignment SYM_CODE_START_LOCAL -- use for local non-C (special) functions SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special) functions, w/o alignment SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START d) For data SYM_DATA_START -- global data symbol SYM_DATA_START_LOCAL -- local data symbol SYM_DATA_END -- the end of the SYM_DATA_START symbol SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol SYM_DATA -- start+end wrapper around simple global data SYM_DATA_LOCAL -- start+end wrapper around simple local data == The macros allow to pair starts and ends of functions and mark functions correctly in the output ELF objects. All users of the old macros in x86 are converted to use these in further patches. Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Acked-by: Rafael J. Wysocki Cc: Andrew Morton Cc: Andrey Ryabinin Cc: Boris Ostrovsky Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Len Brown Cc: Linus Torvalds Cc: linux-a...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: Mark Rutland Cc: Pavel Machek Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Cc: x86-ml Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/2019105108.12392-2-jsl...@suse.cz Cc: Jian Cai Signed-off-by: Greg Kroah-Hartman --- Documentation/asm-annotations.rst | 216 + Documentation/index.rst |8 + arch/x86/include/asm/linkage.h| 10 + include/linux/linkage.h | 245 -- 4 files changed, 468 insertions(+), 11 deletions(-) --- /dev/null +++ b/Documentation/asm-annotations.rst @@ -0,0 +1,216 @@ +Assembler Annotations += + +Copyright (c) 2017-2019 Jiri Slaby + +This document describes the new macros for annotation of data and code in +assembly. In particular, it contains information about ``SYM_FUNC_START``, +``SYM_FUNC_END``, ``SYM_CODE_START``, and similar. + +Rationale +- +Some code like entries, trampolines, or boot code needs to be written in +assembly. The same as in C, such code is grouped into functions and +accompanied with data. Standard assemblers do not force users into precisely +marking these pieces as code, data, or even specifying their length. +Nevertheless, assemblers provide developers with such annotations to aid +debuggers throughout assembly. On top of that, developers also want to mark +some functions as *gl
[PATCH 5.4 01/62] x86/asm/32: Add ENDs to some functions and relabel with SYM_CODE_*
From: Jiri Slaby commit 78762b0e79bc1dd01347be061abdf505202152c9 upstream. All these are functions which are invoked from elsewhere but they are not typical C functions. So annotate them using the new SYM_CODE_START. All these were not balanced with any END, so mark their ends by SYM_CODE_END, appropriately. Signed-off-by: Jiri Slaby Signed-off-by: Borislav Petkov Reviewed-by: Boris Ostrovsky [xen bits] Reviewed-by: Rafael J. Wysocki [hibernate] Cc: Andy Lutomirski Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Len Brown Cc: linux-a...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: Pavel Machek Cc: Peter Zijlstra Cc: Pingfan Liu Cc: Stefano Stabellini Cc: "Steven Rostedt (VMware)" Cc: Thomas Gleixner Cc: x86-ml Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/2019105108.12392-26-jsl...@suse.cz Signed-off-by: Sasha Levin --- arch/x86/entry/entry_32.S| 3 ++- arch/x86/kernel/acpi/wakeup_32.S | 7 --- arch/x86/kernel/ftrace_32.S | 3 ++- arch/x86/kernel/head_32.S| 3 ++- arch/x86/power/hibernate_asm_32.S| 6 -- arch/x86/realmode/rm/trampoline_32.S | 6 -- arch/x86/xen/xen-asm_32.S| 7 --- 7 files changed, 22 insertions(+), 13 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 390edb7638265..bde3e0f85425f 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -869,9 +869,10 @@ GLOBAL(__begin_SYSENTER_singlestep_region) * Xen doesn't set %esp to be precisely what the normal SYSENTER * entry point expects, so fix it up before using the normal path. */ -ENTRY(xen_sysenter_target) +SYM_CODE_START(xen_sysenter_target) addl$5*4, %esp /* remove xen-provided frame */ jmp .Lsysenter_past_esp +SYM_CODE_END(xen_sysenter_target) #endif /* diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S index e95e95960156b..5b076cb79f5fb 100644 --- a/arch/x86/kernel/acpi/wakeup_32.S +++ b/arch/x86/kernel/acpi/wakeup_32.S @@ -9,8 +9,7 @@ .code32 ALIGN -ENTRY(wakeup_pmode_return) -wakeup_pmode_return: +SYM_CODE_START(wakeup_pmode_return) movw$__KERNEL_DS, %ax movw%ax, %ss movw%ax, %fs @@ -39,6 +38,7 @@ wakeup_pmode_return: # jump to place where we left off movlsaved_eip, %eax jmp *%eax +SYM_CODE_END(wakeup_pmode_return) bogus_magic: jmp bogus_magic @@ -72,7 +72,7 @@ restore_registers: popfl ret -ENTRY(do_suspend_lowlevel) +SYM_CODE_START(do_suspend_lowlevel) callsave_processor_state callsave_registers pushl $3 @@ -87,6 +87,7 @@ ret_point: callrestore_registers callrestore_processor_state ret +SYM_CODE_END(do_suspend_lowlevel) .data ALIGN diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S index 073aab525d800..2cc0303522c99 100644 --- a/arch/x86/kernel/ftrace_32.S +++ b/arch/x86/kernel/ftrace_32.S @@ -89,7 +89,7 @@ WEAK(ftrace_stub) ret END(ftrace_caller) -ENTRY(ftrace_regs_caller) +SYM_CODE_START(ftrace_regs_caller) /* * We're here from an mcount/fentry CALL, and the stack frame looks like: * @@ -163,6 +163,7 @@ GLOBAL(ftrace_regs_call) popl%eax jmp .Lftrace_ret +SYM_CODE_END(ftrace_regs_caller) #ifdef CONFIG_FUNCTION_GRAPH_TRACER ENTRY(ftrace_graph_caller) diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 2e6a0676c1f43..11a5d5ade52ce 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -64,7 +64,7 @@ RESERVE_BRK(pagetables, INIT_MAP_SIZE) * can. */ __HEAD -ENTRY(startup_32) +SYM_CODE_START(startup_32) movl pa(initial_stack),%ecx /* test KEEP_SEGMENTS flag to see if the bootloader is asking @@ -172,6 +172,7 @@ num_subarch_entries = (. - subarch_entries) / 4 #else jmp .Ldefault_entry #endif /* CONFIG_PARAVIRT */ +SYM_CODE_END(startup_32) #ifdef CONFIG_HOTPLUG_CPU /* diff --git a/arch/x86/power/hibernate_asm_32.S b/arch/x86/power/hibernate_asm_32.S index 6fe383002125f..a19ed3d231853 100644 --- a/arch/x86/power/hibernate_asm_32.S +++ b/arch/x86/power/hibernate_asm_32.S @@ -35,7 +35,7 @@ ENTRY(swsusp_arch_suspend) ret ENDPROC(swsusp_arch_suspend) -ENTRY(restore_image) +SYM_CODE_START(restore_image) /* prepare to jump to the image kernel */ movlrestore_jump_address, %ebx movlrestore_cr3, %ebp @@ -45,9 +45,10 @@ ENTRY(restore_image) /* jump to relocated restore code */ movlrelocated_restore_code, %eax jmpl*%eax +SYM_CODE_END(restore_image) /* code below has been relocated to a safe page */ -ENTRY(core_restore_code) +SYM_CODE_START(core_restore_code) movltemp_pgt, %eax movl%eax, %cr3 @@ -77,6 +78,7 @@ co
Re: [PATCH for-4.19.y] xen/privcmd: allow fetching resource sizes
On Fri, Jan 29, 2021 at 01:22:15PM +0100, Roger Pau Monne wrote: > commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream. > Now queued up, thanks. greg k-h
Re: [PATCH] xen: don't reschedule in preemption off sections
On Thu, Aug 20, 2020 at 07:13:00AM +0200, Jürgen Groß wrote:
> On 19.08.20 18:57, Sarah Newman wrote:
> > On 7/10/20 5:01 AM, Jürgen Groß wrote:
> > > On 10.07.20 13:55, Jan Beulich wrote:
> > > > On 10.07.2020 12:50, Jürgen Groß wrote:
> > > > > On 10.07.20 11:49, Jan Beulich wrote:
> > > > > > On 10.07.2020 09:50, Juergen Gross wrote:
> > > > > > > For support of long running hypercalls xen_maybe_preempt_hcall()
> > > > > > > is
> > > > > > > calling cond_resched() in case a hypercall marked as preemptible
> > > > > > > has
> > > > > > > been interrupted.
> > > > > > >
> > > > > > > Normally this is no problem, as only hypercalls done
> > > > > > > via some ioctl()s
> > > > > > > are marked to be preemptible. In rare cases when during such a
> > > > > > > preemptible hypercall an interrupt occurs and any softirq action
> > > > > > > is
> > > > > > > started from irq_exit(), a further hypercall issued by the softirq
> > > > > > > handler will be regarded to be preemptible, too. This might lead
> > > > > > > to
> > > > > > > rescheduling in spite of the softirq handler potentially having
> > > > > > > set
> > > > > > > preempt_disable(), leading to splats like:
> > > > > > >
> > > > > > > BUG: sleeping function called from invalid context
> > > > > > > at drivers/xen/preempt.c:37
> > > > > > > in_atomic(): 1, irqs_disabled(): 0, non_block: 0,
> > > > > > > pid: 20775, name: xl
> > > > > > > INFO: lockdep is turned off.
> > > > > > > CPU: 1 PID: 20775 Comm: xl Tainted: G D W
> > > > > > > 5.4.46-1_prgmr_debug.el7.x86_64 #1
> > > > > > > Call Trace:
> > > > > > >
> > > > > > > dump_stack+0x8f/0xd0
> > > > > > > ___might_sleep.cold.76+0xb2/0x103
> > > > > > > xen_maybe_preempt_hcall+0x48/0x70
> > > > > > > xen_do_hypervisor_callback+0x37/0x40
> > > > > > > RIP: e030:xen_hypercall_xen_version+0xa/0x20
> > > > > > > Code: ...
> > > > > > > RSP: e02b:c900400dcc30 EFLAGS: 0246
> > > > > > > RAX: 0004000d RBX: 0200 RCX: 8100122a
> > > > > > > RDX: 88812e788000 RSI: RDI:
> > > > > > > RBP: 83ee3ad0 R08: 0001 R09: 0001
> > > > > > > R10: R11: 0246 R12: 8881824aa0b0
> > > > > > > R13: 000865496000 R14: 000865496000 R15: 88815d04
> > > > > > > ? xen_hypercall_xen_version+0xa/0x20
> > > > > > > ? xen_force_evtchn_callback+0x9/0x10
> > > > > > > ? check_events+0x12/0x20
> > > > > > > ? xen_restore_fl_direct+0x1f/0x20
> > > > > > > ? _raw_spin_unlock_irqrestore+0x53/0x60
> > > > > > > ? debug_dma_sync_single_for_cpu+0x91/0xc0
> > > > > > > ? _raw_spin_unlock_irqrestore+0x53/0x60
> > > > > > > ? xen_swiotlb_sync_single_for_cpu+0x3d/0x140
> > > > > > > ? mlx4_en_process_rx_cq+0x6b6/0x1110 [mlx4_en]
> > > > > > > ? mlx4_en_poll_rx_cq+0x64/0x100 [mlx4_en]
> > > > > > > ? net_rx_action+0x151/0x4a0
> > > > > > > ? __do_softirq+0xed/0x55b
> > > > > > > ? irq_exit+0xea/0x100
> > > > > > > ? xen_evtchn_do_upcall+0x2c/0x40
> > > > > > > ? xen_do_hypervisor_callback+0x29/0x40
> > > > > > >
> > > > > > > ? xen_hypercall_domctl+0xa/0x20
> > > > > > > ? xen_hypercall_domctl+0x8/0x20
> > > > > > > ? privcmd_ioctl+0x221/0x990 [xen_privcmd]
> > > > > > > ? do_vfs_ioctl+0xa5/0x6f0
> > > > > > > ? ksys_ioctl+0x60/0x90
> > > > > > > ? trace_hardirqs_off_thunk+0x1a/0x20
> > > > > > > ? __x64_sys_ioctl+0x16/0x20
> > > > > > > ? do_syscall_64+0x62/0x250
> > > > > > > ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > > > > >
> > > > > > > Fix that by testing preempt_count() before calling cond_resched().
> > > > > > >
> > > > > > > In kernel 5.8 this can't happen any more due to the
> > > > > > > entry code rework.
> > > > > > >
> > > > > > > Reported-by: Sarah Newman
> > > > > > > Fixes: 0fa2f5cb2b0ecd8 ("sched/preempt, xen: Use
> > > > > > > need_resched() instead of should_resched()")
> > > > > > > Cc: Sarah Newman
> > > > > > > Signed-off-by: Juergen Gross
> > > > > > > ---
> > > > > > > drivers/xen/preempt.c | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c
> > > > > > > index 17240c5325a3..6ad87b5c95ed 100644
> > > > > > > --- a/drivers/xen/preempt.c
> > > > > > > +++ b/drivers/xen/preempt.c
> > > > > > > @@ -27,7 +27,7 @@ EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall);
> > > > > > > asmlinkage __visible void xen_maybe_preempt_hcall(void)
> > > > > > > {
> > > > > > > if (unlikely(__this_cpu_read(xen_in_preemptible_hcall)
> > > > > > > - && need_resched())) {
> > > > > > > + && need_resched() && !preempt_count())) {
> > > > > >
> > > > > > Doesn't this have the at least latent risk of hiding issues in
> > > > > > other call trees (by no longer triggering logging like the one
> > > > > > that has propmted this change)? Wouldn't it be better to save,
> > > > > > clear, and restore the flag in one of xen_evtchn_do_upcall() or
> > >
Re: [PATCH] xen: don't reschedule in preemption off sections
On Thu, Aug 20, 2020 at 07:58:55AM +0200, Jürgen Groß wrote: > On 20.08.20 07:44, Greg Kroah-Hartman wrote: > > On Thu, Aug 20, 2020 at 07:13:00AM +0200, Jürgen Groß wrote: > > > On 19.08.20 18:57, Sarah Newman wrote: > > > > On 7/10/20 5:01 AM, Jürgen Groß wrote: > > > > > On 10.07.20 13:55, Jan Beulich wrote: > > > > > > On 10.07.2020 12:50, Jürgen Groß wrote: > > > > > > > On 10.07.20 11:49, Jan Beulich wrote: > > > > > > > > On 10.07.2020 09:50, Juergen Gross wrote: > > > > > > > > > For support of long running hypercalls > > > > > > > > > xen_maybe_preempt_hcall() is > > > > > > > > > calling cond_resched() in case a hypercall marked as > > > > > > > > > preemptible has > > > > > > > > > been interrupted. > > > > > > > > > > > > > > > > > > Normally this is no problem, as only hypercalls done > > > > > > > > > via some ioctl()s > > > > > > > > > are marked to be preemptible. In rare cases when during such a > > > > > > > > > preemptible hypercall an interrupt occurs and any softirq > > > > > > > > > action is > > > > > > > > > started from irq_exit(), a further hypercall issued by the > > > > > > > > > softirq > > > > > > > > > handler will be regarded to be preemptible, too. This might > > > > > > > > > lead to > > > > > > > > > rescheduling in spite of the softirq handler potentially > > > > > > > > > having set > > > > > > > > > preempt_disable(), leading to splats like: > > > > > > > > > > > > > > > > > > BUG: sleeping function called from invalid context > > > > > > > > > at drivers/xen/preempt.c:37 > > > > > > > > > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, > > > > > > > > > pid: 20775, name: xl > > > > > > > > > INFO: lockdep is turned off. > > > > > > > > > CPU: 1 PID: 20775 Comm: xl Tainted: G D W > > > > > > > > > 5.4.46-1_prgmr_debug.el7.x86_64 #1 > > > > > > > > > Call Trace: > > > > > > > > > > > > > > > > > > dump_stack+0x8f/0xd0 > > > > > > > > > ___might_sleep.cold.76+0xb2/0x103 > > > > > > > > > xen_maybe_preempt_hcall+0x48/0x70 > > > > > > > > > xen_do_hypervisor_callback+0x37/0x40 > > > > > > > > > RIP: e030:xen_hypercall_xen_version+0xa/0x20 > > > > > > > > > Code: ... > > > > > > > > > RSP: e02b:c900400dcc30 EFLAGS: 0246 > > > > > > > > > RAX: 0004000d RBX: 0200 RCX: > > > > > > > > > 8100122a > > > > > > > > > RDX: 88812e788000 RSI: RDI: > > > > > > > > > > > > > > > > > > RBP: 83ee3ad0 R08: 0001 R09: > > > > > > > > > 0001 > > > > > > > > > R10: R11: 0246 R12: > > > > > > > > > 8881824aa0b0 > > > > > > > > > R13: 000865496000 R14: 000865496000 R15: > > > > > > > > > 88815d04 > > > > > > > > > ? xen_hypercall_xen_version+0xa/0x20 > > > > > > > > > ? xen_force_evtchn_callback+0x9/0x10 > > > > > > > > > ? check_events+0x12/0x20 > > > > > > > > > ? xen_restore_fl_direct+0x1f/0x20 > > > > > > > > > ? _raw_spin_unlock_irqrestore+0x53/0x60 > > > > > > > > > ? debug_dma_sync_single_for_cpu+0x91/0xc0 > > > > > > > > > ? _raw_spin_unlock_irqrestore+0x53/0x60 > > > > > > > > > ? xen_swiotlb_sync_single_for_cpu+0x3d/0x140 > > > > > > > > > ? mlx4_en_process_rx_cq+0x6b6/0x1110 [mlx4_en] > > > > > > > > > ? mlx4_en_poll_rx_cq+0x64/0x100 [mlx4_en] > > > > > > > > > ? net_rx_action+0x151/0x4a0 > > > > > > >
[PATCH 5.8 121/148] Fix build error when CONFIG_ACPI is not set/enabled:
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
acpi_noirq_set();
Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
Signed-off-by: Randy Dunlap
Reviewed-by: Juergen Gross
Cc: Andy Shevchenko
Cc: Bjorn Helgaas
Cc: Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xenproject.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
arch/x86/pci/xen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index e3f1ca3160684..db34fee931388 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
static int xen_pcifront_enable_irq(struct pci_dev *dev)
--
2.25.1
[PATCH 5.7 104/124] Fix build error when CONFIG_ACPI is not set/enabled:
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
acpi_noirq_set();
Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
Signed-off-by: Randy Dunlap
Reviewed-by: Juergen Gross
Cc: Andy Shevchenko
Cc: Bjorn Helgaas
Cc: Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xenproject.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
arch/x86/pci/xen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 91220cc258547..5c11ae66b5d8e 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
static int xen_pcifront_enable_irq(struct pci_dev *dev)
--
2.25.1
[PATCH 5.4 093/107] Fix build error when CONFIG_ACPI is not set/enabled:
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
acpi_noirq_set();
Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
Signed-off-by: Randy Dunlap
Reviewed-by: Juergen Gross
Cc: Andy Shevchenko
Cc: Bjorn Helgaas
Cc: Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xenproject.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
arch/x86/pci/xen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 91220cc258547..5c11ae66b5d8e 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
static int xen_pcifront_enable_irq(struct pci_dev *dev)
--
2.25.1
[PATCH 4.19 57/71] Fix build error when CONFIG_ACPI is not set/enabled:
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
acpi_noirq_set();
Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
Signed-off-by: Randy Dunlap
Reviewed-by: Juergen Gross
Cc: Andy Shevchenko
Cc: Bjorn Helgaas
Cc: Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xenproject.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
arch/x86/pci/xen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 9112d1cb397bb..22da9bfd8a458 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
static int xen_pcifront_enable_irq(struct pci_dev *dev)
--
2.25.1
Re: [RFC PATCH 10/13] staging: rts5280: Use always-managed version of pci_intx()
On Wed, Oct 09, 2024 at 10:35:16AM +0200, Philipp Stanner wrote: > pci_intx() is a hybrid function which can sometimes be managed through > devres. To remove this hybrid nature from pci_intx(), it is necessary to > port users to either an always-managed or a never-managed version. > > rts5208 enables its PCI-Device with pcim_enable_device(). Thus, it needs the > always-managed version. > > Replace pci_intx() with pcim_intx(). > > Signed-off-by: Philipp Stanner > --- > drivers/staging/rts5208/rtsx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Greg Kroah-Hartman
Re: [PATCH 13/13] PCI: Deprecate pci_intx(), pcim_intx()
On Tue, Oct 15, 2024 at 08:51:23PM +0200, Philipp Stanner wrote: > pci_intx() and its managed counterpart pcim_intx() only exist for older > drivers which have not been ported yet for various reasons. Future > drivers should preferably use pci_alloc_irq_vectors(). > > Mark pci_intx() and pcim_intx() as deprecated and encourage usage of > pci_alloc_irq_vectors() in its place. No one is going to notice these comments, so please, if this really does need to be removed, just remove it from all callers and delete the function from the tree. thanks, greg k-h
Re: [RFC PATCH 10/13] staging: rts5280: Use always-managed version of pci_intx()
On Thu, Oct 10, 2024 at 10:03:30AM +0200, Philipp Stanner wrote: > On Wed, 2024-10-09 at 21:41 +0200, Philipp Hortmann wrote: > > On 10/9/24 11:38, Greg Kroah-Hartman wrote: > > > On Wed, Oct 09, 2024 at 10:35:16AM +0200, Philipp Stanner wrote: > > > > pci_intx() is a hybrid function which can sometimes be managed > > > > through > > > > devres. To remove this hybrid nature from pci_intx(), it is > > > > necessary to > > > > port users to either an always-managed or a never-managed > > > > version. > > > > > > > > rts5208 enables its PCI-Device with pcim_enable_device(). Thus, > > > > it needs the > > > > always-managed version. > > > > > > > > Replace pci_intx() with pcim_intx(). > > > > > > > > Signed-off-by: Philipp Stanner > > > > --- > > > > drivers/staging/rts5208/rtsx.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Acked-by: Greg Kroah-Hartman > > > > > > > Hi Philipp, > > > > this driver (rts5208) will be removed soon - patch is send in. > > > > Discussion about removal: > > https://lore.kernel.org/linux-staging/2024100943-shank-washed-a765@gregkh/T/#t > > > Alright, thx for the heads up. > > I'm not entirely how best to deal with that, though. I could drop this > patch, but then the driver would end up with an unmanaged pci_intx(). > > Might this be a problem for users if my series lands sooner than the > removal, say in v6.13 and your removal in v6.14? The removal will happen in 6.13, I'm going to be queueing it up right now. thanks, greg k-h
Re: [PATCH] xen/usb: harden xen_hcd against malicious backends
On Fri, Mar 11, 2022 at 11:35:09AM +0100, Juergen Gross wrote: > Make sure a malicious backend can't cause any harm other than wrong > I/O data. > > Missing are verification of the request id in a response, sanitizing > the reported actual I/O length, and protection against interrupt storms > from the backend. > > Signed-off-by: Juergen Gross > --- > drivers/usb/host/xen-hcd.c | 57 -- > 1 file changed, 43 insertions(+), 14 deletions(-) Fails to apply to my tree: checking file drivers/usb/host/xen-hcd.c Hunk #2 succeeded at 720 (offset -1 lines). Hunk #3 succeeded at 807 (offset -3 lines). Hunk #4 succeeded at 934 (offset -5 lines). Hunk #5 FAILED at 986. Hunk #6 succeeded at 1003 with fuzz 1 (offset -10 lines). Hunk #7 succeeded at 1048 (offset -10 lines). Hunk #8 succeeded at 1072 (offset -10 lines). Hunk #9 succeeded at 1161 (offset -10 lines). Hunk #10 succeeded at 1516 (offset -10 lines). 1 out of 10 hunks FAILED Any hints? thanks, greg k-h
Re: [PATCH] xen/usb: harden xen_hcd against malicious backends
On Wed, Mar 16, 2022 at 06:29:00AM +0100, Juergen Gross wrote: > On 15.03.22 18:41, Greg Kroah-Hartman wrote: > > On Fri, Mar 11, 2022 at 11:35:09AM +0100, Juergen Gross wrote: > > > Make sure a malicious backend can't cause any harm other than wrong > > > I/O data. > > > > > > Missing are verification of the request id in a response, sanitizing > > > the reported actual I/O length, and protection against interrupt storms > > > from the backend. > > > > > > Signed-off-by: Juergen Gross > > > --- > > > drivers/usb/host/xen-hcd.c | 57 -- > > > 1 file changed, 43 insertions(+), 14 deletions(-) > > > > Fails to apply to my tree: > > > > checking file drivers/usb/host/xen-hcd.c > > Hunk #2 succeeded at 720 (offset -1 lines). > > Hunk #3 succeeded at 807 (offset -3 lines). > > Hunk #4 succeeded at 934 (offset -5 lines). > > Hunk #5 FAILED at 986. > > Hunk #6 succeeded at 1003 with fuzz 1 (offset -10 lines). > > Hunk #7 succeeded at 1048 (offset -10 lines). > > Hunk #8 succeeded at 1072 (offset -10 lines). > > Hunk #9 succeeded at 1161 (offset -10 lines). > > Hunk #10 succeeded at 1516 (offset -10 lines). > > 1 out of 10 hunks FAILED > > > > Any hints? > > Rebase your tree to v5.17-rc8? It is missing the recent security > patches which modified drivers/usb/host/xen-hcd.c. I can't rebase, but I can merge. I'll do that, thanks. greg k-h
Re: [PATCH 04/18] xen/usb: switch xen-hcd to use INVALID_GRANT_REF
On Wed, Apr 20, 2022 at 05:09:28PM +0200, Juergen Gross wrote: > Instead of using a private macro for an invalid grant reference use > the common one. > > Signed-off-by: Juergen Gross > --- > drivers/usb/host/xen-hcd.c | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) Acked-by: Greg Kroah-Hartman
Re: [PATCH 16/18] xen/usbfront: use xenbus_setup_ring() and xenbus_teardown_ring()
On Wed, Apr 20, 2022 at 05:09:40PM +0200, Juergen Gross wrote: > Simplify xen-hcd's ring creation and removal via xenbus_setup_ring() > and xenbus_teardown_ring(). > > Signed-off-by: Juergen Gross > --- > drivers/usb/host/xen-hcd.c | 55 +- > 1 file changed, 13 insertions(+), 42 deletions(-) Acked-by: Greg Kroah-Hartman
Re: [PATCH] drivers/xen: use helper macro __ATTR_RW
On Sat, Mar 05, 2022 at 09:38:23PM +0800, zhanglianjie wrote: > Use helper macro __ATTR_RW to define HYPERVISOR_ATTR_RW to make code more > clear. > Minor readability improvement. > > Signed-off-by: zhanglianjie Is this the name you sign legal documents with? (I have to ask...) > > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c > index feb1d16252e7..fcb0792f090e 100644 > --- a/drivers/xen/sys-hypervisor.c > +++ b/drivers/xen/sys-hypervisor.c > @@ -22,11 +22,10 @@ > #endif > > #define HYPERVISOR_ATTR_RO(_name) \ > -static struct hyp_sysfs_attr _name##_attr = __ATTR_RO(_name) > +static struct hyp_sysfs_attr _name##_attr = __ATTR_RO(_name) Why change this line? That's not relevant to this change :( thanks, greg k-h
Re: [PATCH] drivers/xen: use helper macro __ATTR_RW
On Sat, Mar 05, 2022 at 11:33:58PM +0800, zhanglianjie wrote: > Hi, > > 在 2022/3/5 21:55, Greg Kroah-Hartman 写道: > > On Sat, Mar 05, 2022 at 09:38:23PM +0800, zhanglianjie wrote: > > > Use helper macro __ATTR_RW to define HYPERVISOR_ATTR_RW to make code more > > > clear. > > > Minor readability improvement. > > > > > > Signed-off-by: zhanglianjie > > > > Is this the name you sign legal documents with? (I have to ask...) > Yes, this is my signature. > > > > > > > > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c > > > index feb1d16252e7..fcb0792f090e 100644 > > > --- a/drivers/xen/sys-hypervisor.c > > > +++ b/drivers/xen/sys-hypervisor.c > > > @@ -22,11 +22,10 @@ > > > #endif > > > > > > #define HYPERVISOR_ATTR_RO(_name) \ > > > -static struct hyp_sysfs_attr _name##_attr = __ATTR_RO(_name) > > > +static struct hyp_sysfs_attr _name##_attr = __ATTR_RO(_name) > > > > Why change this line? That's not relevant to this change :( > > > There are two spaces between struct hyp_sysfs_attr and _name, by the way, > modify it. Coding style cleanups should be a separate patch, as each change should only do one logical thing. But hey, I'm not the maintainer of this file/driver, others might be more lax. good luck! greg k-h
Re: Backport request
On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> Hi Greg,
>
> stable kernels 5.18 and 5.15 seem to be missing upstream patch
> c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
> This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
> error_entry() for XENPV"), which is included in 5.15.y and 5.18.y.
>
> Could you please take c64cc2802a78 for 5.15 and 5.18?
5.18 is end-of-life, so that's impossible to do now :(
For 5.15.y, the commit does not apply cleanly, can you provide a working
backport?
thanks,
greg k-h
Re: Backport request
On Wed, Aug 24, 2022 at 03:52:27PM +0200, Juergen Gross wrote:
> On 24.08.22 14:10, Greg Kroah-Hartman wrote:
> > On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> > > Hi Greg,
> > >
> > > stable kernels 5.18 and 5.15 seem to be missing upstream patch
> > > c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
> > > This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
> > > error_entry() for XENPV"), which is included in 5.15.y and 5.18.y.
> > >
> > > Could you please take c64cc2802a78 for 5.15 and 5.18?
> >
> > 5.18 is end-of-life, so that's impossible to do now :(
> >
> > For 5.15.y, the commit does not apply cleanly, can you provide a working
> > backport?
>
> Attached.
Thanks, now queued up.
greg k-h
Re: Backport of 166d38632316 ("xen/gntdev: Ignore failure to unmap INVALID_GRANT_HANDLE")
On Fri, Jul 22, 2022 at 11:44:10PM -0400, Demi Marie Obenour wrote: > This series backports upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f > to all supported stable kernel trees. All now queued up, thanks. greg k-h
Re: Backport of commit 3de218ff39b9e3f0d4
On Mon, Jul 05, 2021 at 01:58:09PM +0200, Juergen Gross wrote: > Hi Greg, > > the attached patch is a backport of upstream commit 3de218ff39b9e3f0d4 > for Linux 5.10 and older (I've checked it to apply down to 4.4). Now applied, thanks. greg k-h
Re: [PATCH v4 0/5] bus: Make remove callback return void
On Tue, Jul 13, 2021 at 09:35:17PM +0200, Uwe Kleine-König wrote: > Hello, > > this is v4 of the final patch set for my effort to make struct > bus_type::remove return void. > > The first four patches contain cleanups that make some of these > callbacks (more obviously) always return 0. They are acked by the > respective maintainers. Bjorn Helgaas explicitly asked to include the > pci patch (#1) into this series, so Greg taking this is fine. I assume > the s390 people are fine with Greg taking patches #2 to #4, too, they > didn't explicitly said so though. > > The last patch actually changes the prototype and so touches quite some > drivers and has the potential to conflict with future developments, so I > consider it beneficial to put these patches into next soon. I expect > that it will be Greg who takes the complete series, he already confirmed > via irc (for v2) to look into this series. > > The only change compared to v3 is in the fourth patch where I modified a > few more drivers to fix build failures. Some of them were found by build > bots (thanks!), some of them I found myself using a regular expression > search. The newly modified files are: > > arch/sparc/kernel/vio.c > drivers/nubus/bus.c > drivers/sh/superhyway/superhyway.c > drivers/vlynq/vlynq.c > drivers/zorro/zorro-driver.c > sound/ac97/bus.c > > Best regards > Uwe Now queued up. I can go make a git tag that people can pull from after 0-day is finished testing this to verify all is good, if others need it. thanks, greg k-h
Re: [PATCH v4 0/5] bus: Make remove callback return void
On Wed, Jul 21, 2021 at 12:09:41PM +0200, Greg Kroah-Hartman wrote: > On Tue, Jul 13, 2021 at 09:35:17PM +0200, Uwe Kleine-König wrote: > > Hello, > > > > this is v4 of the final patch set for my effort to make struct > > bus_type::remove return void. > > > > The first four patches contain cleanups that make some of these > > callbacks (more obviously) always return 0. They are acked by the > > respective maintainers. Bjorn Helgaas explicitly asked to include the > > pci patch (#1) into this series, so Greg taking this is fine. I assume > > the s390 people are fine with Greg taking patches #2 to #4, too, they > > didn't explicitly said so though. > > > > The last patch actually changes the prototype and so touches quite some > > drivers and has the potential to conflict with future developments, so I > > consider it beneficial to put these patches into next soon. I expect > > that it will be Greg who takes the complete series, he already confirmed > > via irc (for v2) to look into this series. > > > > The only change compared to v3 is in the fourth patch where I modified a > > few more drivers to fix build failures. Some of them were found by build > > bots (thanks!), some of them I found myself using a regular expression > > search. The newly modified files are: > > > > arch/sparc/kernel/vio.c > > drivers/nubus/bus.c > > drivers/sh/superhyway/superhyway.c > > drivers/vlynq/vlynq.c > > drivers/zorro/zorro-driver.c > > sound/ac97/bus.c > > > > Best regards > > Uwe > > Now queued up. I can go make a git tag that people can pull from after > 0-day is finished testing this to verify all is good, if others need it. Ok, here's a tag that any other subsystem can pull from if they want these changes in their tree before 5.15-rc1 is out. I might pull it into my char-misc-next tree as well just to keep that tree sane as it seems to pick up new busses on a regular basis... thanks, greg k-h --- The following changes since commit 2734d6c1b1a089fb593ef6a23d4b70903526fe0c: Linux 5.14-rc2 (2021-07-18 14:13:49 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/bus_remove_return_void-5.15 for you to fetch changes up to fc7a6209d5710618eb4f72a77cd81b8d694ecf89: bus: Make remove callback return void (2021-07-21 11:53:42 +0200) -------- Bus: Make remove callback return void tag Tag for other trees/branches to pull from in order to have a stable place to build off of if they want to add new busses for 5.15. Signed-off-by: Greg Kroah-Hartman Uwe Kleine-König (5): PCI: endpoint: Make struct pci_epf_driver::remove return void s390/cio: Make struct css_driver::remove return void s390/ccwgroup: Drop if with an always false condition s390/scm: Make struct scm_driver::remove return void bus: Make remove callback return void arch/arm/common/locomo.c | 3 +-- arch/arm/common/sa.c | 4 +--- arch/arm/mach-rpc/ecard.c | 4 +--- arch/mips/sgi-ip22/ip22-gio.c | 3 +-- arch/parisc/kernel/drivers.c | 5 ++--- arch/powerpc/platforms/ps3/system-bus.c | 3 +-- arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- arch/powerpc/platforms/pseries/vio.c | 3 +-- arch/s390/include/asm/eadm.h | 2 +- arch/sparc/kernel/vio.c | 4 +--- drivers/acpi/bus.c| 3 +-- drivers/amba/bus.c| 4 +--- drivers/base/auxiliary.c | 4 +--- drivers/base/isa.c| 4 +--- drivers/base/platform.c | 4 +--- drivers/bcma/main.c | 6 ++ drivers/bus/sunxi-rsb.c | 4 +--- drivers/cxl/core.c| 3 +-- drivers/dax/bus.c | 4 +--- drivers/dma/idxd/sysfs.c | 4 +--- drivers/firewire/core-device.c| 4 +--- drivers/firmware/arm_scmi/bus.c | 4 +--- drivers/firmware/google/coreboot_table.c | 4 +--- drivers/fpga/dfl.c| 4 +--- drivers/hid/hid-core.c| 4 +--- drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- drivers/hv/vmbus_drv.c| 5 + drivers/hwtracing/intel_th/core.c | 4 +--- drivers/i2c/i2c-core-base.c | 5 + drivers/i3c/master.c | 4 +--- drivers/input/gameport/gameport.c | 3 +-- drivers/input/serio/serio.c | 3 +-- drivers/ipack/ipack.c | 4 +--- drivers/macint
Re: [PATCH v1 0/5] PCI: Drop duplicated tracking of a pci_dev's bound driver
On Thu, Jul 29, 2021 at 10:37:35PM +0200, Uwe Kleine-König wrote: > Hello, > > struct pci_dev tracks the bound pci driver twice. This series is about > removing this duplication. > > The first two patches are just cleanups. The third patch introduces a > wrapper that abstracts access to struct pci_dev->driver. In the next > patch (hopefully) all users are converted to use the new wrapper and > finally the fifth patch removes the duplication. > > Note this series is only build tested (allmodconfig on several > architectures). > > I'm open to restructure this series if this simplifies things. E.g. the > use of the new wrapper in drivers/pci could be squashed into the patch > introducing the wrapper. Patch 4 could be split by maintainer tree or > squashed into patch 3 completely. > > Best regards > Uwe > > Uwe Kleine-König (5): > PCI: Simplify pci_device_remove() > PCI: Drop useless check from pci_device_probe() > PCI: Provide wrapper to access a pci_dev's bound driver > PCI: Adapt all code locations to not use struct pci_dev::driver > directly > PCI: Drop duplicated tracking of a pci_dev's bound driver Other than my objection to patch 5/5 lack of changelog, looks sane to me: Acked-by: Greg Kroah-Hartman
Re: Request for adding patch to stable-5.13
On Mon, Aug 16, 2021 at 01:09:52PM +0200, Juergen Gross wrote:
> Greg,
>
> could you please add upstream commit 05d69d950d9d8 ("xen-blkfront:
> sanitize the removal state machine") to the stable 5.13 kernel?
>
> The patch seems not to have a "Cc: stable" tag while it fixes an
> issue introduced in 5.13.
Please always cc: sta...@vger.kernel.org with these requests in the
future...
Anyway, the commit does not cleanly apply, so we will need a working
backport if you want to see it added to that tree.
thanks,
greg k-h
Re: [PATCH 5.4] xen-netback: move removal of "hotplug-status" to the right place
On Mon, Dec 19, 2022 at 04:37:10PM +0100, Pratyush Yadav wrote:
> The removal of "hotplug-status" has moved around a bit. First it was
> moved from netback_remove() to hotplug_status_changed() in upstream
> commit 1f2565780e9b ("xen-netback: remove 'hotplug-status' once it has
> served its purpose"). Then the change was reverted in upstream commit
> 0f4558ae9187 ("Revert "xen-netback: remove 'hotplug-status' once it has
> served its purpose""), but it moved the removal to backend_disconnect().
> Then the upstream commit c55f34b6aec2 ("xen-netback: only remove
> 'hotplug-status' when the vif is actually destroyed") moved it finally
> back to netback_remove(). The thing to note being it is removed
> unconditionally this time around.
>
> The story on v5.4.y adds to this confusion. Commit 60e4e3198ce8 ("Revert
> "xen-netback: remove 'hotplug-status' once it has served its purpose"")
> is backported to v5.4.y but the original commit that it tries to revert
> was never present on 5.4. So the backport incorrectly ends up just
> adding another xenbus_rm() of "hotplug-status" in backend_disconnect().
>
> Now in v5.4.y it is removed in both backend_disconnect() and
> netback_remove(). But it should only be removed in netback_remove(), as
> the upstream version does.
>
> Removing "hotplug-status" in backend_disconnect() causes problems when
> the frontend unilaterally disconnects, as explained in
> c55f34b6aec2 ("xen-netback: only remove 'hotplug-status' when the vif is
> actually destroyed").
>
> Remove "hotplug-status" in the same place as it is done on the upstream
> version to ensure unilateral re-connection of frontend continues to
> work.
>
> Fixes: 60e4e3198ce8 ("Revert "xen-netback: remove 'hotplug-status' once it
> has served its purpose"")
> Signed-off-by: Pratyush Yadav
> ---
> drivers/net/xen-netback/xenbus.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Now queued up, thanks.
greg k-h
[PATCH v2 14/16] xen/xenbus: move to_xenbus_device() to use container_of_const()
The driver core is changing to pass some pointers as const, so move
to_xenbus_device() to use container_of_const() to handle this change.
to_xenbus_device() now properly keeps the const-ness of the pointer passed
into it, while as before it could be lost.
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Oleksandr Tyshchenko
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Greg Kroah-Hartman
---
include/xen/xenbus.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index eaa932b99d8a..b31f77f9c50c 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -96,10 +96,7 @@ struct xenbus_device {
unsigned int spurious_threshold;
};
-static inline struct xenbus_device *to_xenbus_device(struct device *dev)
-{
- return container_of(dev, struct xenbus_device, dev);
-}
+#define to_xenbus_device(__dev)container_of_const(__dev, struct
xenbus_device, dev)
struct xenbus_device_id
{
--
2.39.0
Re: [PATCH 3/3] usb: xhci: Notify xen when DbC is unsafe to use
On Tue, May 11, 2021 at 06:18:21PM -0600, Connor Davis wrote: > When running as a dom0 guest on Xen, check if the USB3 debug > capability is enabled before xHCI reset, suspend, and resume. If it > is, call xen_dbgp_reset_prep() to notify Xen that it is unsafe to touch > MMIO registers until the next xen_dbgp_external_startup(). > > This notification allows Xen to avoid undefined behavior resulting > from MMIO access when the host controller's CNR bit is set or when > the device transitions to D3hot. > > Signed-off-by: Connor Davis > --- > drivers/usb/host/xhci-dbgcap.h | 6 > drivers/usb/host/xhci.c| 57 ++ > drivers/usb/host/xhci.h| 1 + > 3 files changed, 64 insertions(+) > > diff --git a/drivers/usb/host/xhci-dbgcap.h b/drivers/usb/host/xhci-dbgcap.h > index c70b78d504eb..24784b82a840 100644 > --- a/drivers/usb/host/xhci-dbgcap.h > +++ b/drivers/usb/host/xhci-dbgcap.h > @@ -227,4 +227,10 @@ static inline int xhci_dbc_resume(struct xhci_hcd *xhci) > return 0; > } > #endif /* CONFIG_USB_XHCI_DBGCAP */ > + > +#ifdef CONFIG_XEN_DOM0 > +int xen_dbgp_reset_prep(struct usb_hcd *hcd); > +int xen_dbgp_external_startup(struct usb_hcd *hcd); > +#endif /* CONFIG_XEN_DOM0 */ > + > #endif /* __LINUX_XHCI_DBGCAP_H */ > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index ca9385d22f68..afe44169183f 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -37,6 +37,57 @@ static unsigned long long quirks; > module_param(quirks, ullong, S_IRUGO); > MODULE_PARM_DESC(quirks, "Bit flags for quirks to be enabled as default"); > > +#ifdef CONFIG_XEN_DOM0 > +#include Can't this #ifdef stuff go into a .h file? thanks, greg k-h
Re: [PATCH 8/8] xen/hvc: replace BUG_ON() with negative return value
On Thu, May 13, 2021 at 12:03:02PM +0200, Juergen Gross wrote:
> Xen frontends shouldn't BUG() in case of illegal data received from
> their backends. So replace the BUG_ON()s when reading illegal data from
> the ring page with negative return values.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/tty/hvc/hvc_xen.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 92c9a476defc..30d7ffb1e04c 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -86,6 +86,11 @@ static int __write_console(struct xencons_info *xencons,
> cons = intf->out_cons;
> prod = intf->out_prod;
> mb(); /* update queue values before going on */
> +
> + if (WARN_ONCE((prod - cons) > sizeof(intf->out),
> + "Illegal ring page indices"))
> + return -EINVAL;
How nice, you just rebooted on panic-on-warn systems :(
> +
> BUG_ON((prod - cons) > sizeof(intf->out));
Why keep this line?
Please just fix this up properly, if userspace can trigger this, then
both the WARN_ON() and BUG_ON() are not correct and need to be correctly
handled.
>
> while ((sent < len) && ((prod - cons) < sizeof(intf->out)))
> @@ -114,7 +119,10 @@ static int domU_write_console(uint32_t vtermno, const
> char *data, int len)
>*/
> while (len) {
> int sent = __write_console(cons, data, len);
> -
> +
> + if (sent < 0)
> + return sent;
> +
> data += sent;
> len -= sent;
>
> @@ -138,7 +146,10 @@ static int domU_read_console(uint32_t vtermno, char
> *buf, int len)
> cons = intf->in_cons;
> prod = intf->in_prod;
> mb(); /* get pointers before reading ring */
> - BUG_ON((prod - cons) > sizeof(intf->in));
> +
> + if (WARN_ONCE((prod - cons) > sizeof(intf->in),
> + "Illegal ring page indices"))
> + return -EINVAL;
Same here, you still just paniced a machine :(
thanks,
greg k-h
Re: [PATCH v2 0/4] Support xen-driven USB3 debug capability
On Thu, May 13, 2021 at 06:56:47PM -0600, Connor Davis wrote: > Hi all, > > This goal of this series is to allow the USB3 debug capability (DbC) to be > safely used by xen while linux runs as dom0. Patch 2/4 does not seem to be showing up anywhere, did it get lost? thanks, greg k-h
Re: [PATCH 5.10] x86/xen: Drop USERGS_SYSRET64 paravirt call
On Wed, May 22, 2024 at 06:20:15PM -0700, Pawan Gupta wrote: > From: Juergen Gross > > commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream. Now queued up, thanks. greg k-h
Re: [PATCH v7 0/9] Allow dynamic allocation of software IO TLB bounce buffers
nel was booted with "swiotlb=force" to allow stress-testing > the software IO TLB on a high-performance device that would otherwise not > need it. CONFIG_DEBUG_FS was set to 'y' to match the configuration of > popular distribution kernels; it is understood that parallel workloads > suffer from contention on the recently added debugfs atomic counters. > > These benchmarks were run: > > - small: single-threaded I/O of 4 KiB blocks, > - big: single-threaded I/O of 64 KiB blocks, > - 4way: 4-way parallel I/O of 4 KiB blocks. > > In all tested cases, the default 64 MiB SWIOTLB would be sufficient (but > wasteful). The "default" pair of columns shows performance impact when > booted with 64 MiB SWIOTLB (i.e. current state). The "growing" pair of > columns shows the impact when booted with a 1 MiB initial SWIOTLB, which > grew to 5 MiB at run time. The "var" column in the tables below is the > coefficient of variance over 5 runs of the test, the "diff" column is the > difference in read-write I/O bandwidth (MiB/s). The very first column is > the coefficient of variance in the results of the base unpatched kernel. > > First, on an x86 VM against a QEMU virtio SATA driver backed by a RAM-based > block device on the host: > > base default growing > var var diffvar diff > small 1.96% 0.47% -1.5% 0.52% -2.2% > big 2.03% 1.35% +0.9% 2.22% +2.9% > 4way 0.80% 0.45% -0.7% 1.22% <0.1% > > Second, on a Raspberry Pi4 with 8G RAM and a class 10 A1 microSD card: > > base default growing > var var diffvar diff > small 1.09% 1.69% +0.5% 2.14% -0.2% > big 0.03% 0.28% -0.5% 0.03% -0.1% > 4way 5.15% 2.39% +0.2% 0.66% <0.1% > > Third, on a CoCo VM. This was a bigger system, so I also added a 24-thread > parallel I/O test: > > base default growing > var var diffvar diff > small 2.41% 6.02% +1.1% 10.33% +6.7% > big 9.20% 2.81% -0.6% 16.84% -0.2% > 4way 0.86% 2.66% -0.1%2.22% -4.9% > 24way 3.19% 6.19% +4.4%4.08% -5.9% > > Note the increased variance of the CoCo VM, although the host was not > otherwise loaded. These are caused by the first run, which includes the > overhead of allocating additional bounce buffers and sharing them with the > hypervisor. The system was not rebooted between successive runs. > > Parallel tests suffer from a reduced number of areas in the dynamically > allocated memory pools. This can be improved by allocating a larger pool > from CMA (not implemented in this series yet). > > I have no good explanation for the increase in performance of the > 24-thread I/O test with the default (non-growing) memory pool. Although the > difference is within variance, it seems to be real. The average bandwidth > is consistently above that of the unpatched kernel. > > To sum it up: > > - All workloads benefit from reduced memory footprint. > - No performance regressions have been observed with the default size of > the software IO TLB. > - Most workloads retain their former performance even if the software IO > TLB grows at run time. > For the driver-core touched portions: Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 08/11] sysctl: Add size to register_sysctl_init
On Wed, Jun 21, 2023 at 11:09:57AM +0200, Joel Granados wrote:
> static int __init random_sysctls_init(void)
> {
> - register_sysctl_init("kernel/random", random_table);
> + register_sysctl_init("kernel/random", random_table,
> + ARRAY_SIZE(random_table));
As mentioned before, why not just do:
#define register_sysctl_init(string, table) \
__register_sysctl_init(string, table, ARRAY_SIZE(table);
or something like that?
That way no callers need to change AND you prevent the size from ever
being incorrect?
thanks,
greg k-h
Re: [PATCH v3 1/7] swiotlb: make io_tlb_default_mem local to swiotlb.c
On Tue, Jun 27, 2023 at 11:54:23AM +0200, Petr Tesarik wrote:
> +/**
> + * is_swiotlb_active() - check if the software IO TLB is initialized
> + * @dev: Device to check, or %NULL for the default IO TLB.
> + */
> bool is_swiotlb_active(struct device *dev)
> {
> - struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> + struct io_tlb_mem *mem = dev
> + ? dev->dma_io_tlb_mem
> + : &io_tlb_default_mem;
That's impossible to read and maintain over time, sorry.
Please use real "if () else" lines, so that it can be maintained over
time.
thanks,
greg k-h
Re: [PATCH v3 4/7] swiotlb: if swiotlb is full, fall back to a transient memory pool
On Thu, Jul 06, 2023 at 03:50:55AM +, Michael Kelley (LINUX) wrote: > From: Petr Tesarik Sent: Tuesday, June 27, 2023 > 2:54 AM > > > > Try to allocate a transient memory pool if no suitable slots can be found, > > except when allocating from a restricted pool. The transient pool is just > > enough big for this one bounce buffer. It is inserted into a per-device > > list of transient memory pools, and it is freed again when the bounce > > buffer is unmapped. > > > > Transient memory pools are kept in an RCU list. A memory barrier is > > required after adding a new entry, because any address within a transient > > buffer must be immediately recognized as belonging to the SWIOTLB, even if > > it is passed to another CPU. > > > > Deletion does not require any synchronization beyond RCU ordering > > guarantees. After a buffer is unmapped, its physical addresses may no > > longer be passed to the DMA API, so the memory range of the corresponding > > stale entry in the RCU list never matches. If the memory range gets > > allocated again, then it happens only after a RCU quiescent state. > > > > Since bounce buffers can now be allocated from different pools, add a > > parameter to swiotlb_alloc_pool() to let the caller know which memory pool > > is used. Add swiotlb_find_pool() to find the memory pool corresponding to > > an address. This function is now also used by is_swiotlb_buffer(), because > > a simple boundary check is no longer sufficient. > > > > The logic in swiotlb_alloc_tlb() is taken from __dma_direct_alloc_pages(), > > simplified and enhanced to use coherent memory pools if needed. > > > > Note that this is not the most efficient way to provide a bounce buffer, > > but when a DMA buffer can't be mapped, something may (and will) actually > > break. At that point it is better to make an allocation, even if it may be > > an expensive operation. > > I continue to think about swiotlb memory management from the standpoint > of CoCo VMs that may be quite large with high network and storage loads. > These VMs are often running mission-critical workloads that can't tolerate > a bounce buffer allocation failure. To prevent such failures, the swiotlb > memory size must be overly large, which wastes memory. If "mission critical workloads" are in a vm that allowes overcommit and no control over other vms in that same system, then you have worse problems, sorry. Just don't do that. thanks, greg k-h
Re: [PATCH v3 4/7] swiotlb: if swiotlb is full, fall back to a transient memory pool
On Thu, Jul 06, 2023 at 02:22:50PM +, Michael Kelley (LINUX) wrote: > From: Greg Kroah-Hartman Sent: Thursday, July 6, > 2023 1:07 AM > > > > On Thu, Jul 06, 2023 at 03:50:55AM +, Michael Kelley (LINUX) wrote: > > > From: Petr Tesarik Sent: Tuesday, June 27, > > > 2023 > > 2:54 AM > > > > > > > > Try to allocate a transient memory pool if no suitable slots can be > > > > found, > > > > except when allocating from a restricted pool. The transient pool is > > > > just > > > > enough big for this one bounce buffer. It is inserted into a per-device > > > > list of transient memory pools, and it is freed again when the bounce > > > > buffer is unmapped. > > > > > > > > Transient memory pools are kept in an RCU list. A memory barrier is > > > > required after adding a new entry, because any address within a > > > > transient > > > > buffer must be immediately recognized as belonging to the SWIOTLB, even > > > > if > > > > it is passed to another CPU. > > > > > > > > Deletion does not require any synchronization beyond RCU ordering > > > > guarantees. After a buffer is unmapped, its physical addresses may no > > > > longer be passed to the DMA API, so the memory range of the > > > > corresponding > > > > stale entry in the RCU list never matches. If the memory range gets > > > > allocated again, then it happens only after a RCU quiescent state. > > > > > > > > Since bounce buffers can now be allocated from different pools, add a > > > > parameter to swiotlb_alloc_pool() to let the caller know which memory > > > > pool > > > > is used. Add swiotlb_find_pool() to find the memory pool corresponding > > > > to > > > > an address. This function is now also used by is_swiotlb_buffer(), > > > > because > > > > a simple boundary check is no longer sufficient. > > > > > > > > The logic in swiotlb_alloc_tlb() is taken from > > > > __dma_direct_alloc_pages(), > > > > simplified and enhanced to use coherent memory pools if needed. > > > > > > > > Note that this is not the most efficient way to provide a bounce buffer, > > > > but when a DMA buffer can't be mapped, something may (and will) actually > > > > break. At that point it is better to make an allocation, even if it may > > > > be > > > > an expensive operation. > > > > > > I continue to think about swiotlb memory management from the standpoint > > > of CoCo VMs that may be quite large with high network and storage loads. > > > These VMs are often running mission-critical workloads that can't tolerate > > > a bounce buffer allocation failure. To prevent such failures, the swiotlb > > > memory size must be overly large, which wastes memory. > > > > If "mission critical workloads" are in a vm that allowes overcommit and > > no control over other vms in that same system, then you have worse > > problems, sorry. > > > > Just don't do that. > > > > No, the cases I'm concerned about don't involve memory overcommit. > > CoCo VMs must use swiotlb bounce buffers to do DMA I/O. Current swiotlb > code in the Linux guest allocates a configurable, but fixed, amount of guest > memory at boot time for this purpose. But it's hard to know how much > swiotlb bounce buffer memory will be needed to handle peak I/O loads. > This patch set does dynamic allocation of swiotlb bounce buffer memory, > which can help avoid needing to configure an overly large fixed size at boot. But, as you point out, memory allocation can fail at runtime, so how can you "guarantee" that this will work properly anymore if you are going to make it dynamic? confused, greg k-h
Re: [PATCH v2 1/3] hvc/xen: fix event channel handling for secondary consoles
On Fri, Oct 20, 2023 at 05:15:27PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The xencons_connect_backend() function allocates a local interdomain
> event channel with xenbus_alloc_evtchn(), then calls
> bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
> *remote* domain.
>
> That doesn't work very well:
>
> (qemu) device_add xen-console,id=con1,chardev=pty0
> [ 44.323872] xenconsole console-1: 2 xenbus_dev_probe on device/console/1
> [ 44.323995] xenconsole: probe of console-1 failed with error -2
>
> Fix it to use bind_evtchn_to_irq_lateeoi(), which does the right thing
> by just binding that *local* event channel to an irq. The backend will
> do the interdomain binding.
>
> This didn't affect the primary console because the setup for that is
> special — the toolstack allocates the guest event channel and the guest
> discovers it with HVMOP_get_param.
>
> Fixes: fe415186b4 ("xen/console: harden hvc_xen against event channel storms")
Nit, our tools complain that the sha1 isn't big enough, "fe415186b43d"
I'll go fix it up...
[PATCH 5.4 10/18] x86/asm: Allow to pass macros to __ASM_FORM()
From: Masami Hiramatsu commit f7919fd943abf0c77aed4441ea9897a323d132f5 upstream. Use __stringify() at __ASM_FORM() so that user can pass code including macros to __ASM_FORM(). Signed-off-by: Masami Hiramatsu Signed-off-by: Peter Zijlstra (Intel) Cc: Juergen Gross Cc: x...@kernel.org Cc: Boris Ostrovsky Cc: Ingo Molnar Cc: Stefano Stabellini Cc: Andrew Cooper Cc: Borislav Petkov Cc: xen-devel@lists.xenproject.org Cc: Randy Dunlap Cc: Josh Poimboeuf Link: https://lkml.kernel.org/r/156777562873.25081.2288083344657460959.stgit@devnote2 Signed-off-by: Maximilian Heyne Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/asm.h |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/arch/x86/include/asm/asm.h +++ b/arch/x86/include/asm/asm.h @@ -7,9 +7,11 @@ # define __ASM_FORM_RAW(x) x # define __ASM_FORM_COMMA(x) x, #else -# define __ASM_FORM(x) " " #x " " -# define __ASM_FORM_RAW(x) #x -# define __ASM_FORM_COMMA(x) " " #x "," +#include + +# define __ASM_FORM(x) " " __stringify(x) " " +# define __ASM_FORM_RAW(x) __stringify(x) +# define __ASM_FORM_COMMA(x) " " __stringify(x) "," #endif #ifndef __x86_64__
[PATCH 5.4 11/18] x86: xen: kvm: Gather the definition of emulate prefixes
From: Masami Hiramatsu
commit b3dc0695fa40c3b280230fb6fb7fb7a94ce28bf4 upstream.
Gather the emulate prefixes, which forcibly make the following
instruction emulated on virtualization, in one place.
Suggested-by: Peter Zijlstra
Signed-off-by: Masami Hiramatsu
Signed-off-by: Peter Zijlstra (Intel)
Cc: Juergen Gross
Cc: x...@kernel.org
Cc: Ingo Molnar
Cc: Boris Ostrovsky
Cc: Andrew Cooper
Cc: Stefano Stabellini
Cc: Borislav Petkov
Cc: xen-devel@lists.xenproject.org
Cc: Randy Dunlap
Cc: Josh Poimboeuf
Link:
https://lkml.kernel.org/r/156777563917.25081.7286628561790289995.stgit@devnote2
Signed-off-by: Maximilian Heyne
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/emulate_prefix.h | 14 ++
arch/x86/include/asm/xen/interface.h | 11 ---
arch/x86/kvm/x86.c|4 +++-
3 files changed, 21 insertions(+), 8 deletions(-)
create mode 100644 arch/x86/include/asm/emulate_prefix.h
--- /dev/null
+++ b/arch/x86/include/asm/emulate_prefix.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_EMULATE_PREFIX_H
+#define _ASM_X86_EMULATE_PREFIX_H
+
+/*
+ * Virt escape sequences to trigger instruction emulation;
+ * ideally these would decode to 'whole' instruction and not destroy
+ * the instruction stream; sadly this is not true for the 'kvm' one :/
+ */
+
+#define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e /* ud2 ; .ascii "xen"
*/
+#define __KVM_EMULATE_PREFIX 0x0f,0x0b,0x6b,0x76,0x6d /* ud2 ; .ascii "kvm" */
+
+#endif
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -379,12 +379,9 @@ struct xen_pmu_arch {
* Prefix forces emulation of some non-trapping instructions.
* Currently only CPUID.
*/
-#ifdef __ASSEMBLY__
-#define XEN_EMULATE_PREFIX .byte 0x0f,0x0b,0x78,0x65,0x6e ;
-#define XEN_CPUID XEN_EMULATE_PREFIX cpuid
-#else
-#define XEN_EMULATE_PREFIX ".byte 0x0f,0x0b,0x78,0x65,0x6e ; "
-#define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
-#endif
+#include
+
+#define XEN_EMULATE_PREFIX __ASM_FORM(.byte __XEN_EMULATE_PREFIX ;)
+#define XEN_CPUID XEN_EMULATE_PREFIX __ASM_FORM(cpuid)
#endif /* _ASM_X86_XEN_INTERFACE_H */
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -68,6 +68,7 @@
#include
#include
#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -5583,6 +5584,7 @@ EXPORT_SYMBOL_GPL(kvm_write_guest_virt_s
int handle_ud(struct kvm_vcpu *vcpu)
{
+ static const char kvm_emulate_prefix[] = { __KVM_EMULATE_PREFIX };
int emul_type = EMULTYPE_TRAP_UD;
char sig[5]; /* ud2; .ascii "kvm" */
struct x86_exception e;
@@ -5590,7 +5592,7 @@ int handle_ud(struct kvm_vcpu *vcpu)
if (force_emulation_prefix &&
kvm_read_guest_virt(vcpu, kvm_get_linear_rip(vcpu),
sig, sizeof(sig), &e) == 0 &&
- memcmp(sig, "\xf\xbkvm", sizeof(sig)) == 0) {
+ memcmp(sig, kvm_emulate_prefix, sizeof(sig)) == 0) {
kvm_rip_write(vcpu, kvm_rip_read(vcpu) + sizeof(sig));
emul_type = EMULTYPE_TRAP_UD_FORCED;
}
[PATCH 5.4 12/18] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
From: Masami Hiramatsu
commit 4d65adfcd1196818659d3bd9b42dccab291e1751 upstream.
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder.
It is called "prefix" but actually not x86 instruction prefix, so
this adds insn.emulate_prefix_size field instead of reusing
insn.prefixes.
If x86 decoder finds a special sequence of instructions of
XEN_EMULATE_PREFIX and 'ud2a; .ascii "kvm"', it just counts the
length, set insn.emulate_prefix_size and fold it with the next
instruction. In other words, the signature and the next instruction
is treated as a single instruction.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Josh Poimboeuf
Cc: Juergen Gross
Cc: x...@kernel.org
Cc: Boris Ostrovsky
Cc: Ingo Molnar
Cc: Stefano Stabellini
Cc: Andrew Cooper
Cc: Borislav Petkov
Cc: xen-devel@lists.xenproject.org
Cc: Randy Dunlap
Link:
https://lkml.kernel.org/r/156777564986.25081.4964537658500952557.stgit@devnote2
[mheyne: resolved contextual conflict in tools/objtools/sync-check.sh]
Signed-off-by: Maximilian Heyne
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/insn.h |6
arch/x86/lib/insn.c | 34
tools/arch/x86/include/asm/emulate_prefix.h | 14 +++
tools/arch/x86/include/asm/insn.h |6
tools/arch/x86/lib/insn.c | 34
tools/objtool/sync-check.sh |3 +-
tools/perf/check-headers.sh |3 +-
7 files changed, 98 insertions(+), 2 deletions(-)
create mode 100644 tools/arch/x86/include/asm/emulate_prefix.h
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -45,6 +45,7 @@ struct insn {
struct insn_field immediate2; /* for 64bit imm or seg16 */
};
+ int emulate_prefix_size;
insn_attr_t attr;
unsigned char opnd_bytes;
unsigned char addr_bytes;
@@ -128,6 +129,11 @@ static inline int insn_is_evex(struct in
return (insn->vex_prefix.nbytes == 4);
}
+static inline int insn_has_emulate_prefix(struct insn *insn)
+{
+ return !!insn->emulate_prefix_size;
+}
+
/* Ensure this instruction is decoded completely */
static inline int insn_complete(struct insn *insn)
{
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -13,6 +13,8 @@
#include
#include
+#include
+
/* Verify next sizeof(t) bytes can be on the same instruction */
#define validate_next(t, insn, n) \
((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr)
@@ -58,6 +60,36 @@ void insn_init(struct insn *insn, const
insn->addr_bytes = 4;
}
+static const insn_byte_t xen_prefix[] = { __XEN_EMULATE_PREFIX };
+static const insn_byte_t kvm_prefix[] = { __KVM_EMULATE_PREFIX };
+
+static int __insn_get_emulate_prefix(struct insn *insn,
+const insn_byte_t *prefix, size_t len)
+{
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ if (peek_nbyte_next(insn_byte_t, insn, i) != prefix[i])
+ goto err_out;
+ }
+
+ insn->emulate_prefix_size = len;
+ insn->next_byte += len;
+
+ return 1;
+
+err_out:
+ return 0;
+}
+
+static void insn_get_emulate_prefix(struct insn *insn)
+{
+ if (__insn_get_emulate_prefix(insn, xen_prefix, sizeof(xen_prefix)))
+ return;
+
+ __insn_get_emulate_prefix(insn, kvm_prefix, sizeof(kvm_prefix));
+}
+
/**
* insn_get_prefixes - scan x86 instruction prefix bytes
* @insn: &struct insn containing instruction
@@ -76,6 +108,8 @@ void insn_get_prefixes(struct insn *insn
if (prefixes->got)
return;
+ insn_get_emulate_prefix(insn);
+
nb = 0;
lb = 0;
b = peek_next(insn_byte_t, insn);
--- /dev/null
+++ b/tools/arch/x86/include/asm/emulate_prefix.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_EMULATE_PREFIX_H
+#define _ASM_X86_EMULATE_PREFIX_H
+
+/*
+ * Virt escape sequences to trigger instruction emulation;
+ * ideally these would decode to 'whole' instruction and not destroy
+ * the instruction stream; sadly this is not true for the 'kvm' one :/
+ */
+
+#define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e /* ud2 ; .ascii "xen"
*/
+#define __KVM_EMULATE_PREFIX 0x0f,0x0b,0x6b,0x76,0x6d /* ud2 ; .ascii "kvm" */
+
+#endif
--- a/tools/arch/x86/include/asm/insn.h
+++ b/tools/arch/x86/include/asm/insn.h
@@ -45,6 +45,7 @@ struct insn {
struct insn_field immediate2; /* for 64bit imm or seg16 */
};
+ int emulate_prefix_size;
insn_attr_t attr;
unsigned char opnd_bytes;
unsigned char addr_bytes;
@@ -128,6 +129,11 @@ static inline int insn_is_evex(struct in
return (insn->vex_
[PATCH 5.4 13/18] x86: kprobes: Prohibit probing on instruction which has emulate prefix
From: Masami Hiramatsu commit 004e8dce9c5595697951f7cd0e9f66b35c92265e upstream. Prohibit probing on instruction which has XEN_EMULATE_PREFIX or KVM's emulate prefix. Since that prefix is a marker for Xen and KVM, if we modify the marker by kprobe's int3, that doesn't work as expected. Signed-off-by: Masami Hiramatsu Signed-off-by: Peter Zijlstra (Intel) Cc: Juergen Gross Cc: x...@kernel.org Cc: Boris Ostrovsky Cc: Ingo Molnar Cc: Stefano Stabellini Cc: Andrew Cooper Cc: Borislav Petkov Cc: xen-devel@lists.xenproject.org Cc: Randy Dunlap Cc: Josh Poimboeuf Link: https://lkml.kernel.org/r/156777566048.25081.6296162369492175325.stgit@devnote2 Signed-off-by: Maximilian Heyne Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/kprobes/core.c |4 1 file changed, 4 insertions(+) --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -358,6 +358,10 @@ int __copy_instruction(u8 *dest, u8 *src kernel_insn_init(insn, dest, MAX_INSN_SIZE); insn_get_length(insn); + /* We can not probe force emulate prefixed instruction */ + if (insn_has_emulate_prefix(insn)) + return 0; + /* Another subsystem puts a breakpoint, failed to recover */ if (insn->opcode.bytes[0] == BREAKPOINT_INSTRUCTION) return 0;
Re: Patches for stable 5.10 kernel
On Mon, Nov 29, 2021 at 08:19:18AM +0100, Juergen Gross wrote:
> Hi Greg,
>
> could you please add the following upstream patches to the stable 5.10
> kernel (I'll send separate mails for the older stable kernels as some
> of the patches don't apply for those)? They are hardening Xen PV
> frontends against attacks from related backends.
>
> Qubes-OS has asked for those patches to be added to stable, too.
>
> 629a5d87e26fe96b ("xen: sync include/xen/interface/io/ring.h with Xen's
> newest version")
> 71b66243f9898d0e ("xen/blkfront: read response from backend only once")
> 8f5a695d99000fc3 ("xen/blkfront: don't take local copy of a request from the
> ring page")
> b94e4b147fd1992a ("xen/blkfront: don't trust the backend response data
> blindly")
> 8446066bf8c1f9f7 ("xen/netfront: read response from backend only once")
> 162081ec33c2686a ("xen/netfront: don't read data from request on the ring
> page")
> 21631d2d741a64a0 ("xen/netfront: disentangle tx_skb_freelist")
> a884daa61a7d9165 ("xen/netfront: don't trust the backend response data
> blindly")
> e679004dec37566f ("tty: hvc: replace BUG_ON() with negative return value")
>
All now queued up, thanks.
But people should be moving to the 5.15 kernel by now and not sticking
with 5.10 anymore for stuff like this.
greg k-h
Re: Stable backports of Xen related patches
On Mon, Nov 29, 2021 at 04:15:31PM +0100, Juergen Gross wrote: > Hi Greg, > > attached are git bundles for some patches you merged into the 5.10 > stable kernel already this morning. > > Naming should be obvious, the patches are on the branch "back" in > each bundle. All now queued up, thanks! greg k-h
