similar to: [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 =

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

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

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

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:

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:

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) > +

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

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..

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

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

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> ---

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> ---

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

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

Hi Ankur, Why do you need archive in this case? The other way of doing this is to merge all bitcode files into single file: $ clang -c -emit-llvm abc.c -o abc.bc $ clang -c -emit-llvm bcd.c -o bcd.bc llvm-link bcd.bc abc.bc -o merged.bc Cheers, Ahmad From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ankur deshwal Sent: 21 February 2013 17:54 To:

Hi Ankur, For a MachineBasicBlock you can call getBasicBlock() to find the IR level BasicBlock from which it was generated (if there isn't a one, it will return NULL). I don't know of a way to get a finer granularity than that, though. -Jim On Jul 1, 2011, at 1:06 AM, ankur deshwal wrote: > Hi, > > Is there any way to get a pointer to the LLVM Instr from which a >

From: Andrey Smetanin <asmetanin at virtuozzo.com> Hypervisor Top Level Functional Specification v3.1/4.0 notes that cpuid (0x40000003) EDX's 10th bit should be used to check that Hyper-V guest crash MSR's functionality available. This patch should fix this recognition. Currently the code checks EAX register instead of EDX. Signed-off-by: Andrey Smetanin <asmetanin at

From: Andrey Smetanin <asmetanin at virtuozzo.com> Hypervisor Top Level Functional Specification v3.1/4.0 notes that cpuid (0x40000003) EDX's 10th bit should be used to check that Hyper-V guest crash MSR's functionality available. This patch should fix this recognition. Currently the code checks EAX register instead of EDX. Signed-off-by: Andrey Smetanin <asmetanin at

I guess I miss-interpreted the text in [2]. It talks about the optimizations are hindered if the compiler driver invokes link time optimizer "separately". I found that all files compiled are in bc format. Also in library archives, the embedded files were in bitcode format. So the gold linker and LLVMgold plugin are indeed working fine. However, there is still question over only 6% gain