On Wed, Nov 08, 2023 at 10:29:52AM -0800, Xin Li wrote:
>Set injected-event data when injecting a #PF, #DB, or #NM caused
>by extended feature disable using FRED event delivery, and save
>original-event data for being used as injected-event data.
>
>Unlike IDT using some extra CPU register as part
When we dynamically generate a name for a configuration in get-reg-list
we use strcat() to append to a buffer allocated using malloc() but we
never initialise that buffer. Since malloc() offers no guarantees
regarding the contents of the memory it returns this can lead to us
corrupting, and likely
On 8.11.23 г. 20:29 ч., Xin Li wrote:
Setup the global vmcs_config for FRED:
1) Add VM_ENTRY_LOAD_IA32_FRED to KVM_OPTIONAL_VMX_VM_ENTRY_CONTROLS to
have a FRED CPU load guest FRED MSRs from VMCS upon VM entry.
2) Add SECONDARY_VM_EXIT_SAVE_IA32_FRED to
KVM_OPTIONAL_VMX_SECONDARY_VM_EX
On Sun, 12 Nov 2023 19:28:52 -0800 Mina Almasry wrote:
> My issue with this is that if the driver doesn't support dmabuf then
> the driver will accidentally use the pp backed by the dmabuf, allocate
> a page from it, then call page_address() on it or something, and
> crash.
>
> Currently I avoid t
On Sun, 12 Nov 2023 22:05:30 -0800 Mina Almasry wrote:
> My issue here is that all these skb helpers call each other so I end
> up having to move a lot of the unrelated skb helpers to this new
> header (maybe that is acceptable but it feels weird).
Splitting pp headers again is not an option, we a
On Sun, 12 Nov 2023 20:08:10 -0800 Mina Almasry wrote:
> 1. For (b), would it be OK to implement a very minimal version of
> queue_[stop|start]/queue_mem_[alloc|free], which I use for the sole
> purpose of reposting buffers to an individual queue, and then later
> whoever picks up your queue API ef
ls/testing/selftests/net/mptcp/mptcp_join.sh | 2 +-
4 files changed, 15 insertions(+), 6 deletions(-)
---
base-commit: 2bd5b559a1f391f05927bbb0b31381fa71c61e26
change-id: 20231113-upstream-net-20231113-mptcp-misc-fixes-6-7-rc2-d15df60b0a3f
Best regards,
--
Matthieu Baerts
From: Paolo Abeni
After the blamed commit below, the TCP sockets (and the MPTCP subflows)
can build egress packets larger than 64K. That exceeds the maximum DSS
data size, the length being misrepresent on the wire and the stream being
corrupted, as later observed on the receiver:
WARNING: CPU:
From: Paolo Abeni
After the blamed commit below, the MPTCP release callback can
dereference the first subflow pointer via __mptcp_set_connected()
and send buffer auto-tuning. Such pointer is always expected to be
valid, except at socket destruction time, when the first subflow is
deleted and the
From: Geliang Tang
This patch adds the validity check for sending RM_ADDRs for userspace PM
in mptcp_pm_remove_addrs(), only send a RM_ADDR when the address is in the
anno_list or conn_list.
Fixes: 8b1c94da1e48 ("mptcp: only send RM_ADDR in nl_cmd_remove")
Cc: sta...@vger.kernel.org
Signed-off-b
From: Paolo Abeni
The MPTCP implementation of the IP_TOS socket option uses the lockless
variant of the TOS manipulation helper and does not hold such lock at
the helper invocation time.
Add the required locking.
Fixes: ffcacff87cd6 ("mptcp: Support for IP_TOS for MPTCP setsockopt()")
Cc: sta..
From: Paolo Abeni
Running the mp_join selftest manually with the following command line:
./mptcp_join.sh -z -C
leads to some failures:
002 fastclose server test
# ...
rtx [fail] got 1 MP_RST[s] TX expected 0
# ...
rstrx
[AMD Official Use Only - General]
Hi all:
Do you have any other review comments?
Hi Rafael：
If there are no other issues, can you merge it to linux-next?
> -Original Message-
> From: Meng, Li (Jassmine)
> Sent: Monday, October 30, 2023 2:34 PM
> To: Rafael J . Wysocki ; Huang, Ray
>
>
kselftest/fixes build: 6 builds: 2 failed, 4 passed, 1 warning (v6.7-rc1)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/fixes/kernel/v6.7-rc1/
Tree: kselftest
Branch: fixes
Git Describe: v6.7-rc1
Git Commit: b85ea95d086471afb4ad062012a4d73cd328fa86
Git URL:
https://git.kernel.
kselftest/next build: 6 builds: 2 failed, 4 passed, 1 warning (v6.7-rc1)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/next/kernel/v6.7-rc1/
Tree: kselftest
Branch: next
Git Describe: v6.7-rc1
Git Commit: b85ea95d086471afb4ad062012a4d73cd328fa86
Git URL:
https://git.kernel.org
kselftest/fixes kselftest-lkdtm: 1 runs, 1 regressions (v6.7-rc1)
Regressions Summary
---
platform| arch | lab | compiler | defconfig
| regressions
+--+---+--+--+
kselftest/next kselftest-lkdtm: 1 runs, 1 regressions (v6.7-rc1)
Regressions Summary
---
platform| arch | lab | compiler | defconfig
| regressions
+--+---+--+--+
i
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko :
On Sat, 11 Nov 2023 18:30:10 -0800 you wrote:
> This is a follow up to:
> commit b8e3a87a627b ("bpf: Add crosstask check to __bpf_get_stack").
>
> This test ensures that the task iterator only gets a single
> user st
> > > Clearing VM_EXIT_ACTIVATE_SECONDARY_CONTROLS may be problematic when
> > > new bits are added to secondary vmcs controls. Why not keep
> > > VM_EXIT_ACTIVATE_SECONDARY_CONTROLS always on if it is supported? or
> > > you see any perf impact?
> >
> > I think it from the other way, why keeps hw
> > > > Can we just hide FRED from guests like what KVM does for other
> > > > features which have similar dependencies? see vmx_set_cpu_caps().
> > >
> > > Both of these warnings should simply be dropped. The
> > > error_on_inconsistent_vmcs_config stuff is for inconsistencies within the
> allowe
> >+else if (is_nm_fault(intr_info) &&
> >+ vcpu->arch.guest_fpu.fpstate->xfd)
>
> does this necessarily mean the #NM is caused by XFD?
Then the event data should be 0. Or I missed something obvious? I.e.,
it can be easily differentiated and we sho
> >+return cpu_feature_enabled(X86_FEATURE_FRED) &&
> >+ kvm_is_cr4_bit_set(vcpu, X86_CR4_FRED);
>
> FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to omit the
> check about long mode?
It won' t allow CR4.FRED to be set if not in long mode, I don't expect it
at runtim
> > #ifdef CONFIG_X86_64
> > MSR_CSTAR, MSR_KERNEL_GS_BASE, MSR_SYSCALL_MASK, MSR_LSTAR,
> >+MSR_IA32_FRED_RSP0, MSR_IA32_FRED_RSP1, MSR_IA32_FRED_RSP2,
> >+MSR_IA32_FRED_RSP3, MSR_IA32_FRED_STKLVLS, MSR_IA32_FRED_SSP1,
> >+MSR_IA32_FRED_SSP2, MSR_IA32_FRED_SSP3, MSR_IA32_FRED_CONFI
> >+if (cpu_feature_enabled(X86_FEATURE_FRED) &&
> >+guest_cpuid_has(&vmx->vcpu, X86_FEATURE_FRED)) {
>
> IIUC, vmx_prepare_switch_to_host() is called from IRQ-disabled context. using
> guest_cpuid_has() in this context is not desired, see
> lockdep_assert_irqs_enabled() in cpuid_entry
> >@@ -1477,6 +1477,18 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int
> cpu,
> > (unsigned long)(cpu_entry_stack(cpu) + 1));
> > }
> >
> >+#ifdef CONFIG_X86_64
> >+/* Per-CPU FRED MSRs */
> >+if (cpu_feature_enabled(X86_FEAT
>
> > >+ vmcs_write64(HOST_IA32_FRED_RSP1,
> > read_msr(MSR_IA32_FRED_RSP1));
> > >+ vmcs_write64(HOST_IA32_FRED_RSP2,
> > read_msr(MSR_IA32_FRED_RSP2));
> > >+ vmcs_write64(HOST_IA32_FRED_RSP3,
> > read_msr(MSR_IA32_FRED_RSP3));
> > >+
> /* Require Write-Back (WB) memory type for VMCS accesses. */
>@@ -7313,11 +7328,12 @@ static void __vmx_complete_interrupts(struct kvm_vcpu
>*vcpu,
> }
> }
>
>- if (idt_vectoring_info & VECTORING_INFO_DELIVER_CODE_MASK) {
>-
>> >diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h index
>> >f8c02bd37069..328a3447f064 100644
>> >--- a/arch/x86/kvm/vmx/vmx.h
>> >+++ b/arch/x86/kvm/vmx/vmx.h
>> >@@ -276,6 +276,8 @@ struct vcpu_vmx {
>> > #ifdef CONFIG_X86_64
>> >u64 msr_host_kernel_gs_base;
>
28 matches
Mail list logo
