Instead of stacking alternative and paravirt patching, use the new
ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
handling.
This eliminates the need to be careful regarding the sequence of
alternative and paravirt patching.
For call depth tracking callthunks_setup() needs to
Now that paravirt is using the alternatives patching infrastructure,
remove the paravirt patching code.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/paravirt.h | 18
arch/x86/include/asm/paravirt_types.h | 40
Introduce the macro ALT_NOT_XEN as a short form of
ALT_NOT(X86_FEATURE_XENPV).
Suggested-by: Peter Zijlstra (Intel)
Signed-off-by: Juergen Gross
---
V3:
- split off from next patch
---
arch/x86/include/asm/paravirt.h | 42 ---
arch/x86/include/asm/paravirt_types.h
This is a small series getting rid of paravirt patching by switching
completely to alternative patching for the same functionality.
The basic idea is to add the capability to switch from indirect to
direct calls via a special alternative patching option.
This removes _some_ of the paravirt macro
As a preparation for replacing paravirt patching completely by
alternative patching, move some backend functions and #defines to
alternative code and header.
Signed-off-by: Juergen Gross
---
V4:
- rename x86_nop() to nop_func() and x86_BUG() to BUG_func() (Boris
Petkov)
---
On 25.10.23 12:34, Borislav Petkov wrote:
On Thu, Oct 19, 2023 at 11:15:16AM +0200, Juergen Gross wrote:
+/* Low-level backend functions usable from alternative code replacements. */
+DEFINE_ASM_FUNC(x86_nop, "", .entry.text);
+EXPORT_SYMBOL_GPL(x86_nop);
This is all x86 code so you don't
On 26.10.23 04:44, kernel test robot wrote:
Hello,
kernel test robot noticed "BUG:unable_to_handle_page_fault_for_address" on:
commit: b0b8b06548f7984351b503ec5f5c13fa80bae6a2 ("[PATCH v3 4/5] x86/paravirt:
switch mixed paravirt/alternative calls to alternative_2")
url:
On 25.10.23 15:44, Borislav Petkov wrote:
On Wed, Oct 25, 2023 at 03:31:07PM +0200, Juergen Gross wrote:
There is
#define nop() asm volatile ("nop")
in arch/x86/include/asm/special_insns.h already.
Then call it "nop_func" or so.
Okay.
It might not be needed now, but are you sure we
On 25.10.23 12:34, Borislav Petkov wrote:
On Thu, Oct 19, 2023 at 11:15:16AM +0200, Juergen Gross wrote:
+/* Low-level backend functions usable from alternative code replacements. */
+DEFINE_ASM_FUNC(x86_nop, "", .entry.text);
+EXPORT_SYMBOL_GPL(x86_nop);
This is all x86 code so you don't
Now that paravirt is using the alternatives patching infrastructure,
remove the paravirt patching code.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/paravirt.h | 18
arch/x86/include/asm/paravirt_types.h | 40
Instead of stacking alternative and paravirt patching, use the new
ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
handling.
This eliminates the need to be careful regarding the sequence of
alternative and paravirt patching.
For call depth tracking callthunks_setup() needs to
Introduce the macro ALT_NOT_XEN as a short form of
ALT_NOT(X86_FEATURE_XENPV).
Suggested-by: Peter Zijlstra (Intel)
Signed-off-by: Juergen Gross
---
V3:
- split off from next patch
---
arch/x86/include/asm/paravirt.h | 42 ---
arch/x86/include/asm/paravirt_types.h
This is a small series getting rid of paravirt patching by switching
completely to alternative patching for the same functionality.
The basic idea is to add the capability to switch from indirect to
direct calls via a special alternative patching option.
This removes _some_ of the paravirt macro
As a preparation for replacing paravirt patching completely by
alternative patching, move some backend functions and #defines to
alternative code and header.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/alternative.h| 16
On 18.10.23 13:34, Ingo Molnar wrote:
* Juergen Gross wrote:
On 16.10.23 16:29, Peter Zijlstra wrote:
On Mon, Oct 16, 2023 at 02:39:32PM +0200, Juergen Gross wrote:
Instead of stacking alternative and paravirt patching, use the new
ALT_FLAG_CALL flag to switch those mixed calls to pure
On 16.10.23 16:29, Peter Zijlstra wrote:
On Mon, Oct 16, 2023 at 02:39:32PM +0200, Juergen Gross wrote:
Instead of stacking alternative and paravirt patching, use the new
ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
handling.
This eliminates the need to be careful
Now that paravirt is using the alternatives patching infrastructure,
remove the paravirt patching code.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 18
arch/x86/include/asm/paravirt_types.h | 40
arch/x86/include/asm/text-patching.h | 12
Instead of stacking alternative and paravirt patching, use the new
ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
handling.
This eliminates the need to be careful regarding the sequence of
alternative and paravirt patching.
For call depth tracking callthunks_setup() needs to
As a preparation for replacing paravirt patching completely by
alternative patching, move some backend functions and #defines to
alternative code and header.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/alternative.h| 16
This is a small series getting rid of paravirt patching by switching
completely to alternative patching for the same functionality.
The basic idea is to add the capability to switch from indirect to
direct calls via a special alternative patching option.
This removes _some_ of the paravirt macro
While backporting an upstream patch to one of our older distro kernels I've
found a weird locking hierarchy in the virtio crypto driver:
virtio_config_changed():
spin_lock_irqsave()
->__virtio_config_changed()
->drv->config_changed() <- assume drv == virtio_crypto_driver
On 20.09.23 16:52, Peter Zijlstra wrote:
On Thu, Jun 08, 2023 at 04:03:33PM +0200, Juergen Gross wrote:
Instead of stacking alternative and paravirt patching, use the new
ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
handling.
This eliminates the need to be careful
On 13.09.23 15:26, Steven Rostedt wrote:
On Wed, 13 Sep 2023 13:38:27 +0200
Juergen Gross wrote:
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index 44a3f565264d..0577f0cdd231 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -6,26 +6,26 @@
This small series is cleaning up Xen lazy mode handling by removing
unused stuff and moving purely Xen-specific code away from general
kernel code.
The last patch is fixing a regression which was introduced in the
6.6 merge window.
Juergen Gross (3):
arm/xen: remove lazy mode related
Only Xen is using the paravirt lazy mode code, so it can be moved to
Xen specific sources.
This allows to make some of the functions static or to merge them into
their only call sites.
While at it do a rename from "paravirt" to "xen" for all moved
specifiers.
No functional change.
PING!
On 10.07.23 14:29, Juergen Gross wrote:
Any comments?
On 08.06.23 16:03, Juergen Gross wrote:
This is a small series getting rid of paravirt patching by switching
completely to alternative patching for the same functionality.
The basic idea is to add the capability to switch from
On 27.07.23 01:11, Kees Cook wrote:
Under W=1, this warning is visible in Clang 16 and newer:
arch/x86/kernel/paravirt.c:337:4: warning: cast from 'void (*)(struct
mmu_gather *, struct page *)' to 'void (*)(struct mmu_gather *, void *)'
converts to incompatible function type
Any comments?
On 08.06.23 16:03, Juergen Gross wrote:
This is a small series getting rid of paravirt patching by switching
completely to alternative patching for the same functionality.
The basic idea is to add the capability to switch from indirect to
direct calls via a special alternative
On 10.06.23 07:43, Randy Dunlap wrote:
Clarify language. Clean up grammar. Hyphenate some words.
Change "low-ops" to "low-level" since "low-ops" isn't defined or even
mentioned anywhere else in the kernel source tree.
Signed-off-by: Randy Dunlap
Cc: Juergen Gross
Cc: Ajay Kaher
Cc: Alexey
On 09.06.23 11:45, Hou Wenlong wrote:
Similar to struct alt_instr, make the struct paravirt_patch_site packed
and get rid of all the .align directives. This could save 2 bytes for
one entry on X86_64.
Suggested-by: Nadav Amit
Signed-off-by: Hou Wenlong
Reviewed-by: Juergen Gross
Juergen
Instead of stacking alternative and paravirt patching, use the new
ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
handling.
This eliminates the need to be careful regarding the sequence of
alternative and paravirt patching.
For call depth tracking callthunks_setup() needs to
As a preparation for replacing paravirt patching completely by
alternative patching, move some backend functions and #defines to
alternative code and header.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/alternative.h| 16
arch/x86/include/asm/paravirt.h |
This is a small series getting rid of paravirt patching by switching
completely to alternative patching for the same functionality.
The basic idea is to add the capability to switch from indirect to
direct calls via a special alternative patching option.
This removes _some_ of the paravirt macro
On 28.04.23 11:50, Hou Wenlong wrote:
Similar to the alternative patching, use relative reference for original
instruction rather than absolute one, which saves 8 bytes for one entry
on x86_64. And it could generate R_X86_64_PC32 relocation instead of
R_X86_64_64 relocation, which also reduces
On 12.05.23 18:49, Srivatsa S. Bhat wrote:
From: "Srivatsa S. Bhat (VMware)"
I have decided to change employers and I'm not sure if I'll be able to
spend as much time on the paravirt-ops subsystem going forward. So, I
would like to remove myself from the maintainer role for paravirt-ops.
All functions referenced via __PV_IS_CALLEE_SAVE() need to be assembler
functions, as those functions calls are hidden from gcc. In case the
kernel is compiled with "-fzero-call-used-regs" the compiler will
clobber caller-saved registers at the end of C functions, which will
result in unexpectedly
On 16.03.23 21:14, Peter Zijlstra wrote:
On Wed, Mar 08, 2023 at 04:42:10PM +0100, Juergen Gross wrote:
+DEFINE_PARAVIRT_ASM(pv_native_irq_disable, "cli", .text);
+DEFINE_PARAVIRT_ASM(pv_native_irq_enable, "sti", .text);
+DEFINE_PARAVIRT_ASM(pv_native_read_cr2, "mov %cr2, %rax", .text);
per
On 09.03.23 14:39, Borislav Petkov wrote:
On Wed, Mar 08, 2023 at 04:42:10PM +0100, Juergen Gross wrote:
All functions referenced via __PV_IS_CALLEE_SAVE() need to be assembler
functions, as those functions calls are hidden from gcc. In case the
kernel is compiled with "-fzero-call-used-regs"
All functions referenced via __PV_IS_CALLEE_SAVE() need to be assembler
functions, as those functions calls are hidden from gcc. In case the
kernel is compiled with "-fzero-call-used-regs" the compiler will
clobber caller-saved registers at the end of C functions, which will
result in unexpectedly
On 07.02.23 22:09, Srivatsa S. Bhat wrote:
On 2/6/23 11:59 PM, Juergen Gross wrote:
The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
sharing the same implementations in all cases: for Xen PV guests they
are pinning the PGD of the new mm_struct, and for all other cases
they are
The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
sharing the same implementations in all cases: for Xen PV guests they
are pinning the PGD of the new mm_struct, and for all other cases
they are a NOP.
In the end both callbacks are meant to register an address space with
the
On 16.01.23 07:01, Srivatsa S. Bhat wrote:
From: "Srivatsa S. Bhat (VMware)"
Under hypervisors that support mwait passthrough, a vCPU in mwait
CPU-idle state remains in guest context (instead of yielding to the
hypervisor via VMEXIT), which helps speed up wakeups from idle.
However, this runs
On 16.01.23 05:27, Srivatsa S. Bhat wrote:
Hi Juergen,
On 1/12/23 7:21 AM, Juergen Gross wrote:
The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
sharing the same implementations in all cases: for Xen PV guests they
are pinning the PGD of the new mm_struct, and for all other
The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
sharing the same implementations in all cases: for Xen PV guests they
are pinning the PGD of the new mm_struct, and for all other cases
they are a NOP.
So merge them to a common callback .mmu.enter_mmap (in contrast to the
On 24.11.22 12:51, Hou Wenlong wrote:
Similar to the alternative patching, use relative reference for original
instruction rather than absolute one, which saves 8 bytes for one entry
on x86_64. And it could generate R_X86_64_PC32 relocation instead of
R_X86_64_64 relocation, which also reduces
On 24.11.22 12:06, Hou Wenlong wrote:
On Thu, Nov 24, 2022 at 11:18:52AM +0100, Juergen Gross wrote:
On 24.11.22 09:51, Hou Wenlong wrote:
Similar to the alternative patching, use relative reference for original
instruction rather than absolute one, which saves 8 bytes for one entry
on x86_64.
On 24.11.22 09:51, Hou Wenlong wrote:
Similar to the alternative patching, use relative reference for original
instruction rather than absolute one, which saves 8 bytes for one entry
on x86_64. And it could generate R_X86_64_PC32 relocation instead of
8 bytes saved? I think those are 4 bytes
On 16.11.22 12:04, Peter Zijlstra wrote:
On Wed, Nov 09, 2022 at 02:44:18PM +0100, Juergen Gross wrote:
There are some paravirt assembler functions which are sharing a common
pattern. Introduce a macro DEFINE_PARAVIRT_ASM() for creating them.
Note that this macro is including explicit
There are some paravirt assembler functions which are sharing a common
pattern. Introduce a macro DEFINE_PARAVIRT_ASM() for creating them.
Note that this macro is including explicit alignment of the generated
functions, leading to __raw_callee_save___kvm_vcpu_is_preempted(),
_paravirt_nop() and
On 09.11.22 06:16, Srivatsa S. Bhat wrote:
Hi Juergen,
Sorry for the delay in reviewing this patch!
On 10/20/22 2:19 AM, Juergen Gross wrote:
There are some paravirt assembler functions which are sharing a common
pattern. Introduce a macro DEFINE_PARAVIRT_ASM() for creating them.
The
Ping?
On 20.10.22 11:19, Juergen Gross wrote:
There are some paravirt assembler functions which are sharing a common
pattern. Introduce a macro DEFINE_PARAVIRT_ASM() for creating them.
The explicit _paravirt_nop() prototype in paravirt.c isn't needed, as
it is included in paravirt_types.h
On 03.11.22 14:58, johnnyaiai wrote:
Thanks for reply! I think nopvspin parameters controls
pvspinlock or native spinlock. a vm guest always running
on virtspin wheather nopvspin sets or not when EXITS_HALT
not supported by hypervisor. So provide a missing parameter
'novirtspin'.
Your patch is
On 03.11.22 13:13, johnnyaiai wrote:
From: johnnyaiai
virt_spin_lock() is preferred over native qspinlock when
vCPU is preempted. But brings a lot of regression while
vCPU is not preempted. Provide a early param 'novirtlock'
to choose would be better.
will-it-scale/lock2_threads -s 10 -t 64
There are some paravirt assembler functions which are sharing a common
pattern. Introduce a macro DEFINE_PARAVIRT_ASM() for creating them.
The explicit _paravirt_nop() prototype in paravirt.c isn't needed, as
it is included in paravirt_types.h already.
Signed-off-by: Juergen Gross
---
On 23.09.22 09:05, Peter Zijlstra wrote:
On Thu, Jul 21, 2022 at 01:44:33PM -0700, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware)
VMware ESXi allows enabling a passthru mwait CPU-idle state in the
guest using the following VMX option:
monitor_control.mwait_in_guest = "TRUE"
This
On 19.09.22 12:00, Peter Zijlstra wrote:
vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd()
leaves .noinstr.text section
vmlinux.o: warning: objtool: default_idle+0x4: call to arch_safe_halt() leaves
.noinstr.text section
vmlinux.o: warning: objtool: xen_safe_halt+0xa:
On 16.09.22 11:00, Liang He wrote:
In jailhouse_paravirt(), we should hold the reference returned from
of_find_compatible_node() which has increased the refcount and then
call of_node_put() with it when done.
Fixes: 63338a38db95 ("jailhouse: Provide detection for non-x86 systems")
On 15.09.22 04:23, Liang He wrote:
In jailhouse_paravirt(), we should hold the reference returned from
of_find_compatible_node() which has increased the refcount and then
call of_node_put() with it when done.
Fixes: 63338a38db95 ("jailhouse: Provide detection for non-x86 systems")
On 14.09.22 18:21, Bill Wendling wrote:
The ZERO_CALL_USED_REGS feature may zero out caller-saved registers
before returning. However, alternate code may call this function without
first saving %[re]di, because the proper clobbers aren't taken into
account.
This shows up in
On 03.09.22 09:37, Kees Cook wrote:
The u16 "clobber" value is not used in .parainstructions since commit
27876f3882fd ("x86/paravirt: Remove clobbers from struct paravirt_patch_site")
Remove the u16 from the section macro, the argument from all macros, and
all now-unused CLBR_* macros.
Cc:
On 31.08.22 17:37, Dmitry Osipenko wrote:
Prepare gntdev driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
Acked-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description:
On 22.06.22 08:38, Juergen Gross wrote:
Instead of an all or nothing approach add support for requiring
restricted memory access per device.
Changes in V3:
- new patches 1 + 2
- basically complete rework of patch 3
Juergen Gross (3):
virtio: replace restricted mem access flag with callback
On 27.06.22 16:27, Guo Hui wrote:
The instructions assigned to the vcpu_is_preempted function parameter
in the X86 architecture physical machine are redundant instructions,
causing the multi-core performance of Unixbench to drop by about 4% to 5%.
The C function is as follows:
static bool
On 27.06.22 04:13, Guo Hui wrote:
The instructions assigned to the vcpu_is_preempted function parameter
in the X86 architecture physical machine are redundant instructions,
causing the multi-core performance of Unixbench to drop by about 4% to 5%.
The C function is as follows:
static bool
Instead of an all or nothing approach add support for requiring
restricted memory access per device.
Changes in V3:
- new patches 1 + 2
- basically complete rework of patch 3
Juergen Gross (3):
virtio: replace restricted mem access flag with callback
kernel: remove platform_has()
Instead of having a global flag to require restricted memory access
for all virtio devices, introduce a callback which can select that
requirement on a per-device basis.
For convenience add a common function returning always true, which can
be used for use cases like SEV.
Per default use a
On 02.06.22 21:23, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add support for restricting memory
access under Xen using specific
grant table [1] based DMA-mapping layer. Patch series is based on Juergen
Gross’ initial work [2]
On 04.05.22 17:57, Juergen Gross wrote:
Instead of using arch_has_restricted_virtio_memory_access() together
with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
with platform_has() and a new platform feature
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS.
Signed-off-by: Juergen Gross
In another patch series [1] the need has come up to have support for
a generic feature flag infrastructure.
This patch series is introducing that infrastructure and adds the first
use case.
I have decided to use a similar interface as the already known x86
cpu_has() function. As the new
Add a simple infrastructure for setting, resetting and querying
platform feature flags.
Flags can be either global or architecture specific.
Signed-off-by: Juergen Gross
---
V2:
- rename set/reset functions to platform_[set|clear]() (Boris Petkov,
Heiko Carstens)
- move function
Instead of using arch_has_restricted_virtio_memory_access() together
with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
with platform_has() and a new platform feature
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS.
Signed-off-by: Juergen Gross
---
V2:
- move setting of
On 28.04.22 20:35, Elliot Berman wrote:
From: Prakruthi Deepak Heragu
During hotplug, the stolen time data structure is unmapped and memset.
There is a possibility of the timer IRQ being triggered before memset
and stolen time is getting updated as part of this timer IRQ handler. This
causes
On 04.05.22 11:45, Will Deacon wrote:
On Thu, Apr 28, 2022 at 11:35:36AM -0700, Elliot Berman wrote:
From: Prakruthi Deepak Heragu
During hotplug, the stolen time data structure is unmapped and memset.
There is a possibility of the timer IRQ being triggered before memset
and stolen time is
On 27.04.22 18:30, Michael Kelley (LINUX) wrote:
From: Juergen Gross Sent: Wednesday, April 27, 2022 8:34 AM
Instead of using arch_has_restricted_virtio_memory_access() together
with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
with platform_has() and a new platform feature
Add a simple infrastructure for setting, resetting and querying
platform feature flags.
Flags can be either global or architecture specific.
Signed-off-by: Juergen Gross
---
V2:
- rename set/reset functions to platform_[set|clear]() (Boris Petkov,
Heiko Carstens)
- move function
In another patch series [1] the need has come up to have support for
a generic feature flag infrastructure.
This patch series is introducing that infrastructure and adds the first
use case.
I have decided to use a similar interface as the already known x86
cpu_has() function. As the new
Instead of using arch_has_restricted_virtio_memory_access() together
with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
with platform_has() and a new platform feature
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS.
Signed-off-by: Juergen Gross
---
V2:
- move setting of
On 27.04.22 16:09, Tom Lendacky wrote:
On 4/27/22 07:37, Juergen Gross wrote:
On 27.04.22 14:28, Borislav Petkov wrote:
On Wed, Apr 27, 2022 at 08:37:31AM +0200, Juergen Gross wrote:
On 26.04.22 19:35, Borislav Petkov wrote:
On Tue, Apr 26, 2022 at 03:40:21PM +0200, Juergen Gross wrote:
On 27.04.22 14:26, Borislav Petkov wrote:
On Wed, Apr 27, 2022 at 08:40:08AM +0200, Juergen Gross wrote:
I was planning to look at the x86 cpu features to see whether some of
those might be candidates to be switched to platform features instead.
I'd say "never touch a running system" unless
On 27.04.22 14:28, Borislav Petkov wrote:
On Wed, Apr 27, 2022 at 08:37:31AM +0200, Juergen Gross wrote:
On 26.04.22 19:35, Borislav Petkov wrote:
On Tue, Apr 26, 2022 at 03:40:21PM +0200, Juergen Gross wrote:
/* protected virtualization */
static void pv_init(void)
{
if
On 26.04.22 21:51, Heiko Carstens wrote:
On Tue, Apr 26, 2022 at 07:35:43PM +0200, Borislav Petkov wrote:
On Tue, Apr 26, 2022 at 03:40:21PM +0200, Juergen Gross wrote:
/* protected virtualization */
static void pv_init(void)
{
if (!is_prot_virt_guest())
return;
On 26.04.22 19:35, Borislav Petkov wrote:
On Tue, Apr 26, 2022 at 03:40:21PM +0200, Juergen Gross wrote:
/* protected virtualization */
static void pv_init(void)
{
if (!is_prot_virt_guest())
return;
+ platform_set_feature(PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS);
On 26.04.22 19:31, Borislav Petkov wrote:
On Tue, Apr 26, 2022 at 03:40:20PM +0200, Juergen Gross wrote:
diff --git a/kernel/platform-feature.c b/kernel/platform-feature.c
new file mode 100644
index ..2d52f8442cd5
--- /dev/null
+++ b/kernel/platform-feature.c
@@ -0,0 +1,7 @@
+//
In another patch series [1] the need has come up to have support for
a generic feature flag infrastructure.
This patch series is introducing that infrastructure and adds the first
use case.
I have decided to use a similar interface as the already known x86
cpu_has() function. As the new
Instead of using arch_has_restricted_virtio_memory_access() together
with CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, replace those
with platform_has() and a new platform feature
PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS.
Signed-off-by: Juergen Gross
---
I've only done a compile test on x86 for
Add a simple infrastructure for setting, resetting and querying
platform feature flags.
Flags can be either global or architecture specific.
Signed-off-by: Juergen Gross
---
MAINTAINERS| 8 +++
include/asm-generic/Kbuild | 1 +
On 20.04.22 22:44, Elliot Berman wrote:
From: Prakruthi Deepak Heragu
During hotplug, the stolen time data structure is unmapped and memset.
There is a possibility of the timer IRQ being triggered before memset
and stolen time is getting updated as part of this timer IRQ handler. This
causes
On 07.03.22 11:38, Peter Zijlstra wrote:
On Mon, Mar 07, 2022 at 11:06:46AM +0100, Juergen Gross wrote:
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 4420499f7bb4..a1f179ed39bf 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -145,6
On 07.03.22 10:50, Peter Zijlstra wrote:
On Fri, Mar 04, 2022 at 08:27:45PM +0200, Adrian Hunter wrote:
On 04/03/2022 15:41, Peter Zijlstra wrote:
On Mon, Feb 14, 2022 at 01:09:06PM +0200, Adrian Hunter wrote:
Currently, when Intel PT is used within a VM guest, it is not possible to
make use
On 23.11.21 10:52, Juergen Gross via Virtualization wrote:
On 23.11.21 10:29, Jan Beulich wrote:
On 05.10.2021 09:43, Juergen Gross wrote:
On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
While using a plain (constant) address works, its use needlessly
invokes
a SIB addressing mode
On 23.11.21 10:29, Jan Beulich wrote:
On 05.10.2021 09:43, Juergen Gross wrote:
On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
While using a plain (constant) address works, its use needlessly invokes
a SIB addressing mode, making every call site one byte larger than
necessary.
On 10.11.21 21:09, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware)
VMware mailing lists in the MAINTAINERS file are private lists meant
for VMware-internal review/notification for patches to the respective
subsystems. Anyone can post to these addresses, but there is no public
read
On 08.11.21 21:30, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware)
VMware mailing lists in the MAINTAINERS file are private lists meant
for VMware-internal review/notification for patches to the respective
subsystems. So, in an earlier discussion [1][2], it was recommended to
mark them
On 08.11.21 21:29, Srivatsa S. Bhat wrote:
From: Srivatsa S. Bhat (VMware)
Deep has decided to transfer maintainership of the VMware hypervisor
interface to Srivatsa, and the joint-maintainership of paravirt ops in
the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file
to reflect
A recent patch modifying the core paravirt-ops functionality is
highlighting some missing MAINTAINERS information for PARAVIRT_OPS:
there is no information which tree is to be used for taking those
patches per default. In the past this was mostly handled by the tip
tree, and I think this is fine.
The initial pvops functions handling irq flags will only ever be called
before interrupts are being enabled.
So switch them to be dummy functions:
- xen_save_fl() can always return 0
- xen_irq_disable() is a nop
- xen_irq_enable() can BUG()
Add some generic paravirt functions for that purpose.
The pvops function for Xen PV guests handling the interrupt flag are
much more complex than needed.
With the supported Xen hypervisor versions they can be simplified a
lot, especially by removing the need for disabling preemption.
Juergen Gross (2):
x86/xen: remove xen_have_vcpu_info_placement
On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
While using a plain (constant) address works, its use needlessly invokes
a SIB addressing mode, making every call site one byte larger than
necessary. Instead of using an "i" constraint with address-of operator
and a 'c' operand modifier,
On 22.09.21 23:49, Boris Ostrovsky wrote:
On 9/22/21 6:31 AM, Juergen Gross wrote:
The initial pvops functions handling irq flags will only ever be called
before interrupts are being enabled.
So make the __init and switch them to be dummy functions:
What are you making __init?
Oh, sorry,
The initial pvops functions handling irq flags will only ever be called
before interrupts are being enabled.
So make the __init and switch them to be dummy functions:
- xen_save_fl() can always return 0
- xen_irq_disable() is a nop
- xen_irq_enable() can BUG()
Add some generic paravirt functions
1 - 100 of 178 matches
Mail list logo
