er just on cpu0 may be sufficient. Not sure where to do this though.
But this works as well.
Reviewed-by: Boris Ostrovsky
.initdata
section, as it needs to be accessed for cpuhotplug, too.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
/xen/smp.h
Reviewed-by: Boris Ostrovsky
stored in the multicall data for each call
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 7/8/24 5:04 AM, Jürgen Groß wrote:
On 06.07.24 00:36, boris.ostrov...@oracle.com wrote:
Also, would it be better to keep these fields as a struct of scalars
and instead have the percpu array of this struct? Otherwise there is a
whole bunch of [MC_BATCH] arrays, all of them really i
On 7/3/24 7:56 AM, Juergen Gross wrote:
#define MC_BATCH 32
-#define MC_DEBUG 0
-
#define MC_ARGS (MC_BATCH * 16)
struct mc_buffer {
unsigned mcidx, argidx, cbidx;
struct multicall_entry entries[MC_BATCH];
-#if MC_DEBUG
- struct multicall
DEFINE_PER_CPU_ALIGNED() instead,
as struct vcpu_info is guaranteed to have a size of 64 bytes, matching
the cache line size of x86 64-bit processors (Xen doesn't support
32-bit processors).
Fixes: 5ead97c84fa7 ("xen: Core Xen implementation")
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovs
Cc: Boris Ostrovsky
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: "H. Peter Anvin"
Signed-off-by: Uros Bizjak
Reviewed-by: Boris Ostrovsky
s no reason why nesting of multiple sections of the
same kind of lazy mode shouldn't be allowed. So add support for that
for fixing the regression.
Fixes: bcc6cc832573 ("mm: add default definition of set_ptes()")
Signed-off-by: Juergen Gross
For patches 2 and 3
Reviewed-by: Boris Ostrovsky
xen_evtchn_do_upcall()
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
p pvh leftovers from pv-only sources")
Signed-off-by: Petr Tesarik
Reviewed-by: Boris Ostrovsky
nt of start_secondary().
Fixes: b81fac906a8f ("x86/fpu: Move FPU initialization into
arch_cpu_finalize_init()")
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 6/15/23 8:39 AM, Juergen Gross wrote:
When running as an unprivileged PV-guest under Xen (not dom0), the
default MTRR memory type should be write-back.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
/x86/xen/smp.h | 4
arch/x86/xen/smp_pv.c | 1 -
arch/x86/xen/xen-ops.h | 3 +++
include/xen/xen.h | 3 +++
6 files changed, 28 insertions(+), 1 deletion(-)
Reviewed-by: Boris Ostrovsky
On 5/23/23 4:37 PM, Arnd Bergmann wrote:
On Sat, May 20, 2023, at 00:24, Boris Ostrovsky wrote:
On 5/19/23 5:28 AM, Arnd Bergmann wrote:
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 22fb982ff971..81a7821dd07f 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -1,7
On 5/19/23 5:28 AM, Arnd Bergmann wrote:
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 22fb982ff971..81a7821dd07f 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -1,7 +1,11 @@
/* SPDX-License-Identifier: GPL-2.0 */
#ifndef _XEN_SMP_H
+void asm_cpu_bringup_and_i
on to complete makes no difference.
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/smp_pv.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -3
abled() properly reflect state when
running on Xen")
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 2/27/23 2:12 AM, Juergen Gross wrote:
On 24.02.23 22:00, Boris Ostrovsky wrote:
On 2/23/23 4:32 AM, Juergen Gross wrote:
+
+ for (reg = 0; reg < MTRR_MAX_VAR_RANGES; reg++) {
+ op.u.read_memtype.reg = reg;
+ if (HYPERVISOR_platform_op(&op))
+ break;
On 2/23/23 4:32 AM, Juergen Gross wrote:
+
+ for (reg = 0; reg < MTRR_MAX_VAR_RANGES; reg++) {
+ op.u.read_memtype.reg = reg;
+ if (HYPERVISOR_platform_op(&op))
+ break;
If we fail on the first iteration, do we still want to mark MTRRs a
On 2/15/23 3:31 AM, Jan Beulich wrote:
On 15.02.2023 01:07, Boris Ostrovsky wrote:
On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -32,6 +34,7 @@
#include
#include
#include
+#include
#include
#include "c
On 2/14/23 2:48 AM, Jan Beulich wrote:
On 13.02.2023 21:53, Boris Ostrovsky wrote:
On 2/13/23 11:41 AM, Jan Beulich wrote:
On 13.02.2023 17:30, Xenia Ragiadakou wrote:
On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/cpu/Makefile
+++ b
On 2/13/23 11:41 AM, Jan Beulich wrote:
On 13.02.2023 17:30, Xenia Ragiadakou wrote:
On 2/13/23 17:11, Jan Beulich wrote:
On 13.02.2023 15:57, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -10,4 +10,6 @@ obj-y += intel.o
obj-y += intel_cacheinf
_play_dead() return
x86/xen: mark xen_pv_play_dead() as __noreturn
arch/x86/xen/smp.h | 2 ++
arch/x86/xen/smp_pv.c | 17 -
arch/x86/xen/xen-head.S | 7 +++
tools/objtool/check.c | 1 +
4 files changed, 14 insertions(+), 13 deletions(-)
Ping?
Reviewed
callback .mmu.enter_mmap (in contrast to the
corresponding already existing .mmu.exit_mmap).
As the first parameter of the old callbacks isn't used, drop it from
the replacement one.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 12/14/22 1:01 PM, Krister Johansen wrote:
On Tue, Dec 13, 2022 at 04:25:32PM -0500, Boris Ostrovsky wrote:
On 12/12/22 5:09 PM, Krister Johansen wrote:
On Mon, Dec 12, 2022 at 01:48:24PM -0500, Boris Ostrovsky wrote:
On 12/12/22 11:05 AM, Krister Johansen wrote:
diff --git a/arch/x86
On 12/12/22 5:09 PM, Krister Johansen wrote:
On Mon, Dec 12, 2022 at 01:48:24PM -0500, Boris Ostrovsky wrote:
On 12/12/22 11:05 AM, Krister Johansen wrote:
diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
index 6daa9b0c8d11..d9d7432481e9 100644
--- a/arch/x86
On 12/12/22 11:05 AM, Krister Johansen wrote:
diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h
index 6daa9b0c8d11..d9d7432481e9 100644
--- a/arch/x86/include/asm/xen/cpuid.h
+++ b/arch/x86/include/asm/xen/cpuid.h
@@ -88,6 +88,12 @@
* EDX: shift am
On 12/8/22 11:36 AM, Krister Johansen wrote:
+ /*
+* As Dom0 is never moved, no penalty on using TSC there.
+*
+* If the guest has invariant tsc, then set xen_clocksource rating
+* below that of the tsc so that the system prefers tsc instead. This
+
On 11/29/22 10:00 AM, Per Bilse wrote:
+static ssize_t flags_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+ static char const *const sifstr[SIFN_NUM_SIFN] = {
+ [SIFN_PRIV] = "privileged",
+ [SIFN_INIT] = "initdomain",
+ [SIFN_MULTI] =
is available
at [1].
[1]:
https://lore.kernel.org/all/cover.1667336095.git.christophe.jail...@wanadoo.fr/
Reviewed-by: Boris Ostrovsky
On 10/20/22 9:34 AM, Juergen Gross wrote:
On 20.10.22 15:16, Jan Beulich wrote:
On 20.10.2022 13:37, Juergen Gross wrote:
Commit 8714f7bcd3c2 ("xen/pv: add fault recovery control to pmu msr
accesses") introduced code resulting in a warning issued by the smatch
static checker, claiming to use
() (Oleksandr Tyshchenko)
- add xen_virtio_restricted_mem_acc() stub (Oleksandr Tyshchenko)
Reviewed-by: Oleksandr Tyshchenko #
common code
Reviewed-by: Boris Ostrovsky
On 10/4/22 4:43 AM, Juergen Gross wrote:
bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
{
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
- if (is_amd_pmu_msr(msr)) {
- if (!xen_amd_pmu_emulate(msr, val, 1))
-
On 9/26/22 10:18 AM, Juergen Gross wrote:
bool pmu_msr_read(unsigned int msr, uint64_t *val, int *err)
{
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
- if (is_amd_pmu_msr(msr)) {
- if (!xen_amd_pmu_emulate(msr, val, 1))
-
te-warning]
__write_overflow_field(p_size_field, size);
^
which was isolated to the memset() call in xen_load_idt().
Note that this looks very much like another bug that was worked around:
https://github.com/ClangBuiltLinux/linux/issues/1592
Cc: Juergen Gross
Cc: Boris
On 9/20/22 10:54 AM, Jan Beulich wrote:
On 20.09.2022 16:26, Boris Ostrovsky wrote:
On 9/20/22 4:01 AM, Jan Beulich wrote:
On 20.09.2022 00:42, Boris Ostrovsky wrote:
It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
in vmx_find_msr() is not @cu
On 9/20/22 4:01 AM, Jan Beulich wrote:
On 20.09.2022 00:42, Boris Ostrovsky wrote:
It is saving vpmu data from current pcpu's MSRs for a remote vcpu so @v
in vmx_find_msr() is not @current:
vpmu_load()
...
prev = per_cpu(last_vcpu,
, Sep 19, 2022 at 5:28 AM Jan Beulich wrote:
On 16.09.2022 23:35, Boris Ostrovsky wrote:
On 9/16/22 8:52 AM, Jan Beulich wrote:
On 15.09.2022 16:01, Tamas K Lengyel wrote:
While experimenting with the vPMU subsystem an ASSERT failure was
observed in vmx_find_msr because the vcpu_runnable state
On 9/16/22 8:52 AM, Jan Beulich wrote:
On 15.09.2022 16:01, Tamas K Lengyel wrote:
While experimenting with the vPMU subsystem an ASSERT failure was
observed in vmx_find_msr because the vcpu_runnable state was true.
The root cause of the bug appears to be the fact that the vPMU subsystem
does
On 7/28/22 8:52 AM, Jane Malalane wrote:
+/*
+ * Setup per-vCPU vector-type callbacks and trick toolstack to think
The comment should be adjusted -- no need to mention toolstack now that that
code has been factored out.
Other than that
Reviewed-by: Boris Ostrovsky
+ * we are
On 7/26/22 8:56 AM, Jane Malalane wrote:
+/* Setup per-vCPU vector-type callbacks and trick toolstack to think
+ * we are enlightened. If this setup is unavailable, fallback to the
+ * global vector-type callback. */
Comment style.
+static __init void xen_init_setup_upcall_vector(void)
On 7/25/22 6:03 AM, Jane Malalane wrote:
On 18/07/2022 14:59, Boris Ostrovsky wrote:
On 7/18/22 4:56 AM, Andrew Cooper wrote:
On 15/07/2022 14:10, Boris Ostrovsky wrote:
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky
On 7/18/22 4:56 AM, Andrew Cooper wrote:
On 15/07/2022 14:10, Boris Ostrovsky wrote:
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky wrote:
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup
On 7/17/22 1:20 AM, Juergen Gross wrote:
What about filling the complete hypercall page just with "int 3" or "ud2"?
Any try to do a hypercall before the hypercall page has been initialized
is a bug anyway. What good can come from calling a function which will
return a basically random value i
d to other stable branches as well.
TL;DR: for this particular warning, objtool would exit early and fail to
create any .orc_unwind* ELF sections for head_64.o, which are consumed
by the ORC unwinder at runtime.
Boris Ostrovsky writes:
On 7/12/22 3:31 PM, Greg KH wrote:
On Tue, Jul 12, 2022 at
On 7/15/22 5:50 AM, Andrew Cooper wrote:
On 15/07/2022 09:18, Jane Malalane wrote:
On 14/07/2022 00:27, Boris Ostrovsky wrote:
xen_hvm_smp_init();
WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_hvm, xen_cpu_dead_hvm));
diff --git a/arch/x86/xen/suspend_hvm.c b/arch/x86/xen
On 7/11/22 11:22 AM, Jane Malalane wrote:
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
@@ -30,6 +31,9 @@
static unsigned long shared_info_pfn;
+__ro_after_init bool xen_ack_upcall
On 7/12/22 3:31 PM, Greg KH wrote:
On Tue, Jul 12, 2022 at 03:19:39PM -0400, Boris Ostrovsky wrote:
On 7/12/22 12:38 PM, Greg KH wrote:
Hi all,
I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool:
xen_hypercall_mmu_update(): can't fin
On 7/12/22 12:38 PM, Greg KH wrote:
Hi all,
I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool:
xen_hypercall_mmu_update(): can't find starting instruction
in the 5.15.y and 5.10.y retbleed backports.
I don't know why just this one hypercall is being
On 6/29/22 4:03 PM, Stefano Stabellini wrote:
Adding Juergen and Boris because this is a Linux/x86 issue.
As you can see from this Linux driver:
https://elixir.bootlin.com/linux/latest/source/drivers/crypto/ccp/tee-dev.c#L132
Linux as dom0 on x86 is trying to communicate with firmware (TEE).
bits as Jan had already reviewed it but in
case you do
Reviewed-by: Boris Ostrovsky
nts for x86 side here?
Reviewed-by: Boris Ostrovsky
an be replaced with memunmap().
Reported-by: kernel test robot
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Due to time constraints I am stepping down as maintainter. I will stay
as reviewer for x86 code (for which create a separate category).
Stefano is now maintainer for Xen hypervisor interface and Oleksandr has
graciously agreed to become a reviewer.
Signed-off-by: Boris Ostrovsky
On 5/16/22 2:30 PM, Oleksandr wrote:
On 16.05.22 19:00, Boris Ostrovsky wrote:
With the error handling in gnttab_init() fixed
yes, this is a diff that I am going to apply for the next version:
[snip]
@@ -1596,19 +1601,20 @@ static int gnttab_expand(unsigned int req_entries)
int
: Boris Ostrovsky
On 5/16/22 1:59 AM, Juergen Gross wrote:
On 14.05.22 04:34, Boris Ostrovsky wrote:
On 5/13/22 1:33 AM, Juergen Gross wrote:
On 12.05.22 22:01, Boris Ostrovsky wrote:
On 5/7/22 2:19 PM, Oleksandr Tyshchenko wrote:
+/* Rebuilds the free grant list and tries to find count consecutive
On 5/13/22 1:33 AM, Juergen Gross wrote:
On 12.05.22 22:01, Boris Ostrovsky wrote:
On 5/7/22 2:19 PM, Oleksandr Tyshchenko wrote:
+/* Rebuilds the free grant list and tries to find count consecutive entries. */
+static int get_free_seq(unsigned int count)
+{
+ int ret = -ENOSPC
On 5/7/22 2:19 PM, Oleksandr Tyshchenko wrote:
+
+/*
+ * Handling of free grants:
+ *
+ * Free grants are in a simple list anchored in gnttab_free_head. They are
+ * linked by grant ref, the last element contains GNTTAB_LIST_END. The number
+ * of free entries is stored in gnttab_free_count.
+
On 5/11/22 2:00 PM, Oleksandr wrote:
On 07.05.22 21:19, Oleksandr Tyshchenko wrote:
Hello Boris, Stefano
From: Juergen Gross
For support of virtio via grant mappings in rare cases larger mappings
using consecutive grants are needed. Support those by adding a bitmap
of free grants.
As co
On 5/9/22 3:01 PM, Stefano Stabellini wrote:
On Mon, 9 May 2022, Juergen Gross wrote:
On IRC the question came up whether it would be possible to have a
special marker for Linux patches on the xen-devel ML.
I suggested to use xen-devel+li...@lists.xenprojext.org for those
patches. With a patc
value for an invalid
grant reference in order to make the functions idempotent.
Changes in V3:
- new patches 1 and 2, comments addressed
Changes in V2:
- new patch 9 and related changes in patches 10-18
For the patches that I was explicitly copied on:
Reviewed-by: Boris Ostrovsky
...
*/
- if (!v || !~v) {
+ if (!v) {
err = -ENOENT;
goto out_error;
}
- /* Avoid truncation on 32-bit. */
... here.
But this is ntpicking so for the series
Reviewed-by: Boris Ostrovsky
On 5/2/22 8:36 PM, Stefano Stabellini wrote:
I gave it a try and there is a problem with unbinding the IRQ here. If I
do that, later when xb_init_comms calls bind_evtchn_to_irqhandler, the
event channel doesn't fire anymore. I did some testing and debugging and
as far as I can tell the issue i
On 4/29/22 5:10 PM, Stefano Stabellini wrote:
From: Luca Miccio
When running as dom0less guest (HVM domain on ARM) the xenstore event
channel is available at domain creation but the shared xenstore
interface page only becomes available later on.
In that case, wait for a notification on the x
On 4/28/22 6:49 PM, Stefano Stabellini wrote:
On Thu, 28 Apr 2022, Boris Ostrovsky wrote:
On 4/28/22 5:49 PM, Stefano Stabellini wrote:
On Thu, 28 Apr 2022, Christoph Hellwig wrote:
On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote:
Reported-by: Rahul Singh
Signed-off-by
/vscsiif.h | 133 ++-
3 files changed, 340 insertions(+), 43 deletions(-)
Reviewed-by: Boris Ostrovsky
On 4/28/22 5:49 PM, Stefano Stabellini wrote:
On Thu, 28 Apr 2022, Christoph Hellwig wrote:
On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote:
Reported-by: Rahul Singh
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
Do you want to take this through the X
On 4/28/22 11:53 AM, Jan Beulich wrote:
Hello,
in the course of analyzing the i915 driver causing boot to fail in
Linux 5.18 I found that Linux, for all the years, has been running
in PV mode as if PAT was (mostly) disabled. This is a result of
them tying PAT initialization to MTRR initializat
On 4/24/22 12:53 PM, Oleksandr wrote:
On 23.04.22 19:40, Christoph Hellwig wrote:
+
+#ifdef CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
+int arch_has_restricted_virtio_memory_access(void)
+{
+ return (xen_has_restricted_virtio_memory_access() ||
+ cc_platform_has(CC_AT
On 4/19/22 7:43 PM, Alaa Mohamed wrote:
kmap() is being deprecated and these usages are all local to the thread
so there is no reason kmap_local_page() can't be used.
Replace kmap() calls with kmap_local_page().
Signed-off-by: Alaa Mohamed
Applied to for-linus-5.18. (Juergen, I kept your
On 4/21/22 4:40 AM, Juergen Gross wrote:
On 20.04.22 18:12, Boris Ostrovsky wrote:
On 4/20/22 5:25 AM, Juergen Gross wrote:
@@ -569,7 +645,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
wait_for_completion(&pending_req->tmr_done);
err =
On 4/20/22 11:09 AM, Juergen Gross wrote:
+/*
+ * xenbus_setup_ring
+ * @dev: xenbus device
+ * @vaddr: pointer to starting virtual address of the ring
+ * @nr_pages: number of pages to be granted
+ * @grefs: grant reference array to be filled in
+ *
+ * Allocate physically contiguous pages
Just a couple of nits.
On 4/20/22 5:25 AM, Juergen Gross wrote:
-static int scsifront_ring_drain(struct vscsifrnt_info *info)
+static int scsifront_ring_drain(struct vscsifrnt_info *info,
+ unsigned int *eoiflag)
{
- struct vscsiif_response *ring_rsp;
+
On 4/20/22 5:25 AM, Juergen Gross wrote:
@@ -569,7 +645,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
wait_for_completion(&pending_req->tmr_done);
err = (se_cmd->se_tmr_req->response == TMR_FUNCTION_COMPLETE) ?
- SUCCESS : FAILED;
+
On 4/7/22 5:38 AM, Juergen Gross wrote:
When running as a Xen PV guest use the extra memory (memory which isn't
allocated for the guest at boot time) only for ballooning purposes and
not for zone device allocations. This will remove some code without any
lack of functionality.
While at it move
at it move some code to get rid of another #ifdef.
Remove a comment which is stale since some time now.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
://git.infradead.org/users/hch/misc.git swiotlb-init-cleanup
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb-init-cleanup
Tested-by: Boris Ostrovsky
On 3/25/22 10:20 AM, Juergen Gross wrote:
is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in or
On 3/22/22 9:21 PM, Jakub Kądziołka wrote:
If a xen domain with at least two VCPUs has a PCI device attached which
enters the D3hot state during suspend, the kernel may hang while
resuming, depending on the core on which an async resume task gets
scheduled.
The bug occurs because xen's do_susp
boolean variable not being set.
Fixes: bf6dfb154d93 ("xen/PMU: PMU emulation code")
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 3/22/22 11:50 AM, Juergen Gross wrote:
is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in or
On 3/14/22 3:05 AM, jianchunfu wrote:
In the function xen_apic_read(), the initialized value of 'ret' is unused
because it will be assigned by the function HYPERVISOR_platform_op(),
thus remove it.
Signed-off-by: jianchunfu
Reviewed-by: Boris Ostrovsky
Applied to for-linus-
On 3/11/22 5:34 AM, Juergen Gross wrote:
All grant table operations related to the "transfer" functionality
are unused currently. There have been users in the old days of the
"Xen-o-Linux" kernel, but those didn't make it upstream.
So remove the "transfer" related functions.
Signed-off-by: Ju
On 3/15/22 2:10 AM, Juergen Gross wrote:
On 15.03.22 00:37, Boris Ostrovsky wrote:
On 3/11/22 5:34 AM, Juergen Gross wrote:
All grant table operations related to the "transfer" functionality
are unused currently. There have been users in the old days of the
"Xen-o-Linux&quo
On 3/15/22 2:36 AM, Christoph Hellwig wrote:
@@ -271,12 +273,23 @@ void __init swiotlb_init(bool addressing_limit, unsigned
int flags)
* allow to pick a location everywhere for hypervisors with guest
* memory encryption.
*/
+retry:
+ bytes = PAGE_ALIGN(defaul
On 3/11/22 5:34 AM, Juergen Gross wrote:
All grant table operations related to the "transfer" functionality
are unused currently. There have been users in the old days of the
"Xen-o-Linux" kernel, but those didn't make it upstream.
So remove the "transfer" related functions.
Do we need to a
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
@@ -314,6 +293,7 @@ void __init swiotlb_init(bool addressing_limit, unsigned
int flags)
int swiotlb_init_late(size_t size, gfp_t gfp_mask,
int (*remap)(void *tlb, unsigned long nslabs))
{
+ struct io_tlb_mem *mem = &io_tlb_
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
-
static void __init pci_xen_swiotlb_init(void)
{
if (!xen_initial_domain() && !x86_swiotlb_enable)
return;
x86_swiotlb_enable = true;
- xen_swiotlb = true;
- xen_swiotlb_init_early();
+ swiotlb_i
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
-void __init swiotlb_init(bool addressing_limit, unsigned int flags)
+void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
+ int (*remap)(void *tlb, unsigned long nslabs))
{
- size_t bytes = PAGE_ALIGN(defau
: Boris Ostrovsky
Applied to for-linus-5.18
On 3/5/22 8:38 AM, zhanglianjie wrote:
Use helper macro __ATTR_RW to define HYPERVISOR_ATTR_RW to make code more clear.
Minor readability improvement.
Signed-off-by: zhanglianjie
Reviewed-by: Boris Ostrovsky
Applied to for-linus-5.18 (with whitespace change noted in commit message)
ter the 'vcpu_info' for boot vcpu is
registered when the boot vcpu is >= 32.
This issue can be reproduced on purpose via below command at the guest
side when kdump/kexec is enabled:
"taskset -c 33 echo c > /proc/sysrq-trigger"
The bugfix for PVM is not implemented
On 2/27/22 10:15 PM, Qing Wang wrote:
From: Wang Qing
Use the helper function time_is_{before,after}_jiffies() to improve
code readability.
Signed-off-by: Wang Qing
Reviewed-by: Boris Ostrovsky
Applied to for-linus-5.18
On 3/9/22 1:18 AM, Christoph Hellwig wrote:
On Tue, Mar 08, 2022 at 04:38:21PM -0500, Boris Ostrovsky wrote:
On 3/1/22 5:53 AM, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
On 3/1/22 5:53 AM, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from xen_swiotlb_fixup, so we don't even need that quirk.
Any chance this patch could be split? Lots of thin
On 3/4/22 12:43 PM, Christoph Hellwig wrote:
On Fri, Mar 04, 2022 at 12:36:17PM -0500, Boris Ostrovsky wrote:
I bisected it to "x86: remove the IOMMU table infrastructure" but haven't
actually looked at the code yet.
That looks like the swiotlb buffer did not get initialize
1 - 100 of 1033 matches
Mail list logo
