On 03.01.24 08:16, Bibo Mao wrote:
The patch add paravirt interface for guest kernel, it checks whether
system runs on VM mode. If it is, it will detect hypervisor type. And
returns true it is KVM hypervisor, else return false. Currently only
KVM hypervisor is supported, so there is only
On 02.03.21 07:28, Juergen Gross wrote:
In order to help identifying problems with IPI handling and remote
function execution add some more data to IPI debugging code.
There have been multiple reports of cpus looping long times (many
seconds) in smp_call_function_many() waiting for another cpu
On 17.03.21 12:04, Roger Pau Monne wrote:
This partially reverts commit 882213990d32fd224340a4533f6318dd152be4b2.
There's no need to special case XEN_UNPOPULATED_ALLOC anymore in order
to correctly size the p2m. The generic memory hotplug option has
already been tied together with the Xen
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 10.03.21 15:27, Borislav Petkov wrote:
On Tue, Mar 09, 2021 at 02:48:06PM +0100, Juergen Gross wrote:
diff --git a/arch/x86/include/asm/alternative.h
b/arch/x86/include/asm/alternative.h
index 89889618ae01..4fb844e29d26 100644
--- a/arch/x86/include/asm/alternative.h
+++
On 10.03.21 15:15, Borislav Petkov wrote:
On Wed, Mar 10, 2021 at 08:52:40AM +0100, Jürgen Groß wrote:
Did you look at patch 13? :-)
Well, I usually review in increasing patch order. :-P
But make that change here pls because otherwise unnecessary churn.
Okay.
Juergen
On 10.03.21 07:07, Borislav Petkov wrote:
On Tue, Mar 09, 2021 at 02:48:05PM +0100, Juergen Gross wrote:
Add support for alternative patching for the case a feature is not
present on the current cpu.
For users of ALTERNATIVE() and friends an inverted feature is specified
by applying the
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 08.03.21 21:33, Boris Ostrovsky wrote:
On 3/6/21 11:18 AM, Juergen Gross wrote:
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to
On 23.02.21 10:26, Ross Lagerwall wrote:
On 2021-02-19 15:40, Juergen Gross wrote:
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to
On 23.02.21 10:26, Ross Lagerwall wrote:
On 2021-02-19 15:40, Juergen Gross wrote:
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to
On 03.03.21 10:36, maqiang wrote:
We get 1 warning when building kernel with W=1:
arch/x86/xen/efi.c:130:13: warning:
no previous prototype for ‘xen_efi_init’ [-Wmissing-prototypes]
void __init xen_efi_init(struct boot_params *boot_params)
In fact, this function is declared as a static
On 01.03.21 18:07, Peter Zijlstra wrote:
On Mon, Mar 01, 2021 at 11:13:36AM +0100, Juergen Gross wrote:
In order to help identifying problems with IPI handling and remote
function execution add some more data to IPI debugging code.
There have been multiple reports of cpus looping long times
On 01.03.21 17:16, Boris Ostrovsky wrote:
On 3/1/21 9:11 AM, Rafael J. Wysocki wrote:
On Sun, Feb 28, 2021 at 2:49 AM Boris Ostrovsky
wrote:
On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
The ACPI_DEBUG_PRINT() macro is used in a few places in
xen-acpi-cpuhotplug.c
On 01.03.21 18:07, Peter Zijlstra wrote:
On Mon, Mar 01, 2021 at 11:13:36AM +0100, Juergen Gross wrote:
In order to help identifying problems with IPI handling and remote
function execution add some more data to IPI debugging code.
There have been multiple reports of cpus looping long times
On 01.03.21 16:45, Peter Zijlstra wrote:
On Sun, Feb 28, 2021 at 04:07:04PM -0800, Paul E. McKenney wrote:
On Fri, Feb 26, 2021 at 10:05:51PM +0100, Peter Zijlstra wrote:
On Fri, Feb 26, 2021 at 10:12:05AM -0800, Paul E. McKenney wrote:
On Fri, Feb 26, 2021 at 05:38:44PM +0100, Peter Zijlstra
On 24.02.21 15:20, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c03c21ba6f4e95e406a1a7b4c34ef334b977c194
commit: ab234a260b1f625b26cbefa93ca365b0ae66df33 x86/pv: Rework
arch_local_irq_restore() to not use popf
date: 2
On 20.02.21 23:32, Peter Zijlstra wrote:
On Sat, Feb 20, 2021 at 06:41:01PM +0100, Borislav Petkov wrote:
- if we had negative alternatives objtool doesn't need to actually
rewrite code in this case. It could simply emit alternative entries
and call it a day.
I don't mind the
On 17.02.21 14:29, Ross Lagerwall wrote:
On 2021-02-11 10:16, Juergen Gross wrote:
For avoiding read- and write-tearing by the compiler use READ_ONCE()
and WRITE_ONCE() for accessing the ring indices in evtchn.c.
Signed-off-by: Juergen Gross
---
V2:
- modify all accesses (Julien Grall)
---
On 15.02.21 22:35, Boris Ostrovsky wrote:
On 2/11/21 5:16 AM, Juergen Gross wrote:
@@ -622,6 +623,7 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
bool spurious)
}
info->eoi_time = 0;
+ smp_store_release(>is_active, 0);
Can this be done in
On 14.02.21 22:34, Julien Grall wrote:
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an
On 10.02.21 18:06, Julien Grall wrote:
From: Julien Grall
After Commit 3499ba8198cad ("xen: Fix event channel callback via
INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
recent to a guest hang during boot.
If there hang wasn't there, we would have ended up to call
On 08.02.21 15:20, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 13:58, Jürgen Groß wrote:
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is
to re-use
On 08.02.21 13:23, Jan Beulich wrote:
On 08.02.2021 13:15, Jürgen Groß wrote:
On 08.02.21 12:54, Jan Beulich wrote:
On 08.02.2021 11:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11
On 08.02.21 12:54, Jan Beulich wrote:
On 08.02.2021 11:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is to
re-use what's already existing rather than trying to re-invent the
wheel with an extra lock
On 08.02.21 12:40, Julien Grall wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1
On 08.02.21 11:23, Andrew Cooper wrote:
On 08/02/2021 09:50, Jan Beulich wrote:
On 08.02.2021 10:44, Andrew Cooper wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
The ring buffer for user events is used in the local system only, so
smp barriers are fine for ensuring consistency.
On 08.02.21 10:54, Julien Grall wrote:
On 08/02/2021 09:41, Jürgen Groß wrote:
On 08.02.21 10:11, Julien Grall wrote:
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches
On 08.02.21 11:06, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
@@ -1798,6 +1818,29 @@ static void mask_ack_dynirq(struct irq_data *data)
ack_dynirq(data);
}
+static void lateeoi_ack_dynirq(struct irq_data *data)
+{
+ struct irq_info *info =
On 08.02.21 10:38, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
The ring buffer for user events is used in the local system only, so
smp barriers are fine for ensuring consistency.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Albeit I
On 08.02.21 10:11, Julien Grall wrote:
Hi Juergen,
On 07/02/2021 12:58, Jürgen Groß wrote:
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue
On 06.02.21 19:46, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Thanks for helping to figure out the problem. Unfortunately, I still see
On 06.02.21 12:20, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port.
The same applies to
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following warning
with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but apparently not enabled;
per-user a86a4c1b
[ 589.593259] WARNING: CPU: 0 PID: at
On 02.02.21 11:17, Jiapeng Chong wrote:
Fix the following coccicheck warnings:
./drivers/net/xen-netfront.c:1816:52-54: WARNING !A || A && B is
equivalent to !A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
Reviewed-by: Juergen Gross
Juergen
On 04.02.21 00:48, Jakub Kicinski wrote:
On Tue, 2 Feb 2021 08:09:38 +0100 Juergen Gross wrote:
Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
xenvif_rx_ring_slots_available() is no longer called only from the rx
queue kernel thread, so it needs to access the rx queue
On 02.02.21 16:26, Igor Druzhinin wrote:
On 02/02/2021 07:09, Juergen Gross wrote:
Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
xenvif_rx_ring_slots_available() is no longer called only from the rx
queue kernel thread, so it needs to access the rx queue with the
On 29.01.21 07:20, Dongli Zhang wrote:
On 1/28/21 5:04 AM, Paul Durrant wrote:
From: Paul Durrant
Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
behaviour of xen-blkback when connecting to a
On 29.01.21 01:51, Marek Marczykowski-Górecki wrote:
On Thu, Jan 28, 2021 at 07:03:00PM -0500, Boris Ostrovsky wrote:
On 1/28/21 6:52 PM, Michael D Labriola wrote:
Hey, everyone. I've run into problems starting up my Xen domUs as of
the latest batch of stable updates. Whenever I try to
On 27.01.21 12:23, Andrew Cooper wrote:
On 27/01/2021 10:26, Jürgen Groß wrote:
On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..ca5ac10fcbf7 100644
--- a/arch/x86/xen
On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..ca5ac10fcbf7 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,12 @@
On 19.01.21 11:57, Roger Pau Monne wrote:
This is inline with the specification described in blkif.h:
* discard-granularity: should be set to the physical block size if
node is not present.
* discard-alignment, discard-secure: should be set to 0 if node not
present.
This was
On 25.01.21 18:26, Andrew Cooper wrote:
On 25/01/2021 14:00, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..82948251f57b 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,14 @@
On 21.01.21 22:29, Josh Poimboeuf wrote:
This indirect jump is harmless; annotate it to keep objtool's retpoline
validation happy.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Signed-off-by: Josh Poimboeuf
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description:
On 19.01.21 13:06, Borislav Petkov wrote:
On Tue, Jan 19, 2021 at 12:35:42PM +0100, Jürgen Groß wrote:
In fact this should rather be named "X86_FEATURE_TRUE", as this is its
semantics.
And I think I can define it to the value 0x instead of using a
"real" bit for it.
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 07.01.21 20:08, Borislav Petkov wrote:
On Thu, Dec 17, 2020 at 10:31:25AM +0100, Juergen Gross wrote:
Instead of only supporting to modify instructions when a specific
feature is set, support doing so for the case a feature is not set.
As today a feature is specified using a 16 bit quantity
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 19.01.21 11:57, Roger Pau Monne wrote:
This is inline with the specification described in blkif.h:
* discard-granularity: should be set to the physical block size if
node is not present.
* discard-alignment, discard-secure: should be set to 0 if node not
present.
This was
On 18.01.21 15:12, Frederic Weisbecker wrote:
From: Peter Zijlstra
Some static call declarations are going to be needed on low level header
files. Move the necessary material to the dedicated static call types
header to avoid inclusion dependency hell.
Signed-off-by: Peter Zijlstra (Intel)
On 19.01.21 11:06, Roger Pau Monné wrote:
On Tue, Jan 19, 2021 at 08:43:01AM +0100, Jürgen Groß wrote:
On 18.01.21 16:15, Roger Pau Monne wrote:
Don't require the discard-alignment xenstore node to be present in
order to correctly setup the feature. This can happen with versions of
QEMU
On 18.01.21 16:15, Roger Pau Monne wrote:
Don't require the discard-alignment xenstore node to be present in
order to correctly setup the feature. This can happen with versions of
QEMU that only write the discard-granularity but not the
discard-alignment node.
Assume discard-alignment is 0 if
On 15.01.21 20:11, Randy Dunlap wrote:
Fix build error in x86/xen/ when PARAVIRT_SPINLOCKS is not enabled.
Fixes this build error:
../arch/x86/xen/smp_hvm.c: In function ‘xen_hvm_smp_init’:
../arch/x86/xen/smp_hvm.c:77:3: error: ‘nopvspin’ undeclared (first use in this
function)
nopvspin
On 14.01.21 20:40, Josh Poimboeuf wrote:
It's kernel policy to not have (unannotated) indirect jumps because of
Spectre v2. This one's probably harmless, but better safe than sorry.
Convert it to a retpoline.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Signed-off-by: Josh Poimboeuf
---
On 14.01.21 20:40, Josh Poimboeuf wrote:
The Xen hypercall page is filled with zeros, causing objtool to fall
through all the empty hypercall functions until it reaches a real
function, resulting in a stack state mismatch.
The build-time contents of the hypercall page don't matter, since it
On 12.01.21 12:53, Roger Pau Monne wrote:
Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
addr = 0 in order to fetch the size of a specific resource.
Add a shortcut to the default map resource path, since fetching the
size requires no address to be passed in, and thus no VMA
On 12.01.21 12:53, Roger Pau Monne wrote:
Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
addr = 0 in order to fetch the size of a specific resource.
Add a shortcut to the default map resource path, since fetching the
size requires no address to be passed in, and thus no VMA
On 12.01.21 11:03, Roger Pau Monné wrote:
On Tue, Jan 12, 2021 at 06:57:30AM +0100, Jürgen Groß wrote:
On 11.01.21 16:29, Roger Pau Monne wrote:
Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
addr = 0 in order to fetch the size of a specific resource.
Add a shortcut
On 12.01.21 06:50, Jürgen Groß wrote:
On 11.01.21 23:39, Andrew Cooper wrote:
On 11/01/2021 22:09, boris.ostrov...@oracle.com wrote:
On 1/11/21 10:29 AM, Roger Pau Monne wrote:
+ xdata.domid = kdata.dom;
+ xdata.type = kdata.type;
+ xdata.id = kdata.id;
+
+ if (!kdata.addr
On 11.01.21 16:29, Roger Pau Monne wrote:
Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
addr = 0 in order to fetch the size of a specific resource.
Add a shortcut to the default map resource path, since fetching the
size requires no address to be passed in, and thus no VMA
On 11.01.21 23:39, Andrew Cooper wrote:
On 11/01/2021 22:09, boris.ostrov...@oracle.com wrote:
On 1/11/21 10:29 AM, Roger Pau Monne wrote:
+ xdata.domid = kdata.dom;
+ xdata.type = kdata.type;
+ xdata.id = kdata.id;
+
+ if (!kdata.addr && !kdata.num) {
I think we should
On 16.12.20 15:08, Jason Andryuk wrote:
commit bfda93aee0ec ("xen: Kconfig: nest Xen guest options")
accidentally re-added X86_64 as a dependency to XEN_512GB. It was
originally removed in commit a13f2ef168cb ("x86/xen: remove 32-bit Xen
PV guest support"). Remove it again.
Fixes:
On 17.12.20 19:25, Andrew Cooper wrote:
On 16/12/2020 08:21, Jürgen Groß wrote:
On 15.12.20 21:59, Andrew Cooper wrote:
On 15/12/2020 11:10, Juergen Gross wrote:
In case a process waits for any Xenstore action in the xenbus driver
it should be interruptible by signals.
Signed-off-by: Juergen
On 17.12.20 09:17, SeongJae Park wrote:
From: SeongJae Park
This commit adds a counter of pending messages for each watch in the
struct. It is used to skip unnecessary pending messages lookup in
'unregister_xenbus_watch()'. It could also be used in 'will_handle'
callback.
This is part of
On 16.12.20 15:08, Jason Andryuk wrote:
commit bfda93aee0ec ("xen: Kconfig: nest Xen guest options")
accidentally re-added X86_64 as a dependency to XEN_512GB. It was
originally removed in commit a13f2ef168cb ("x86/xen: remove 32-bit Xen
PV guest support"). Remove it again.
Fixes:
On 15.12.20 21:59, Andrew Cooper wrote:
On 15/12/2020 11:10, Juergen Gross wrote:
In case a process waits for any Xenstore action in the xenbus driver
it should be interruptible by signals.
Signed-off-by: Juergen Gross
---
V2:
- don't special case SIGKILL as libxenstore is handling -EINTR
On 27.11.20 17:07, t...@redhat.com wrote:
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
Applied to: xen/tip.git for-linus-5.11
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital
On 20.11.20 19:32, Gustavo A. R. Silva wrote:
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R.
On 20.11.20 19:40, Gustavo A. R. Silva wrote:
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R.
On 14.10.20 19:53, Jason Andryuk wrote:
A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in. Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.
The first patch introduces XEN_PVHVM_GUEST as a toplevel item and
changes XEN_PVHVM to a hidden
On 17.09.20 14:55, Qinglang Miao wrote:
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao
Applied to: xen/tip.git for-linus-5.11
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital
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 15.12.20 08:27, Jürgen Groß wrote:
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following
warning with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but apparently not enabled;
per-user a86a4c1b
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following warning
with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but apparently not enabled;
per-user a86a4c1b
[ 589.593259] WARNING: CPU: 0 PID: at
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN
On 11.12.20 11:13, Thomas Gleixner wrote:
On Fri, Dec 11 2020 at 07:17, Jürgen Groß wrote:
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN
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 10.12.20 12:14, Roger Pau Monné wrote:
On Tue, Dec 08, 2020 at 07:45:00AM +0100, Jürgen Groß wrote:
On 07.12.20 21:48, Jason Andryuk wrote:
On Mon, Dec 7, 2020 at 8:30 AM Juergen Gross wrote:
Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated
memory") introd
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 09.12.20 13:03, Borislav Petkov wrote:
On Wed, Dec 09, 2020 at 08:30:53AM +0100, Jürgen Groß wrote:
Hey, I already suggested to use ~FEATURE for that purpose (see
https://lore.kernel.org/lkml/f105a63d-6b51-3afb-83e0-e899ea408...@suse.com/
Great minds think alike!
:-P
I'd rather make
On 08.12.20 19:43, Borislav Petkov wrote:
On Fri, Nov 20, 2020 at 12:46:25PM +0100, Juergen Gross wrote:
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index dad350d42ecf..ffa23c655412 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++
On 07.12.20 21:48, Jason Andryuk wrote:
On Mon, Dec 7, 2020 at 8:30 AM Juergen Gross wrote:
Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated
memory") introduced usage of ZONE_DEVICE memory for foreign memory
mappings.
Unfortunately this collides with using page->lru for Xen
On 06.12.20 18:22, Marek Marczykowski-Górecki wrote:
This reverts commit 9e2369c06c8a181478039258a4598c1ddd2cadfa.
On a Xen PV dom0, with NVME disk, this makes the dom0 crash when starting
a domain. This looks like some bad interaction between xen-blkback and
xen-scsiback has the same use
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 27.11.20 17:07, t...@redhat.com wrote:
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
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 19.11.20 13:01, Peter Zijlstra wrote:
On Thu, Nov 19, 2020 at 11:51:00AM +, Shinichiro Kawasaki wrote:
I tried Peter's patch in my test system and result looks good. The warning is
still observed with 5.10-rc4. With the patch on top of 5.10-rc4, the warning
disappeared.
The patch on
1 - 100 of 262 matches
Mail list logo
