Displaying 20 results from an estimated 1000 matches similar to: "[RFC PATCH 15/26] x86/alternatives: Non-emulated text poking"
2020 Apr 08
2
[RFC PATCH 00/26] Runtime paravirt patching
On Tue, Apr 07, 2020 at 10:02:57PM -0700, 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
> host might go from being undersubscribed to being oversubscribed
> (or the other way round) and it would make sense
2020 Apr 08
2
[RFC PATCH 00/26] Runtime paravirt patching
On Tue, Apr 07, 2020 at 10:02:57PM -0700, 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
> host might go from being undersubscribed to being oversubscribed
> (or the other way round) and it would make sense
2020 Apr 08
0
[RFC PATCH 15/26] x86/alternatives: Non-emulated text poking
On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote:
> +static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
> +{
> + int ret;
> +
> + lockdep_assert_held(&text_mutex);
> +
> + if (system_state != SYSTEM_RUNNING)
> + return -EINVAL;
> +
> + text_poke_state.stage = stage;
> + text_poke_state.num_acks =
2020 Apr 08
0
[RFC PATCH 00/26] Runtime paravirt patching
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 issues:
>> 1) emulation in text_poke() can only easily
2007 Apr 18
1
[RFC, PATCH 12/24] i386 Vmi processor header
Fairly straight code motion. Split non-virtualizable pieces of
processor.h into default and VMI subarches. CPUID is
non-virtualizable, since it doesn't trap, and very often the
hypervisor will want to hide specific feature bits from the
kernel. To provide a replacement for call sites that use
CPUID as a serializing instruction, the sync_core() macro is
still available.
Signed-off-by:
2007 Apr 18
1
[RFC, PATCH 12/24] i386 Vmi processor header
Fairly straight code motion. Split non-virtualizable pieces of
processor.h into default and VMI subarches. CPUID is
non-virtualizable, since it doesn't trap, and very often the
hypervisor will want to hide specific feature bits from the
kernel. To provide a replacement for call sites that use
CPUID as a serializing instruction, the sync_core() macro is
still available.
Signed-off-by:
2020 Apr 08
0
[RFC PATCH 14/26] x86/alternatives: Handle native insns in text_poke_loc*()
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> struct text_poke_loc {
> s32 rel_addr; /* addr := _stext + rel_addr */
> - s32 rel32;
> - u8 opcode;
> + union {
> + struct {
> + s32 rel32;
> + u8 opcode;
> + } emulated;
> + struct {
> + u8 len;
> + } native;
> + };
> const u8 text[POKE_MAX_OPCODE_SIZE];
> };
NAK, this
2020 Apr 08
0
[RFC PATCH 14/26] x86/alternatives: Handle native insns in text_poke_loc*()
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> @@ -1071,10 +1079,13 @@ int notrace poke_int3_handler(struct pt_regs *regs)
> goto out_put;
> }
>
> - len = text_opcode_size(tp->opcode);
> + if (desc->native)
> + BUG();
> +
Subject: x86/alternatives: Handle native insns in text_poke_loc*()
That's not really handling, is it..
2020 Apr 08
0
[RFC PATCH 19/26] x86/alternatives: NMI safe runtime patching
On Tue, Apr 07, 2020 at 10:03:16PM -0700, Ankur Arora wrote:
> @@ -1807,12 +1911,20 @@ static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
> text_poke_state.state = PATCH_SYNC_DONE; /* Start state */
> text_poke_state.primary_cpu = smp_processor_id();
>
> + text_poke_state.nmi_context = nmi;
> +
> + if (nmi)
> +
2020 Apr 08
0
[RFC PATCH 00/26] Runtime paravirt patching
Ankur Arora <ankur.a.arora at oracle.com> writes:
> 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
> host might go from being undersubscribed to being oversubscribed
> (or the other way round) and it would make sense for the
2004 Nov 19
1
com32: custom int3 handler
I am having problems installing a custom int3 handler
from a com32 app. Here is what I have tried:
void int3_handler()
{
put_str("int3!!!");
__asm__("iret");
}
void init_handlers()
{
struct {
unsigned long limit : 16;
unsigned long base : 32;
} __attribute__((packed)) idtr;
__asm__("sidt
2020 Apr 08
0
[RFC PATCH 00/26] Runtime paravirt patching
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 might go from being undersubscribed to being oversubscribed
> (or the other way
2020 Feb 11
0
[PATCH 03/62] x86/cpufeatures: Add SEV-ES CPU feature
From: Tom Lendacky <thomas.lendacky at amd.com>
Add CPU feature detection for Secure Encrypted Virtualization with
Encrypted State. This feature enhances SEV by also encrypting the
guest register state, making it in-accessible to the hypervisor.
Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Joerg Roedel <jroedel at suse.de>
---
2020 Apr 28
0
[PATCH v3 04/75] x86/cpufeatures: Add SEV-ES CPU feature
From: Tom Lendacky <thomas.lendacky at amd.com>
Add CPU feature detection for Secure Encrypted Virtualization with
Encrypted State. This feature enhances SEV by also encrypting the
guest register state, making it in-accessible to the hypervisor.
Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Joerg Roedel <jroedel at suse.de>
---
2007 Apr 18
0
[PATCH] paravirt_ops x86_64 , take 2
Hello all,
Here's a new version of the paravirt_ops x86_64 patch. With this
message, I'm sending an incremental patch. The complete patches can be
found , from now on, at http://et.redhat.com/~gcosta/paravirt_ops/
The main aim of this new update, is to fix a critical bug, namely,
Rusty's name. However, I took the opportunity to write some new less
important pieces of code,
2007 Apr 18
0
[PATCH] paravirt_ops x86_64 , take 2
Hello all,
Here's a new version of the paravirt_ops x86_64 patch. With this
message, I'm sending an incremental patch. The complete patches can be
found , from now on, at http://et.redhat.com/~gcosta/paravirt_ops/
The main aim of this new update, is to fix a critical bug, namely,
Rusty's name. However, I took the opportunity to write some new less
important pieces of code,
2013 Feb 22
1
[LLVMdev] llvm-ar llvm-link
Hi Ahmad,
Yes, merging works good.
However, my problem is like this - I have a C library which consists of
1000's of functions spread through various files. The functions do not have
dependency amoung each other. I want to link only relavant files( files
which have functions called from my application). Since ar has a global
symbol table, I believe it should be faster to look for a symol in
2007 Apr 18
2
[PATCH] x86_64 paravirt_ops port
Hi all,
I've been working on a port of paravirt_ops for the x86_64 architectures
for a couple of days. Here's the result so far. I'm posting it soon for
early cooments. The more, the better.
It's obviously based on the previous work for i386, with the needed
modifications. By now, I'm able to boot a bare metal kernel, but there
are still some known issues, that are in my TODO
2007 Apr 18
2
[PATCH] x86_64 paravirt_ops port
Hi all,
I've been working on a port of paravirt_ops for the x86_64 architectures
for a couple of days. Here's the result so far. I'm posting it soon for
early cooments. The more, the better.
It's obviously based on the previous work for i386, with the needed
modifications. By now, I'm able to boot a bare metal kernel, but there
are still some known issues, that are in my TODO
2013 Jan 23
0
[LLVMdev] OpenCL SPIR/NVPTX code generation
Hi Ankur,
Since you use -Xclang, the clang executable passes multiple triples to "clang -cc1". You can see that if you add the -v option. I'm sure there is someone here who can explain it better than I...
Anyhow, I think you better use clang -cc1. Make sure -cc1 is the first command line option you use.
$ clang -cc1 -fno-builtin -emit-llvm-bc -triple spir-unknown-unknown