From 415dab3c179632d098aadc756b39cebceb977978 Mon Sep 17 00:00:00 2001 From: Per Bilse Date: Tue, 3 Jan 2023 13:02:13 +0000 Subject: [PATCH 01/10] drivers/xen/hypervisor: Expose Xen SIF flags to userspace /proc/xen is a legacy pseudo filesystem which predates Xen support getting merged into Linux. It has largely been replaced with more normal locations for data (/sys/hypervisor/ for info, /dev/xen/ for user devices). We want to compile xenfs support out of the dom0 kernel. There is one item which only exists in /proc/xen, namely /proc/xen/capabilities with "control_d" being the signal of "you're in the control domain". This ultimately comes from the SIF flags provided at VM start. This patch exposes all SIF flags in /sys/hypervisor/start_flags/ as boolean files, one for each bit, returning '1' if set, '0' otherwise. Two known flags, 'privileged' and 'initdomain', are explicitly named, and all remaining flags can be accessed via generically named files, as suggested by Andrew Cooper. Signed-off-by: Per Bilse Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20230103130213.2129753-1-per.bilse@citrix.com Signed-off-by: Juergen Gross --- Documentation/ABI/stable/sysfs-hypervisor-xen | 13 ++++ drivers/xen/sys-hypervisor.c | 69 +++++++++++++++++-- 2 files changed, 78 insertions(+), 4 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-hypervisor-xen b/Documentation/ABI/stable/sysfs-hypervisor-xen index 748593c64568..be9ca9981bb1 100644 --- a/Documentation/ABI/stable/sysfs-hypervisor-xen +++ b/Documentation/ABI/stable/sysfs-hypervisor-xen @@ -120,3 +120,16 @@ Contact: xen-devel@lists.xenproject.org Description: If running under Xen: The Xen version is in the format . This is the part of it. + +What: /sys/hypervisor/start_flags/* +Date: March 2023 +KernelVersion: 6.3.0 +Contact: xen-devel@lists.xenproject.org +Description: If running under Xen: + All bits in Xen's start-flags are represented as + boolean files, returning '1' if set, '0' otherwise. + This takes the place of the defunct /proc/xen/capabilities, + which would contain "control_d" on dom0, and be empty + otherwise. This flag is now exposed as "initdomain" in + addition to the "privileged" flag; all other possible flags + are accessible as "unknownXX". diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c index fcb0792f090e..ca092db8f498 100644 --- a/drivers/xen/sys-hypervisor.c +++ b/drivers/xen/sys-hypervisor.c @@ -31,7 +31,10 @@ struct hyp_sysfs_attr { struct attribute attr; ssize_t (*show)(struct hyp_sysfs_attr *, char *); ssize_t (*store)(struct hyp_sysfs_attr *, const char *, size_t); - void *hyp_attr_data; + union { + void *hyp_attr_data; + unsigned long hyp_attr_value; + }; }; static ssize_t type_show(struct hyp_sysfs_attr *attr, char *buffer) @@ -399,6 +402,60 @@ static int __init xen_sysfs_properties_init(void) return sysfs_create_group(hypervisor_kobj, &xen_properties_group); } +#define FLAG_UNAME "unknown" +#define FLAG_UNAME_FMT FLAG_UNAME "%02u" +#define FLAG_UNAME_MAX sizeof(FLAG_UNAME "XX") +#define FLAG_COUNT (sizeof(xen_start_flags) * BITS_PER_BYTE) +static_assert(sizeof(xen_start_flags) <= + sizeof_field(struct hyp_sysfs_attr, hyp_attr_value)); + +static ssize_t flag_show(struct hyp_sysfs_attr *attr, char *buffer) +{ + char *p = buffer; + + *p++ = '0' + ((xen_start_flags & attr->hyp_attr_value) != 0); + *p++ = '\n'; + return p - buffer; +} + +#define FLAG_NODE(flag, node) \ + [ilog2(flag)] = { \ + .attr = { .name = #node, .mode = 0444 },\ + .show = flag_show, \ + .hyp_attr_value = flag \ + } + +/* + * Add new, known flags here. No other changes are required, but + * note that each known flag wastes one entry in flag_unames[]. + * The code/complexity machinations to avoid this isn't worth it + * for a few entries, but keep it in mind. + */ +static struct hyp_sysfs_attr flag_attrs[FLAG_COUNT] = { + FLAG_NODE(SIF_PRIVILEGED, privileged), + FLAG_NODE(SIF_INITDOMAIN, initdomain) +}; +static struct attribute_group xen_flags_group = { + .name = "start_flags", + .attrs = (struct attribute *[FLAG_COUNT + 1]){} +}; +static char flag_unames[FLAG_COUNT][FLAG_UNAME_MAX]; + +static int __init xen_sysfs_flags_init(void) +{ + for (unsigned fnum = 0; fnum != FLAG_COUNT; fnum++) { + if (likely(flag_attrs[fnum].attr.name == NULL)) { + sprintf(flag_unames[fnum], FLAG_UNAME_FMT, fnum); + flag_attrs[fnum].attr.name = flag_unames[fnum]; + flag_attrs[fnum].attr.mode = 0444; + flag_attrs[fnum].show = flag_show; + flag_attrs[fnum].hyp_attr_value = 1 << fnum; + } + xen_flags_group.attrs[fnum] = &flag_attrs[fnum].attr; + } + return sysfs_create_group(hypervisor_kobj, &xen_flags_group); +} + #ifdef CONFIG_XEN_HAVE_VPMU struct pmu_mode { const char *name; @@ -539,18 +596,22 @@ static int __init hyper_sysfs_init(void) ret = xen_sysfs_properties_init(); if (ret) goto prop_out; + ret = xen_sysfs_flags_init(); + if (ret) + goto flags_out; #ifdef CONFIG_XEN_HAVE_VPMU if (xen_initial_domain()) { ret = xen_sysfs_pmu_init(); if (ret) { - sysfs_remove_group(hypervisor_kobj, - &xen_properties_group); - goto prop_out; + sysfs_remove_group(hypervisor_kobj, &xen_flags_group); + goto flags_out; } } #endif goto out; +flags_out: + sysfs_remove_group(hypervisor_kobj, &xen_properties_group); prop_out: sysfs_remove_file(hypervisor_kobj, &uuid_attr.attr); uuid_out: From 336f560a8917fd60bcdb71b97263257611411453 Mon Sep 17 00:00:00 2001 From: Juergen Gross Date: Fri, 25 Nov 2022 07:32:47 +0100 Subject: [PATCH 02/10] x86/xen: don't let xen_pv_play_dead() return A function called via the paravirt play_dead() hook should not return to the caller. xen_pv_play_dead() has a problem in this regard, as it currently will return in case an offlined cpu is brought to life again. This can be changed only by doing basically a longjmp() to cpu_bringup_and_idle(), as the hypercall for bringing down the cpu will just return when the cpu is coming up again. Just re-initializing the cpu isn't possible, as the Xen hypervisor will deny that operation. So introduce xen_cpu_bringup_again() resetting the stack and calling cpu_bringup_and_idle(), which can be called after HYPERVISOR_vcpu_op() in xen_pv_play_dead(). Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20221125063248.30256-2-jgross@suse.com Signed-off-by: Juergen Gross --- arch/x86/xen/smp.h | 2 ++ arch/x86/xen/smp_pv.c | 13 ++----------- arch/x86/xen/xen-head.S | 7 +++++++ 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h index bd02f9d50107..6e90a312067b 100644 --- a/arch/x86/xen/smp.h +++ b/arch/x86/xen/smp.h @@ -21,6 +21,8 @@ void xen_smp_send_reschedule(int cpu); void xen_smp_send_call_function_ipi(const struct cpumask *mask); void xen_smp_send_call_function_single_ipi(int cpu); +void xen_cpu_bringup_again(unsigned long stack); + struct xen_common_irq { int irq; char *name; diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c index 6175f2c5c822..a97b0505a483 100644 --- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -385,17 +385,8 @@ static void xen_pv_play_dead(void) /* used only with HOTPLUG_CPU */ { play_dead_common(); HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(smp_processor_id()), NULL); - cpu_bringup(); - /* - * commit 4b0c0f294 (tick: Cleanup NOHZ per cpu data on cpu down) - * clears certain data that the cpu_idle loop (which called us - * and that we return from) expects. The only way to get that - * data back is to call: - */ - tick_nohz_idle_enter(); - tick_nohz_idle_stop_tick_protected(); - - cpuhp_online_idle(CPUHP_AP_ONLINE_IDLE); + xen_cpu_bringup_again((unsigned long)task_pt_regs(current)); + BUG(); } #else /* !CONFIG_HOTPLUG_CPU */ diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index ffaa62167f6e..e36ea4268bd2 100644 --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -76,6 +76,13 @@ SYM_CODE_START(asm_cpu_bringup_and_idle) call cpu_bringup_and_idle SYM_CODE_END(asm_cpu_bringup_and_idle) + +SYM_CODE_START(xen_cpu_bringup_again) + UNWIND_HINT_FUNC + mov %rdi, %rsp + UNWIND_HINT_REGS + call cpu_bringup_and_idle +SYM_CODE_END(xen_cpu_bringup_again) .popsection #endif #endif From f697cb00afa90b68748f246540270b5865c801ba Mon Sep 17 00:00:00 2001 From: Juergen Gross Date: Fri, 25 Nov 2022 07:32:48 +0100 Subject: [PATCH 03/10] x86/xen: mark xen_pv_play_dead() as __noreturn Mark xen_pv_play_dead() and related to that xen_cpu_bringup_again() as "__noreturn". Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20221125063248.30256-3-jgross@suse.com Signed-off-by: Juergen Gross --- arch/x86/xen/smp.h | 2 +- arch/x86/xen/smp_pv.c | 4 ++-- tools/objtool/check.c | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h index 6e90a312067b..22fb982ff971 100644 --- a/arch/x86/xen/smp.h +++ b/arch/x86/xen/smp.h @@ -21,7 +21,7 @@ void xen_smp_send_reschedule(int cpu); void xen_smp_send_call_function_ipi(const struct cpumask *mask); void xen_smp_send_call_function_single_ipi(int cpu); -void xen_cpu_bringup_again(unsigned long stack); +void __noreturn xen_cpu_bringup_again(unsigned long stack); struct xen_common_irq { int irq; diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c index a97b0505a483..a9cf8c8fa074 100644 --- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -381,7 +381,7 @@ static void xen_pv_cpu_die(unsigned int cpu) } } -static void xen_pv_play_dead(void) /* used only with HOTPLUG_CPU */ +static void __noreturn xen_pv_play_dead(void) /* used only with HOTPLUG_CPU */ { play_dead_common(); HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(smp_processor_id()), NULL); @@ -400,7 +400,7 @@ static void xen_pv_cpu_die(unsigned int cpu) BUG(); } -static void xen_pv_play_dead(void) +static void __noreturn xen_pv_play_dead(void) { BUG(); } diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 4b7c8b33069e..68e87b45caef 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -186,6 +186,7 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func, "snp_abort", "stop_this_cpu", "usercopy_abort", + "xen_cpu_bringup_again", "xen_start_kernel", }; From caea091e48ed9d3951506507abf26e9918d08e35 Mon Sep 17 00:00:00 2001 From: Krister Johansen Date: Fri, 16 Dec 2022 08:21:18 -0800 Subject: [PATCH 04/10] x86/xen/time: prefer tsc as clocksource when it is invariant Kvm elects to use tsc instead of kvm-clock when it can detect that the TSC is invariant. (As of commit 7539b174aef4 ("x86: kvmguest: use TSC clocksource if invariant TSC is exposed")). Notable cloud vendors[1] and performance engineers[2] recommend that Xen users preferentially select tsc over xen-clocksource due the performance penalty incurred by the latter. These articles are persuasive and tailored to specific use cases. In order to understand the tradeoffs around this choice more fully, this author had to reference the documented[3] complexities around the Xen configuration, as well as the kernel's clocksource selection algorithm. Many users may not attempt this to correctly configure the right clock source in their guest. The approach taken in the kvm-clock module spares users this confusion, where possible. Both the Intel SDM[4] and the Xen tsc documentation explain that marking a tsc as invariant means that it should be considered stable by the OS and is elibile to be used as a wall clock source. In order to obtain better out-of-the-box performance, and reduce the need for user tuning, follow kvm's approach and decrease the xen clock rating so that tsc is preferable, if it is invariant, stable, and the tsc will never be emulated. [1] https://aws.amazon.com/premiumsupport/knowledge-center/manage-ec2-linux-clock-source/ [2] https://www.brendangregg.com/blog/2021-09-26/the-speed-of-time.html [3] https://xenbits.xen.org/docs/unstable/man/xen-tscmode.7.html [4] Intel 64 and IA-32 Architectures Sofware Developer's Manual Volume 3b: System Programming Guide, Part 2, Section 17.17.1, Invariant TSC Signed-off-by: Krister Johansen Code-reviewed-by: David Reaver Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20221216162118.GB2633@templeofstupid.com Signed-off-by: Juergen Gross --- arch/x86/xen/time.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 9ef0a5cca96e..95140609c8a8 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -474,15 +474,51 @@ static void xen_setup_vsyscall_time_info(void) xen_clocksource.vdso_clock_mode = VDSO_CLOCKMODE_PVCLOCK; } +/* + * Check if it is possible to safely use the tsc as a clocksource. This is + * only true if the hypervisor notifies the guest that its tsc is invariant, + * the tsc is stable, and the tsc instruction will never be emulated. + */ +static int __init xen_tsc_safe_clocksource(void) +{ + u32 eax, ebx, ecx, edx; + + if (!(boot_cpu_has(X86_FEATURE_CONSTANT_TSC))) + return 0; + + if (!(boot_cpu_has(X86_FEATURE_NONSTOP_TSC))) + return 0; + + if (check_tsc_unstable()) + return 0; + + /* Leaf 4, sub-leaf 0 (0x40000x03) */ + cpuid_count(xen_cpuid_base() + 3, 0, &eax, &ebx, &ecx, &edx); + + /* tsc_mode = no_emulate (2) */ + if (ebx != 2) + return 0; + + return 1; +} + static void __init xen_time_init(void) { struct pvclock_vcpu_time_info *pvti; int cpu = smp_processor_id(); struct timespec64 tp; - /* As Dom0 is never moved, no penalty on using TSC there */ + /* + * As Dom0 is never moved, no penalty on using TSC there. + * + * If it is possible for the guest to determine that the tsc is a safe + * clocksource, then set xen_clocksource rating below that of the tsc + * so that the system prefers tsc instead. + */ if (xen_initial_domain()) xen_clocksource.rating = 275; + else if (xen_tsc_safe_clocksource()) + xen_clocksource.rating = 299; clocksource_register_hz(&xen_clocksource, NSEC_PER_SEC); From 3e8cd711c3da6c3d724076048038cd666bdbb2b5 Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Wed, 18 Jan 2023 12:22:38 +0000 Subject: [PATCH 05/10] xen: Allow platform PCI interrupt to be shared When we don't use the per-CPU vector callback, we ask Xen to deliver event channel interrupts as INTx on the PCI platform device. As such, it can be shared with INTx on other PCI devices. Set IRQF_SHARED, and make it return IRQ_HANDLED or IRQ_NONE according to whether the evtchn_upcall_pending flag was actually set. Now I can share the interrupt: 11: 82 0 IO-APIC 11-fasteoi xen-platform-pci, ens4 Drop the IRQF_TRIGGER_RISING. It has no effect when the IRQ is shared, and besides, the only effect it was having even beforehand was to trigger a debug message in both I/OAPIC and legacy PIC cases: [ 0.915441] genirq: No set_type function for IRQ 11 (IO-APIC) [ 0.951939] genirq: No set_type function for IRQ 11 (XT-PIC) Signed-off-by: David Woodhouse Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/f9a29a68d05668a3636dd09acd94d970269eaec6.camel@infradead.org Signed-off-by: Juergen Gross --- drivers/xen/events/events_base.c | 9 ++++++--- drivers/xen/platform-pci.c | 5 ++--- include/xen/events.h | 2 +- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index c443f04aaad7..c7715f8bd452 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -1710,9 +1710,10 @@ void handle_irq_for_port(evtchn_port_t port, struct evtchn_loop_ctrl *ctrl) generic_handle_irq(irq); } -static void __xen_evtchn_do_upcall(void) +static int __xen_evtchn_do_upcall(void) { struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu); + int ret = vcpu_info->evtchn_upcall_pending ? IRQ_HANDLED : IRQ_NONE; int cpu = smp_processor_id(); struct evtchn_loop_ctrl ctrl = { 0 }; @@ -1737,6 +1738,8 @@ static void __xen_evtchn_do_upcall(void) * above. */ __this_cpu_inc(irq_epoch); + + return ret; } void xen_evtchn_do_upcall(struct pt_regs *regs) @@ -1751,9 +1754,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs) set_irq_regs(old_regs); } -void xen_hvm_evtchn_do_upcall(void) +int xen_hvm_evtchn_do_upcall(void) { - __xen_evtchn_do_upcall(); + return __xen_evtchn_do_upcall(); } EXPORT_SYMBOL_GPL(xen_hvm_evtchn_do_upcall); diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c index cd07e3fed0fa..fcc819131572 100644 --- a/drivers/xen/platform-pci.c +++ b/drivers/xen/platform-pci.c @@ -64,14 +64,13 @@ static uint64_t get_callback_via(struct pci_dev *pdev) static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id) { - xen_hvm_evtchn_do_upcall(); - return IRQ_HANDLED; + return xen_hvm_evtchn_do_upcall(); } static int xen_allocate_irq(struct pci_dev *pdev) { return request_irq(pdev->irq, do_hvm_evtchn_intr, - IRQF_NOBALANCING | IRQF_TRIGGER_RISING, + IRQF_NOBALANCING | IRQF_SHARED, "xen-platform-pci", pdev); } diff --git a/include/xen/events.h b/include/xen/events.h index 344081e71584..44c2855c76d1 100644 --- a/include/xen/events.h +++ b/include/xen/events.h @@ -107,7 +107,7 @@ evtchn_port_t evtchn_from_irq(unsigned irq); int xen_set_callback_via(uint64_t via); void xen_evtchn_do_upcall(struct pt_regs *regs); -void xen_hvm_evtchn_do_upcall(void); +int xen_hvm_evtchn_do_upcall(void); /* Bind a pirq for a physical interrupt to an irq. */ int xen_bind_pirq_gsi_to_irq(unsigned gsi, From c70b7741dda7586529cc270e0f2c4cae3921b9b1 Mon Sep 17 00:00:00 2001 From: Volodymyr Babchuk Date: Thu, 19 Jan 2023 21:11:15 +0000 Subject: [PATCH 06/10] xen/pvcalls-back: fix permanently masked event channel There is a sequence of events that can lead to a permanently masked event channel, because xen_irq_lateeoi() is newer called. This happens when a backend receives spurious write event from a frontend. In this case pvcalls_conn_back_write() returns early and it does not clears the map->write counter. As map->write > 0, pvcalls_back_ioworker() returns without calling xen_irq_lateeoi(). This leaves the event channel in masked state, a backend does not receive any new events from a frontend and the whole communication stops. Move atomic_set(&map->write, 0) to the very beginning of pvcalls_conn_back_write() to fix this issue. Signed-off-by: Volodymyr Babchuk Reported-by: Oleksii Moisieiev Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20230119211037.1234931-1-volodymyr_babchuk@epam.com Signed-off-by: Juergen Gross --- drivers/xen/pvcalls-back.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c index 0d4f8f4f4948..7a464a541d91 100644 --- a/drivers/xen/pvcalls-back.c +++ b/drivers/xen/pvcalls-back.c @@ -173,6 +173,8 @@ static bool pvcalls_conn_back_write(struct sock_mapping *map) RING_IDX cons, prod, size, array_size; int ret; + atomic_set(&map->write, 0); + cons = intf->out_cons; prod = intf->out_prod; /* read the indexes before dealing with the data */ @@ -197,7 +199,6 @@ static bool pvcalls_conn_back_write(struct sock_mapping *map) iov_iter_kvec(&msg.msg_iter, ITER_SOURCE, vec, 2, size); } - atomic_set(&map->write, 0); ret = inet_sendmsg(map->sock, &msg, size); if (ret == -EAGAIN) { atomic_inc(&map->write); From 2062f9fb6445451b189595e295765c69f43bc12e Mon Sep 17 00:00:00 2001 From: Oleksandr Tyshchenko Date: Wed, 8 Feb 2023 17:36:49 +0200 Subject: [PATCH 07/10] xen/grant-dma-iommu: Implement a dummy probe_device() callback Update stub IOMMU driver (which main purpose is to reuse generic IOMMU device-tree bindings by Xen grant DMA-mapping layer on Arm) according to the recent changes done in the following commit 57365a04c921 ("iommu: Move bus setup to IOMMU device registration"). With probe_device() callback being called during IOMMU device registration, the uninitialized callback just leads to the "kernel NULL pointer dereference" issue during boot. Fix that by adding a dummy callback. Looks like the release_device() callback is not mandatory to be implemented as IOMMU framework makes sure that callback is initialized before dereferencing. Reported-by: Viresh Kumar Fixes: 57365a04c921 ("iommu: Move bus setup to IOMMU device registration") Signed-off-by: Oleksandr Tyshchenko Tested-by: Viresh Kumar Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/20230208153649.3604857-1-olekstysh@gmail.com Signed-off-by: Juergen Gross --- drivers/xen/grant-dma-iommu.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/xen/grant-dma-iommu.c b/drivers/xen/grant-dma-iommu.c index 16b8bc0c0b33..6a9fe02c6bfc 100644 --- a/drivers/xen/grant-dma-iommu.c +++ b/drivers/xen/grant-dma-iommu.c @@ -16,8 +16,15 @@ struct grant_dma_iommu_device { struct iommu_device iommu; }; -/* Nothing is really needed here */ -static const struct iommu_ops grant_dma_iommu_ops; +static struct iommu_device *grant_dma_iommu_probe_device(struct device *dev) +{ + return ERR_PTR(-ENODEV); +} + +/* Nothing is really needed here except a dummy probe_device callback */ +static const struct iommu_ops grant_dma_iommu_ops = { + .probe_device = grant_dma_iommu_probe_device, +}; static const struct of_device_id grant_dma_iommu_of_match[] = { { .compatible = "xen,grant-dma" }, From 9a0450ada86e842997db6296244e159879fb6ef9 Mon Sep 17 00:00:00 2001 From: "Gustavo A. R. Silva" Date: Thu, 2 Feb 2023 19:28:23 -0600 Subject: [PATCH 08/10] xen: Replace one-element array with flexible-array member One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct xen_page_directory. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. This results in no differences in binary output. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/255 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/Y9xjN6Wa3VslgXeX@work Signed-off-by: Juergen Gross --- drivers/xen/xen-front-pgdir-shbuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-front-pgdir-shbuf.c b/drivers/xen/xen-front-pgdir-shbuf.c index 5c0b5cb5b419..b52e0fa595a9 100644 --- a/drivers/xen/xen-front-pgdir-shbuf.c +++ b/drivers/xen/xen-front-pgdir-shbuf.c @@ -30,7 +30,7 @@ struct xen_page_directory { grant_ref_t gref_dir_next_page; #define XEN_GREF_LIST_END 0 - grant_ref_t gref[1]; /* Variable length */ + grant_ref_t gref[]; /* Variable length */ }; /** From 20e7da1bbba8474839157fb28fb538d2c058128d Mon Sep 17 00:00:00 2001 From: Jan Beulich Date: Wed, 15 Feb 2023 12:27:52 +0100 Subject: [PATCH 09/10] x86/Xen: drop leftover VM-assist uses Both the 4Gb-segments and the PAE-extended-CR3 one are applicable to 32-bit guests only. The PAE-extended-CR3 use, furthermore, was redundant with the PAE_MODE ELF note anyway. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/215515af-cfb9-3237-03ba-3312e3fa0d34@suse.com Signed-off-by: Juergen Gross --- arch/x86/xen/setup.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 8db26f10fb1d..c2be3efb2ba0 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -934,12 +934,8 @@ void xen_enable_syscall(void) static void __init xen_pvmmu_arch_setup(void) { - HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments); HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables); - HYPERVISOR_vm_assist(VMASST_CMD_enable, - VMASST_TYPE_pae_extended_cr3); - if (register_callback(CALLBACKTYPE_event, xen_asm_exc_xen_hypervisor_callback) || register_callback(CALLBACKTYPE_failsafe, xen_failsafe_callback)) From 4ecc96cba8d93d86abf46d17067e9b4c96241a29 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= Date: Thu, 16 Feb 2023 01:10:59 +0000 Subject: [PATCH 10/10] xen: sysfs: make kobj_type structure constant MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Signed-off-by: Thomas Weißschuh Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20230216-kobj_type-xen-v1-1-742423de7d71@weissschuh.net Signed-off-by: Juergen Gross --- drivers/xen/sys-hypervisor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c index ca092db8f498..2f880374b463 100644 --- a/drivers/xen/sys-hypervisor.c +++ b/drivers/xen/sys-hypervisor.c @@ -655,7 +655,7 @@ static const struct sysfs_ops hyp_sysfs_ops = { .store = hyp_sysfs_store, }; -static struct kobj_type hyp_sysfs_kobj_type = { +static const struct kobj_type hyp_sysfs_kobj_type = { .sysfs_ops = &hyp_sysfs_ops, };