2025-05-23T11:02:11-07:00, Atish Patra :
> On 5/23/25 9:27 AM, Radim KrÄmáŠwrote:
>> 2025-05-23T17:29:49+02:00, Clément Léger :
>>> Is this something blocking though ? We'd like to merge FWFT once SBI 3.0
>>> is ratified so that would be nice not delaying it too much. I'll take a
>>> look at it t
2025-05-23T17:29:49+02:00, Clément Léger :
> On 23/05/2025 15:05, Radim Krčmář wrote:
>> 2025-05-23T12:19:30+02:00, Clément Léger :
>>> +++ b/arch/riscv/kvm/vcpu_sbi_fwft.c
>>> +static const enum sbi_fwft_feature_t kvm_fwft_defined_features[] = {
>>&g
2025-05-23T12:19:31+02:00, Clément Léger :
> SBI_FWFT_MISALIGNED_DELEG needs hedeleg to be modified to delegate
> misaligned load/store exceptions. Save and restore it during CPU
> load/put.
How do you plan to access the value of hedeleg & MIS_DELEG from
userspace?
(I think that modeling medeleg
2025-05-23T12:19:30+02:00, Clément Léger :
> +++ b/arch/riscv/kvm/vcpu_sbi_fwft.c
> +static const enum sbi_fwft_feature_t kvm_fwft_defined_features[] = {
> + SBI_FWFT_MISALIGNED_EXC_DELEG,
> + SBI_FWFT_LANDING_PAD,
> + SBI_FWFT_SHADOW_STACK,
> + SBI_FWFT_DOUBLE_TRAP,
> + SBI_FWF
2025-05-16T08:34:25-07:00, Deepak Gupta :
> On Thu, May 15, 2025 at 10:48:35AM +0200, Radim Krčmář wrote:
>>2025-05-15T09:28:25+02:00, Alexandre Ghiti :
>>> On 06/05/2025 12:10, Radim Krčmář wrote:
>>>> 2025-05-02T16:30:36-07:00, Deepak Gupta :
>>>>>
2025-05-15T09:28:25+02:00, Alexandre Ghiti :
> On 06/05/2025 12:10, Radim Krčmář wrote:
>> 2025-05-02T16:30:36-07:00, Deepak Gupta :
>>> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
>>> @@ -91,6 +91,32 @@
>>> +.macro restore_use
[Ah, I missed v13 and v14, feel free to Cc me on next versions.]
2025-05-02T16:30:36-07:00, Deepak Gupta :
> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> @@ -91,6 +91,32 @@
> +.macro save_userssp tmp, status
> + ALTERNATIVE("nops(4)",
> + __stringify(
2025-04-24T11:16:19-07:00, Deepak Gupta :
> On Thu, Apr 24, 2025 at 03:36:54PM +0200, Radim Krčmář wrote:
>>2025-04-23T21:44:09-07:00, Deepak Gupta :
>>> On Thu, Apr 10, 2025 at 11:45:58AM +0200, Radim Krčmář wrote:
>>>>2025-03-14T14:39:31-07:00, Deepak Gupta :
2025-04-24T11:03:59-07:00, Deepak Gupta :
> On Thu, Apr 24, 2025 at 02:16:32PM +0200, Radim Krčmář wrote:
>>2025-04-23T17:23:56-07:00, Deepak Gupta :
>>> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote:
>>>>2025-03-14T14:39:24-07:00, Deepak Gupta :
>&g
2025-04-24T10:56:34-07:00, Deepak Gupta :
> On Thu, Apr 24, 2025 at 01:52:43PM +0200, Radim Krčmář wrote:
>>2025-04-23T17:00:29-07:00, Deepak Gupta :
>>> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote:
>>>>2025-03-14T14:39:24-07:00, Deepak Gupta :
2025-04-23T17:00:29-07:00, Deepak Gupta :
> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote:
>>2025-03-14T14:39:24-07:00, Deepak Gupta :
>>> diff --git a/arch/riscv/include/asm/thread_info.h
>>> b/arch/riscv/include/asm/thread_info.h
>>>
2025-04-23T21:44:09-07:00, Deepak Gupta :
> On Thu, Apr 10, 2025 at 11:45:58AM +0200, Radim Krčmář wrote:
>>2025-03-14T14:39:31-07:00, Deepak Gupta :
>>> diff --git a/arch/riscv/include/asm/usercfi.h
>>> b/arch/riscv/include/asm/usercfi.h
>>> @@ -14
2025-04-23T20:16:58-07:00, Deepak Gupta :
> On Thu, Apr 10, 2025 at 11:56:44AM +0200, Radim Krčmář wrote:
>>2025-03-14T14:39:29-07:00, Deepak Gupta :
>>> As discussed extensively in the changelog for the addition of this
>>> syscall on x86 ("x86/shstk: Introduc
2025-04-23T17:45:53-07:00, Deepak Gupta :
> On Thu, Apr 10, 2025 at 12:03:44PM +0200, Radim Krčmář wrote:
>>2025-03-14T14:39:25-07:00, Deepak Gupta :
>>> diff --git a/arch/riscv/kernel/sys_riscv.c b/arch/riscv/kernel/sys_riscv.c
>>> @@ -16,6 +17,15 @@ static long riscv_
2025-04-23T17:23:56-07:00, Deepak Gupta :
> On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Krčmář wrote:
>>2025-03-14T14:39:24-07:00, Deepak Gupta :
>>> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
>>> @@ -147,6 +147,20 @@ SYM_CODE_START(handle_e
2025-03-14T14:39:24-07:00, Deepak Gupta :
> diff --git a/arch/riscv/include/asm/thread_info.h
> b/arch/riscv/include/asm/thread_info.h
> @@ -62,6 +62,9 @@ struct thread_info {
> longuser_sp;/* User stack pointer */
> int cpu;
> unsi
2025-03-14T14:39:25-07:00, Deepak Gupta :
> diff --git a/arch/riscv/include/asm/mman.h b/arch/riscv/include/asm/mman.h
> +static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
> +unsigned long pkey
> __always_unused)
> +{
> + uns
2025-03-14T14:39:29-07:00, Deepak Gupta :
> As discussed extensively in the changelog for the addition of this
> syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
> existing mmap() and madvise() syscalls do not map entirely well onto the
> security requirements for shadow stack m
2025-03-14T14:39:31-07:00, Deepak Gupta :
> diff --git a/arch/riscv/include/asm/usercfi.h
> b/arch/riscv/include/asm/usercfi.h
> @@ -14,7 +15,8 @@ struct kernel_clone_args;
> struct cfi_status {
> unsigned long ubcfi_en : 1; /* Enable for backward cfi. */
> - unsigned long rsvd : ((size
2025-03-14T14:39:36-07:00, Deepak Gupta :
> diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
> @@ -140,6 +142,62 @@ static long __restore_v_state(struct pt_regs *regs, void
> __user *sc_vec)
> return copy_from_user(current->thread.vstate.datap, datap,
> riscv_v_vsize);
>
2025-03-14T14:39:42-07:00, Deepak Gupta :
> This commit adds a kernel command line option using which user cfi can be
> disabled.
>
> Signed-off-by: Deepak Gupta
> ---
> arch/riscv/kernel/usercfi.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/riscv/kernel/u
2025-03-14T14:39:44-07:00, Deepak Gupta :
> This patch creates a config for shadow stack support and landing pad instr
> support. Shadow stack support and landing instr support can be enabled by
> selecting `CONFIG_RISCV_USER_CFI`. Selecting `CONFIG_RISCV_USER_CFI` wires
> up path to enumerate CPU
2025-03-20T15:42:44-07:00, Deepak Gupta :
> On Thu, Mar 20, 2025 at 3:10 PM Radim Krčmář wrote:
>>
>> 2025-03-14T14:39:41-07:00, Deepak Gupta :
>> > Kernel will have to perform shadow stack operations on user shadow stack.
>> > Like during signal delivery and sigr
2025-03-20T15:29:55-07:00, Deepak Gupta :
> On Thu, Mar 20, 2025 at 2:25 PM Radim Krčmář wrote:
>>
>> 2025-03-14T14:39:44-07:00, Deepak Gupta :
>> > This patch creates a config for shadow stack support and landing pad instr
>> > support. Shadow stack support
2025-03-20T15:31:09-07:00, Deepak Gupta :
> On Thu, Mar 20, 2025 at 2:35 PM Radim Krčmář wrote:
>> 2025-03-14T14:39:42-07:00, Deepak Gupta :
>> > +__setup("disable_riscv_usercfi=", setup_global_riscv_enable);
>>
>> I'd prefer two command line opt
2025-03-20T16:09:12-07:00, Deepak Gupta :
> On Thu, Mar 20, 2025 at 3:24 PM Radim Krčmář wrote:
>> 2025-03-14T14:39:38-07:00, Deepak Gupta :
>> > Expose a new register type NT_RISCV_USER_CFI for risc-v cfi status and
>> > state. Intentionally both landing pad and sh
2025-03-14T14:39:41-07:00, Deepak Gupta :
> Kernel will have to perform shadow stack operations on user shadow stack.
> Like during signal delivery and sigreturn, shadow stack token must be
> created and validated respectively. Thus shadow stack access for kernel
> must be enabled.
Why can't kerne
2019-01-07 18:52+0100, Christophe de Dinechin:
> The URL of [api-spec] in Documentation/virtual/kvm/amd-memory-encryption.rst
> is no longer valid, replaced space with underscore.
>
> Signed-off-by: Christophe de Dinechin
> ---
Applied, thanks.
2017-11-09 00:55-0800, Eduardo Valentin:
> Hello,
>
> On Wed, Nov 08, 2017 at 06:36:52PM +0100, Radim Krčmář wrote:
> > 2017-11-06 12:26-0800, Eduardo Valentin:
> > > Currently, the existing qspinlock implementation will fallback to
> > > test-and-set if the hyp
2017-10-31 10:02-0700, Eduardo Valentin:
> Hello Radim,
>
> On Tue, Oct 24, 2017 at 01:18:59PM +0200, Radim Krčmář wrote:
> > 2017-10-23 17:44-0700, Eduardo Valentin:
> > > Currently, the existing qspinlock implementation will fallback to
> > > test-and-set
LT = 0: default is tas
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Jonathan Corbet
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Peter Zijlstra
> Cc: Waiman Long
> Cc: k...@vger.kernel.org
&
2017-10-23 17:44-0700, Eduardo Valentin:
> Currently, the existing qspinlock implementation will fallback to
> test-and-set if the hypervisor has not set the PV_UNHALT flag.
Where have you detected the main source of overhead with pinned VCPUs?
Makes me wonder if we couldn't improve general PV_UNH
2017-07-03 17:28+0800, Yang Zhang:
> The background is that we(Alibaba Cloud) do get more and more complaints
> from our customers in both KVM and Xen compare to bare-mental.After
> investigations, the root cause is known to us: big cost in message passing
> workload(David show it in KVM forum 2015
2017-06-27 15:56+0200, Paolo Bonzini:
> On 27/06/2017 15:40, Radim Krčmář wrote:
>>> ... which is not necessarily _wrong_. It's just a different heuristic.
>> Right, it's just harder to use than host's single_task_running() -- the
>> VCPU calling vcpu_is_pre
2017-06-23 14:49+0800, Yang Zhang:
> On 2017/6/23 12:35, Wanpeng Li wrote:
> > 2017-06-23 12:08 GMT+08:00 Yang Zhang :
> > > On 2017/6/22 19:50, Wanpeng Li wrote:
> > > >
> > > > 2017-06-22 19:22 GMT+08:00 root :
> > > > >
> > > > > From: Yang Zhang
> > > > >
> > > > > Some latency-intensive wo
2017-06-27 14:28+0200, Paolo Bonzini:
> On 27/06/2017 14:23, Wanpeng Li wrote:
> I have considered single_task_running() before. But since there is no
> such paravirtual interface currently and i am not sure whether it is a
> information leak from host if introducing such interface, so
[Cc qemu-devel as we've gone off-topic]
2017-04-04 15:15+0200, Alexander Graf:
> On 04/04/2017 03:13 PM, Radim Krčmář wrote:
>> 2017-04-04 14:51+0200, Alexander Graf:
>> > Please see my patch to force enable CPUID bits ;).
>> Nice. MWAIT could also use setting of
2017-04-04 14:51+0200, Alexander Graf:
> On 04/04/2017 02:39 PM, Radim Krčmář wrote:
>> 2017-04-03 12:04+0200, Alexander Graf:
>> > So coming back to the original patch, is there anything that should keep us
>> > from exposing MWAIT straight into the guest at all
2017-04-03 12:04+0200, Alexander Graf:
> On 03/29/2017 02:11 PM, Radim Krčmář wrote:
>> 2017-03-28 13:35-0700, Jim Mattson:
>> > On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář wrote:
>> > > 2017-03-27 15:34+0200, Alexander Graf:
>> > > >
2017-03-28 13:35-0700, Jim Mattson:
> On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář wrote:
>> 2017-03-27 15:34+0200, Alexander Graf:
>>> On 15/03/2017 22:22, Michael S. Tsirkin wrote:
>>>> Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
&
2017-03-27 15:34+0200, Alexander Graf:
> On 15/03/2017 22:22, Michael S. Tsirkin wrote:
>> Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
>> unless explicitly provided with kernel command line argument
>> "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability
2017-03-21 10:29-0700, Nadav Amit:
>
> > On Mar 21, 2017, at 9:58 AM, Radim Krčmář wrote:
>
> > In '-smp 2', the writing VCPU always does 1 wakeups by writing into
> > monitored memory, but the mwaiting VCPU can be also woken up by host
> > interrupt
2017-03-21 05:22+0200, Michael S. Tsirkin:
> On Fri, Mar 17, 2017 at 09:23:56AM -0400, Gabriel L. Somlo wrote:
>> OK, now on to Radim's test, on the MacPro1,1:
>>
>> [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 1'
>> timeout -k 1s --foreground 20 qemu-kvm -nodefaults -
hu, Mar 16, 2017 at 12:16:13PM -0400, Gabriel L. Somlo wrote:
> > > > > On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote:
> > > > > > 2017-03-16 10:58-0400, Gabriel L. Somlo:
> > > > > > > On Thu, Mar 16, 2017 at 04:04:12PM +0200, Mi
2017-03-16 12:47-0400, Gabriel L. Somlo:
> On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote:
> > 2017-03-16 16:35+0100, Radim Krčmář:
> > > 2017-03-16 10:58-0400, Gabriel L. Somlo:
> > >> The intel manual said the same thing back in 2010 as well. However
2017-03-16 16:35+0100, Radim Krčmář:
> 2017-03-16 10:58-0400, Gabriel L. Somlo:
>> The intel manual said the same thing back in 2010 as well. However,
>> regardless of how any flags were set, interrupt-window exiting or not,
>> "normal" L1 MWAIT behavior was that it
2017-03-16 11:44-0400, Gabriel L. Somlo:
> On Thu, Mar 16, 2017 at 03:08:07PM +0100, Radim Krčmář wrote:
>> 2017-03-16 09:24-0400, Gabriel L. Somlo:
>> > On Thu, Mar 16, 2017 at 01:41:28AM +0200, Michael S. Tsirkin wrote:
>> > > On Wed, Mar 15, 2017 at 07:35:34PM
2017-03-16 10:58-0400, Gabriel L. Somlo:
> On Thu, Mar 16, 2017 at 04:04:12PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 16, 2017 at 09:24:27AM -0400, Gabriel L. Somlo wrote:
> > > After studying your patch a bit more carefully (sorry, it's crazy
> > > around here right now :) ) I realized yo
2017-03-16 09:24-0400, Gabriel L. Somlo:
> On Thu, Mar 16, 2017 at 01:41:28AM +0200, Michael S. Tsirkin wrote:
> > On Wed, Mar 15, 2017 at 07:35:34PM -0400, Gabriel L. Somlo wrote:
> > > On Wed, Mar 15, 2017 at 11:22:18PM +0200, Michael S. Tsirkin wrote:
> > > > Guests running Mac OS 5, 6, and 7 (L
2017-03-15 16:21-0400, Gabriel L. Somlo:
> On Wed, Mar 15, 2017 at 09:13:49PM +0100, Radim Krčmář wrote:
>> 2017-03-15 21:28+0200, Michael S. Tsirkin:
>> > Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
>> > unless explicitly provided with k
2017-03-15 21:28+0200, Michael S. Tsirkin:
> Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
> unless explicitly provided with kernel command line argument
> "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability,
> without checking CPUID.
>
> We currently em
2017-03-14 01:44+0200, Michael S. Tsirkin:
> Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
> unless explicitly provided with kernel command line argument
> "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability,
> without checking CPUID.
>
> We currently em
2017-03-13 22:03+0200, Michael S. Tsirkin:
> On Mon, Mar 13, 2017 at 08:39:11PM +0100, Radim Krčmář wrote:
> > 2017-03-13 18:08+0200, Michael S. Tsirkin:
> > > On Mon, Mar 13, 2017 at 04:46:20PM +0100, Radim Krčmář wrote:
>> >> What about keeping just the last
2017-03-13 18:08+0200, Michael S. Tsirkin:
> On Mon, Mar 13, 2017 at 04:46:20PM +0100, Radim Krčmář wrote:
>> 2017-03-10 00:29+0200, Michael S. Tsirkin:
>> > Some guests call mwait without checking the cpu flags. We currently
>> > emulate that as a NOP but on VMX we ca
2017-03-10 00:29+0200, Michael S. Tsirkin:
> Some guests call mwait without checking the cpu flags. We currently
> emulate that as a NOP but on VMX we can do better: let guest stop the
> CPU until timer or IPI. CPU will be busy but that isn't any worse than
> a NOP emulation.
>
> Note that mwait
2016-11-15 11:02-0600, Tom Lendacky:
> On 11/15/2016 8:39 AM, Radim Krčmář wrote:
>> 2016-11-09 18:37-0600, Tom Lendacky:
>>> Since DMA addresses will effectively look like 48-bit addresses when the
>>> memory encryption mask is set, SWIOTLB is needed if the DMA mask o
2016-11-09 18:37-0600, Tom Lendacky:
> Since DMA addresses will effectively look like 48-bit addresses when the
> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
> device performing the DMA does not support 48-bits. SWIOTLB will be
> initialized to create un-encrypted bounce
2016-04-25 14:00+0200, Cornelia Huck:
> On Mon, 25 Apr 2016 07:37:04 +0100
> Eric Engestrom wrote:
>> Signed-off-by: Eric Engestrom
>> ---
>> Documentation/virtual/kvm/devices/s390_flic.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/virtual/kvm/dev
58 matches
Mail list logo
