From: Nikunj A Dadhania
Add a test case to verify the Bus Lock exit feature
The main thing that the selftest verifies is that when a Buslock is
generated in the guest context, the KVM_EXIT_X86_BUS_LOCK is triggered
for SVM or VMX when the KVM capability KVM_CAP_X86_BUS_LOCK_EXIT is
enabled.
Thi
Add a note about behavioral difference for KVM_EXIT_X86_BUS_LOCK
between AMD CPUs and Intel CPUs in KVM_CAP_X86_BUS_LOCK_EXIT
capability documentation.
Signed-off-by: Manali Shukla
---
Documentation/virt/kvm/api.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/virt/kvm/
Misbehaving guests can cause bus locks to degrade the performance of
a system. Non-WB (write-back) and misaligned locked RMW
(read-modify-write) instructions are referred to as "bus locks" and
require system wide synchronization among all processors to guarantee
the atomicity. The bus locks can imp
From: Nikunj A Dadhania
Virtual machines can exploit bus locks to degrade the performance of
the system. Bus locks can be caused by Non-WB(Write back) and
misaligned locked RMW (Read-modify-Write) instructions and require
systemwide synchronization among all processors which can result into
signi
Misbehaving guests can cause bus locks to degrade the performance of
the system. The Bus Lock Threshold feature can be used to address this
issue by providing capability to the hypervisor to limit guest's
ability to generate bus lock, thereby preventing system slowdown due
to performance penalities
Add support for generating Virtualization feature names in capflags.c
and use the resulting x86_virt_flags to print the virt flags in
/proc/cpuinfo.
Currently, it is difficult to check if a feature is supported in _KVM_.
Manually querying cpuid to know whether the feature is supported or not
can b
On Tue, Oct 1, 2024 at 2:15 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Tue, Oct 1, 2024 at 1:14 AM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
> > > > wrote:
> > > > >
> > > > > Jason Xing wrote:
> > > > > > On M
kselftest/next kselftest-lib: 1 runs, 1 regressions (v6.12-rc1-2-g010b07d11e25)
Regressions Summary
---
platform| arch | lab | compiler | defconfig
| regressions
+--+-+--+--
kselftest/next kselftest-lkdtm: 1 runs, 1 regressions
(v6.12-rc1-2-g010b07d11e25)
Regressions Summary
---
platform| arch | lab | compiler | defconfig
| regressions
+--+-+--+---
step_after_suspend_test fails with device busy error while
writing to /sys/power/state to start suspend. The test believes
it failed to enter suspend state with
$ sudo ./step_after_suspend_test
TAP version 13
Bail out! Failed to enter Suspend state
However, in the kernel message, I indeed see the
Hi Shuah,
> On Sep 30, 2024, at 3:19 PM, Shuah Khan wrote:
>
> On 9/30/24 16:13, Shuah Khan wrote:
>> On 9/30/24 14:36, Yifei Liu wrote:
>>> "step_after_suspend_test fails with device busy error while
>
> You don't need quotes
>
>>> writing to /sys/power/state to start suspend."
>
> Same her
On 9/30/24 14:36, Yifei Liu wrote:
"step_after_suspend_test fails with device busy error while
writing to /sys/power/state to start suspend." The test believes
it failed to enter suspend state with
$ sudo ./step_after_suspend_test
TAP version 13
Bail out! Failed to enter Suspend state
However,
On 9/30/24 16:13, Shuah Khan wrote:
On 9/30/24 14:36, Yifei Liu wrote:
"step_after_suspend_test fails with device busy error while
You don't need quotes
writing to /sys/power/state to start suspend."
Same here.
The test believes
it failed to enter suspend state with
$ sudo ./step_after
kselftest/next build: 7 builds: 2 failed, 5 passed, 1 warning
(v6.12-rc1-2-g010b07d11e25)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/next/kernel/v6.12-rc1-2-g010b07d11e25/
Tree: kselftest
Branch: next
Git Describe: v6.12-rc1-2-g010b07d11e25
Git Commit: 010b07d11e259e37d2cd5
On 9/30/24 10:09, Siddharth Menon wrote:
Check if VMsize is 0 to determine whether the process has been unmapped.
The child process cannot signal the parent that it has unmapped itself,
as it no longer exists. This includes unmapping the text segment,
preventing the child from proceeding to the n
"step_after_suspend_test fails with device busy error while
writing to /sys/power/state to start suspend." The test believes
it failed to enter suspend state with
$ sudo ./step_after_suspend_test
TAP version 13
Bail out! Failed to enter Suspend state
However, in the kernel message, I indeed see
kselftest/fixes build: 7 builds: 2 failed, 5 passed, 1 warning
(v6.12-rc1-5-g45a8897db67d4)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/fixes/kernel/v6.12-rc1-5-g45a8897db67d4/
Tree: kselftest
Branch: fixes
Git Describe: v6.12-rc1-5-g45a8897db67d4
Git Commit: 45a8897db67d43a
kselftest/fixes build: 7 builds: 2 failed, 5 passed, 1 warning (v6.12-rc1)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/fixes/kernel/v6.12-rc1/
Tree: kselftest
Branch: fixes
Git Describe: v6.12-rc1
Git Commit: 9852d85ec9d492ebef56dc5f229416c925758edc
Git URL:
https://git.kern
Jason Xing wrote:
> On Tue, Oct 1, 2024 at 1:14 AM Willem de Bruijn
> wrote:
> >
> > Jason Xing wrote:
> > > On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
> > > wrote:
> > > >
> > > > Jason Xing wrote:
> > > > > On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
> > > > > wrote:
> > > > > >
> >
On Tue, Oct 1, 2024 at 1:14 AM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
> > > > wrote:
> > > > >
> > > > > Jason Xing wrote:
> > > > > > Fro
On 9/23/24 16:50, Yifei Liu wrote:
"step_after_suspend_test fails with device busy error while
writing to /sys/power/state to start suspend." The test believes
it failed to enter suspend state with
$ sudo ./step_after_suspend_test
TAP version 13
Bail out! Failed to enter Suspend state
However,
Jason Xing wrote:
> On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
> wrote:
> >
> > Jason Xing wrote:
> > > On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
> > > wrote:
> > > >
> > > > Jason Xing wrote:
> > > > > From: Jason Xing
> > > > >
> > > > > Even though this case is unlikely to happen
Check if VMsize is 0 to determine whether the process has been unmapped.
The child process cannot signal the parent that it has unmapped itself,
as it no longer exists. This includes unmapping the text segment,
preventing the child from proceeding to the next instruction.
Signed-off-by: Siddharth
From: Amit Cohen
The test runs "devlink reload" explicitly. Instead, it is better to use
devlink_reload() which waits for udev events to be processed. Do not sleep
after reload, as devlink_reload() blocks until all the netdevs are renamed.
Signed-off-by: Amit Cohen
Reviewed-by: Ido Schimmel
Si
On Mon, Sep 30, 2024 at 7:49 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing
> > > >
> > > > Even though this case is unlikely to happen, we have to avoid such
> > > > a case o
On Mon, Sep 30, 2024 at 7:54 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn
> > wrote:
> > >
> > > Jason Xing wrote:
> > > > From: Jason Xing
> > > >
> > > > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so
> > > > that we c
Jason Xing wrote:
> On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn
> wrote:
> >
> > Jason Xing wrote:
> > > From: Jason Xing
> > >
> > > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so
> > > that we can get aware of whether using write_seq as an initial key
> > > value works a
On Mon, Sep 30, 2024 at 6:42 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so
> > that we can get aware of whether using write_seq as an initial key
> > value works as expected.
>
> Does the test behave
Jason Xing wrote:
> On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
> wrote:
> >
> > Jason Xing wrote:
> > > From: Jason Xing
> > >
> > > Even though this case is unlikely to happen, we have to avoid such
> > > a case occurring at an earlier point: the sk_rmem_alloc could get
> > > increased bec
On Mon, Sep 30, 2024 at 6:39 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > Even though this case is unlikely to happen, we have to avoid such
> > a case occurring at an earlier point: the sk_rmem_alloc could get
> > increased because of inserting more and more skbs
On Mon, Sep 30, 2024 at 6:48 PM Vadim Fedorenko
wrote:
>
> On 30/09/2024 10:24, Jason Xing wrote:
> > From: Jason Xing
> >
> > Even though this case is unlikely to happen, we have to avoid such
> > a case occurring at an earlier point: the sk_rmem_alloc could get
> > increased because of insertin
On Mon, Sep 30, 2024 at 6:47 PM Willem de Bruijn
wrote:
>
> Jason Xing wrote:
> > From: Jason Xing
> >
> > Let it be tuned in per netns by admins.
> >
> > Signed-off-by: Jason Xing
>
> +1 on the idea
>
> > ---
> > include/net/netns/core.h | 1 +
> > include/net/sock.h | 2 --
>
> als
On 30/09/2024 10:24, Jason Xing wrote:
From: Jason Xing
Even though this case is unlikely to happen, we have to avoid such
a case occurring at an earlier point: the sk_rmem_alloc could get
increased because of inserting more and more skbs into the errqueue
when calling __skb_complete_tx_timesta
Jason Xing wrote:
> From: Jason Xing
>
> Let it be tuned in per netns by admins.
>
> Signed-off-by: Jason Xing
+1 on the idea
> ---
> include/net/netns/core.h | 1 +
> include/net/sock.h | 2 --
also remove the static global from sock.c
> net/core/net_namespace.c | 1 +
> ne
Jason Xing wrote:
> From: Jason Xing
>
> Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so
> that we can get aware of whether using write_seq as an initial key
> value works as expected.
Does the test behave different with this flag set?
>
> Signed-off-by: Jason Xing
> ---
>
Jason Xing wrote:
> From: Jason Xing
>
> Even though this case is unlikely to happen, we have to avoid such
> a case occurring at an earlier point: the sk_rmem_alloc could get
> increased because of inserting more and more skbs into the errqueue
> when calling __skb_complete_tx_timestamp(). This
On 2024/9/30 15:45, Tian, Kevin wrote:
From: Liu, Yi L
Sent: Thursday, September 12, 2024 9:13 PM
The iommu_attach_handle is optional in the RID attach/replace API and the
PASID attach APIs. But it is a mandatory argument for the PASID replace API.
Without it, the PASID replace path cannot get
On 2024/9/30 15:44, Tian, Kevin wrote:
From: Yi Liu
Sent: Thursday, September 12, 2024 9:13 PM
iommufd plans to always pass in an iommu_attach_handle to the iommu
core, so it's no longer fault specific, hence move the helpers out
of the fault.c
again please put the reason for why iommufd plan
On 2024/9/30 15:42, Tian, Kevin wrote:
From: Liu, Yi L
Sent: Thursday, September 12, 2024 9:13 PM
@@ -191,13 +187,25 @@ int iommufd_fault_domain_replace_dev(struct
iommufd_device *idev,
return ret;
}
- ret = __fault_domain_replace_dev(idev, hwpt, old);
+
From: Jason Xing
Introduce a test for SOF_TIMESTAMPING_OPT_ID_TCP for TCP proto so
that we can get aware of whether using write_seq as an initial key
value works as expected.
Signed-off-by: Jason Xing
---
tools/testing/selftests/net/txtimestamp.c | 6 ++
1 file changed, 6 insertions(+)
di
From: Jason Xing
Let it be tuned in per netns by admins.
Signed-off-by: Jason Xing
---
include/net/netns/core.h | 1 +
include/net/sock.h | 2 --
net/core/net_namespace.c | 1 +
net/core/skbuff.c | 2 +-
net/core/sysctl_net_core.c | 18 +-
5 files chang
From: Jason Xing
Even though this case is unlikely to happen, we have to avoid such
a case occurring at an earlier point: the sk_rmem_alloc could get
increased because of inserting more and more skbs into the errqueue
when calling __skb_complete_tx_timestamp(). This bad case would stop
the socket
From: Jason Xing
When reading through the whole feature, I feel we can do these things to
make it more robust. They are trivial changes, not big ones.
Jason Xing (3):
net-timestamp: add strict check when setting tx flags
net-timestamp: add OPT_ID_TCP test in selftests
net-timestamp: namesp
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:17 PM
>
> PASID usage requires PASID support in both device and IOMMU. Since the
> iommu drivers always enable the PASID capability for the device if it
> is supported, so it is reasonable to extend the IOMMU_GET_HW_INFO to
> report the PAS
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:17 PM
>
> +/*
> + * VFIO_DEVICE_PASID_ATTACH_IOMMUFD_PT - _IOW(VFIO_TYPE,
> VFIO_BASE + 21,
> + * struct
> vfio_device_pasid_attach_iommufd_pt)
> + * @argsz: User filled size of this data.
> + * @fl
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:17 PM
>
> There is no helpers for user to check if a given ID is allocated or not,
> neither a helper to loop all the allocated IDs in an IDA and do something
> for cleanup. With the two needs, a helper to get the lowest allocated ID
> of a
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:13 PM
>
> The iommu_attach_handle is optional in the RID attach/replace API and the
> PASID attach APIs. But it is a mandatory argument for the PASID replace API.
> Without it, the PASID replace path cannot get the old domain. Hence, the
>
> From: Yi Liu
> Sent: Thursday, September 12, 2024 9:13 PM
>
> iommufd plans to always pass in an iommu_attach_handle to the iommu
> core, so it's no longer fault specific, hence move the helpers out
> of the fault.c
again please put the reason for why iommufd plans to do so.
> --- a/drivers/i
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:13 PM
>
> @@ -191,13 +187,25 @@ int iommufd_fault_domain_replace_dev(struct
> iommufd_device *idev,
> return ret;
> }
>
> - ret = __fault_domain_replace_dev(idev, hwpt, old);
> + if (hwpt->fault) {
> +
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:13 PM
>
> +/**
> + * iommu_replace_device_pasid - Replace the domain that a pasid is
> attached to
> + * @domain: the new iommu domain
> + * @dev: the attached device.
> + * @pasid: the pasid of the device.
> + * @handle: the attach handle.
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:07 PM
>
> The iommu drivers are on the way to drop the remove_dev_pasid op by
> extending the blocked_domain to support PASID. However, this cannot be
> done in one shot. So far, the Intel iommu and the ARM SMMUv3 driver have
> supported it
> From: Yi Liu
> Sent: Thursday, September 12, 2024 9:07 PM
>
> The blocked domain can be extended to park PASID of a device to be the
> DMA blocking state. By this the remove_dev_pasid() op is dropped.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:07 PM
>
> From: Jason Gunthorpe
>
> The blocked domain is used to park RID to be blocking DMA state. This
> can be extended to PASID as well. By this, the remove_dev_pasid() op
> of ARM SMMUv3 can be dropped.
>
> Signed-off-by: Jason Gun
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> The iommu core is going to support domain replacement for pasid, it needs
> to make the set_dev_pasid op support replacing domain and keep the old
> domain config in the failure case.
>
> AMD iommu driver does not support domain
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> From: Jason Gunthorpe
>
> set_dev_pasid() op is going to be enhanced to support domain replacement
> of a pasid. This prepares for this op definition.
>
> Signed-off-by: Jason Gunthorpe
> Signed-off-by: Yi Liu
Reviewed-by: K
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> From: Lu Baolu
>
> Extend intel_iommu_set_dev_pasid() to set a nested type domain to a PASID
> of a device.
>
> Signed-off-by: Lu Baolu
> Co-developed-by: Yi Liu
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Baolu Lu
> Sent: Friday, September 13, 2024 10:17 AM
>
> On 9/13/24 9:35 AM, Baolu Lu wrote:
> > On 9/12/24 9:04 PM, Yi Liu wrote:
> >> +static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t
> >> pasid,
> >> + struct iommu_domain *domain)
> >> +{
> >> +
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> +/*
> + * Not all PASID entry destroy requires PRQ drain as it can be handled in
> + * the remove_dev_pasid path. Caller should be clear about it and set the
> + * @flags properly.
> + */
/*
* Caller can request to drain PRQ in
> From: Liu, Yi L
> Sent: Thursday, September 12, 2024 9:04 PM
>
> To support domain replacement for pasid, the underlying iommu driver
> needs
> to know the old domain hence be able to clean up the existing attachment.
> It would be much convenient for iommu layer to pass down the old domain.
>
59 matches
Mail list logo
