On 11.03.21 13:51, Borislav Petkov wrote:
On Thu, Mar 11, 2021 at 01:50:26PM +0100, Borislav Petkov wrote:
and move the cleanups patches 13 and 14 to the beginning of the set?
Yeah, 14 needs ALTERNATIVE_TERNARY so I guess after patch 5, that is.
I'm putting 13 at the begin of the series and
On 09.03.21 19:57, Borislav Petkov wrote:
On Tue, Mar 09, 2021 at 02:48:03PM +0100, Juergen Gross wrote:
@@ -167,6 +168,17 @@ static u64 native_steal_clock(int cpu)
return 0;
}
+DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
+DEFINE_STATIC_CALL(pv_sched_clock,
On 08.03.21 19:30, Borislav Petkov wrote:
On Mon, Mar 08, 2021 at 01:28:43PM +0100, Juergen Gross wrote:
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 36cd71fa097f..04b3067f31b5 100644
--- a/arch/x86/include/asm/paravirt.h
+++
On 08.03.21 18:00, Boris Ostrovsky wrote:
On 3/8/21 7:28 AM, Juergen Gross wrote:
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -379,11 +379,6 @@ void xen_timer_resume(void)
}
}
-static const struct pv_time_ops xen_time_ops __initconst = {
- .sched_clock =
On 17.12.20 18:31, Michael Kelley wrote:
From: Juergen Gross Sent: Thursday, December 17, 2020 1:31 AM
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this
On 06.01.21 11:03, Borislav Petkov wrote:
On Thu, Dec 17, 2020 at 10:31:24AM +0100, Juergen Gross wrote:
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this
On 15.12.20 15:54, Peter Zijlstra wrote:
On Tue, Dec 15, 2020 at 03:18:34PM +0100, Peter Zijlstra wrote:
Ah, I was waiting for Josh to have an opinion (and then sorta forgot
about the whole thing again). Let me refresh and provide at least a
Changelog.
How's this then?
Thanks, will add it
Peter,
On 23.11.20 14:43, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 01:53:42PM +0100, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:18PM +0100, Juergen Gross wrote:
30 files changed, 325 insertions(+), 598 deletions(-)
Much awesome ! I'll try and get that objtool thing sorted.
On 10.12.20 21:15, Thomas Gleixner wrote:
Mark tripped over the creative irqflags handling in the IO-APIC timer
delivery check which ends up doing:
local_irq_save(flags);
local_irq_enable();
local_irq_restore(flags);
which triggered a new consistency check he's
On 09.12.20 15:02, Mark Rutland wrote:
On Wed, Dec 09, 2020 at 01:27:10PM +, Mark Rutland wrote:
On Sun, Nov 22, 2020 at 01:44:53PM -0800, Andy Lutomirski wrote:
On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
On 20.11.20 12:59, Peter Zijlstra wrote:
If someone were to write
On 02.12.20 13:32, Borislav Petkov wrote:
On Fri, Nov 20, 2020 at 12:46:22PM +0100, Juergen Gross wrote:
@@ -123,12 +115,15 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe,
SYM_L_GLOBAL)
* Try to use SYSRET instead of IRET if we're returning to
* a completely clean 64-bit
On 22.11.20 22:44, Andy Lutomirski wrote:
On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
On 20.11.20 12:59, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
+static __always_inline void arch_local_irq_restore(unsigned long flags
On 20.11.20 12:59, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
+static __always_inline void arch_local_irq_restore(unsigned long flags)
+{
+ if (!arch_irqs_disabled_flags(flags))
+ arch_local_irq_enable();
+}
If someone were to
On 20.11.20 13:08, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
+#define PVOP_CALL(rettype, op, clbr, call_clbr, extra_clbr, ...) \
({ \
PVOP_CALL_ARGS;
On 20.11.20 13:01, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:24PM +0100, Juergen Gross wrote:
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this
On 20.11.20 12:59, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
+static __always_inline void arch_local_irq_restore(unsigned long flags)
+{
+ if (!arch_irqs_disabled_flags(flags))
+ arch_local_irq_enable();
+}
If someone were to
On 16.11.20 17:28, Andy Lutomirski wrote:
On Mon, Nov 16, 2020 at 7:23 AM Juergen Gross wrote:
USERGS_SYSRET64 is used to return from a syscall via sysret, but
a Xen PV guest will nevertheless use the iret hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the
On 08.09.20 22:10, David Hildenbrand wrote:
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc:
On 08.09.20 22:10, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc:
On 21.08.20 12:34, David Hildenbrand wrote:
Let's reuse the new mechanism to merge system ram resources below the
root. We are the only one hotplugging system ram (e.g., DIMMs don't apply),
so this is safe to be used.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
On 11.08.20 10:12, Peter Zijlstra wrote:
On Tue, Aug 11, 2020 at 09:57:55AM +0200, Jürgen Groß wrote:
On 11.08.20 09:41, Peter Zijlstra wrote:
On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
My hypothesis here is simply that kvm_wait() may be called in a place
where we get
On 11.08.20 10:12, Peter Zijlstra wrote:
On Tue, Aug 11, 2020 at 09:57:55AM +0200, Jürgen Groß wrote:
On 11.08.20 09:41, Peter Zijlstra wrote:
On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
My hypothesis here is simply that kvm_wait() may be called in a place
where we get
On 11.08.20 09:41, Peter Zijlstra wrote:
On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
My hypothesis here is simply that kvm_wait() may be called in a place
where we get the same case I mentioned to Peter,
raw_local_irq_save(); /* or other IRQs off without tracing */
On 11.08.20 09:00, Marco Elver wrote:
On Fri, 7 Aug 2020 at 17:19, Marco Elver wrote:
On Fri, Aug 07, 2020 at 02:08PM +0200, Marco Elver wrote:
On Fri, 7 Aug 2020 at 14:04, Jürgen Groß wrote:
On 07.08.20 13:38, Marco Elver wrote:
On Fri, Aug 07, 2020 at 12:35PM +0200, Jürgen Groß wrote
On 10.08.20 18:53, Boris Ostrovsky wrote:
On 8/10/20 12:39 AM, Jürgen Groß wrote:
On 09.08.20 04:34, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
@@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
{
pteval_t ret;
- if (sizeof(pteval_t) > sizeof(l
On 09.08.20 04:34, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
@@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
{
pteval_t ret;
- if (sizeof(pteval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32);
-
On 07.08.20 13:38, Marco Elver wrote:
On Fri, Aug 07, 2020 at 12:35PM +0200, Jürgen Groß wrote:
On 07.08.20 11:50, Marco Elver wrote:
On Fri, Aug 07, 2020 at 11:24AM +0200, Jürgen Groß wrote:
On 07.08.20 11:01, Marco Elver wrote:
On Thu, 6 Aug 2020 at 18:06, Marco Elver wrote:
On Thu, 6
On 07.08.20 11:50, Marco Elver wrote:
On Fri, Aug 07, 2020 at 11:24AM +0200, Jürgen Groß wrote:
On 07.08.20 11:01, Marco Elver wrote:
On Thu, 6 Aug 2020 at 18:06, Marco Elver wrote:
On Thu, 6 Aug 2020 at 15:17, Marco Elver wrote:
On Thu, Aug 06, 2020 at 01:32PM +0200, pet...@infradead.org
On 07.08.20 11:39, pet...@infradead.org wrote:
On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote:
-# else
- const unsigned char cpu_iret[1];
-# endif
};
static const struct patch_xxl patch_data_xxl = {
@@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl
On 07.08.20 11:01, Marco Elver wrote:
On Thu, 6 Aug 2020 at 18:06, Marco Elver wrote:
On Thu, 6 Aug 2020 at 15:17, Marco Elver wrote:
On Thu, Aug 06, 2020 at 01:32PM +0200, pet...@infradead.org wrote:
On Thu, Aug 06, 2020 at 09:47:23AM +0200, Marco Elver wrote:
Testing my hypothesis that
On 05.08.20 16:12, pet...@infradead.org wrote:
On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote:
On Wed, Aug 05, 2020 at 03:42PM +0200, pet...@infradead.org wrote:
Shouldn't we __always_inline those? They're going to be really small.
I can send a v2, and you can choose. For
On 02.07.20 16:48, Brian Gerst wrote:
On Wed, Jul 1, 2020 at 7:07 AM Juergen Gross wrote:
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires 64-bit support
On 17.04.20 01:45, Deep Shah wrote:
Thomas Hellstrom will be handing over VMware's maintainership of these
interfaces to Deep Shah.
Signed-off-by: Deep Shah
Acked-by: Thomas Hellstrom
Pushed to xen/tip.git for-linus-5.8
Juergen
___
Virtualization
On 17.04.20 08:22, Jürgen Groß wrote:
On 17.04.20 01:45, Deep Shah wrote:
Thomas Hellstrom will be handing over VMware's maintainership of these
interfaces to Deep Shah.
Signed-off-by: Deep Shah
Acked-by: Thomas Hellstrom
Acked-by: Juergen Gross
BTW, I can carry this patch through
On 17.04.20 01:45, Deep Shah wrote:
Thomas Hellstrom will be handing over VMware's maintainership of these
interfaces to Deep Shah.
Signed-off-by: Deep Shah
Acked-by: Thomas Hellstrom
Acked-by: Juergen Gross
Juergen
___
Virtualization mailing
On 08.04.20 14:08, Peter Zijlstra wrote:
On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote:
Mechanism: the patching itself is done using stop_machine(). That is
not ideal -- text_poke_stop_machine() was replaced with INT3+emulation
via text_poke_bp(), but I'm using this to address two
On 08.04.20 07:02, Ankur Arora wrote:
A KVM host (or another hypervisor) might advertise paravirtualized
features and optimization hints (ex KVM_HINTS_REALTIME) which might
become stale over the lifetime of the guest. For instance, the
Then this hint is wrong if it can't be guaranteed.
host
On 28.02.20 17:47, Alex Bennée wrote:
Jan Kiszka writes:
On 28.02.20 11:30, Jan Kiszka wrote:
On 28.02.20 11:16, Alex Bennée wrote:
Hi,
I believe there has been some development work for supporting VIRTIO on
Xen although it seems to have stalled according to:
Friendly ping...
On 18.02.20 16:47, Juergen Gross wrote:
Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control
ioperm() as well") reworked the iopl syscall to use I/O bitmaps.
Unfortunately this broke Xen PV domains using that syscall as there
is currently no I/O bitmap support in
On 19.02.20 11:42, Joerg Roedel wrote:
Hi Jürgen,
On Wed, Feb 12, 2020 at 05:28:21PM +0100, Jürgen Groß wrote:
Xen-PV is clearing BSS as the very first action.
In the kernel image? Or in the ELF loader before jumping to the kernel
image?
In the kernel image.
See arch/x86/xen/xen-head.S
On 19.02.20 10:22, Thomas Gleixner wrote:
Jürgen Groß writes:
On 18.02.20 22:03, Thomas Gleixner wrote:
BTW, why isn't stuff like this not catched during next or at least
before the final release? Is nothing running CI on upstream with all
that XEN muck active?
This problem showed up
On 18.02.20 22:03, Thomas Gleixner wrote:
Juergen Gross writes:
Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control
ioperm() as well") reworked the iopl syscall to use I/O bitmaps.
Unfortunately this broke Xen PV domains using that syscall as there
is currently no I/O bitmap
On 12.02.20 17:23, Andy Lutomirski wrote:
On Feb 12, 2020, at 3:55 AM, Joerg Roedel wrote:
On Tue, Feb 11, 2020 at 02:41:25PM -0800, Andy Lutomirski wrote:
On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel wrote:
From: Joerg Roedel
With SEV-ES, exception handling is needed very early, even
43 matches
Mail list logo
