pagecache folio to order 3 at in-folio offset 16
passed
ok 32 Split PMD-mapped pagecache folio to order 3 at in-folio offset 24
passed
ok 33 Split PMD-mapped pagecache folio to order 4 at in-folio offset 0
passed
ok 34 Split PMD-mapped pagecache folio to order 4 at in-folio offset 16
passed
Fee
On 7/3/25 8:00 PM, Zi Yan wrote:
On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:
From: Donet Tom
The split_huge_page_test fails on systems with a 64KB base page size.
This is because the order of a 2MB huge page is different:
On 64KB systems, the order is 5.
On 4KB systems, it's 9.
On 7/3/25 8:11 PM, Zi Yan wrote:
On 3 Jul 2025, at 2:06, Aboorva Devarajan wrote:
From: Donet Tom
PowerPC64 supports a 4PB virtual address space, but this test was
previously limited to 512TB. This patch extends the coverage up to
the full 4PB VA range on PowerPC64.
Memory from 0 to 128TB
On 7/3/25 7:51 PM, Zi Yan wrote:
On 3 Jul 2025, at 4:58, Donet Tom wrote:
On 7/3/25 1:52 PM, David Hildenbrand wrote:
On 03.07.25 08:06, Aboorva Devarajan wrote:
From: Donet Tom
The split_huge_page_test fails on systems with a 64KB base page size.
This is because the order of a 2MB huge
On 7/3/25 2:44 PM, David Hildenbrand wrote:
On 03.07.25 10:51, Donet Tom wrote:
Hi David
On 7/3/25 2:03 PM, David Hildenbrand wrote:
On 03.07.25 08:06, Aboorva Devarajan wrote:
In ksm_functional_tests, test_child_ksm() returned negative values
to indicate errors. However, when passed to
On 7/3/25 1:52 PM, David Hildenbrand wrote:
On 03.07.25 08:06, Aboorva Devarajan wrote:
From: Donet Tom
The split_huge_page_test fails on systems with a 64KB base page size.
This is because the order of a 2MB huge page is different:
On 64KB systems, the order is 5.
On 4KB systems, it
Hi David
On 7/3/25 2:03 PM, David Hildenbrand wrote:
On 03.07.25 08:06, Aboorva Devarajan wrote:
In ksm_functional_tests, test_child_ksm() returned negative values
to indicate errors. However, when passed to exit(), these were
interpreted as large unsigned values (e.g, -2 became 254), leading t
On Thu, Jun 26, 2025 at 12:05:11PM +0530, Dev Jain wrote:
>
> On 26/06/25 11:12 am, Donet Tom wrote:
> > On Thu, Jun 26, 2025 at 09:27:30AM +0530, Dev Jain wrote:
> > > On 25/06/25 10:47 pm, Donet Tom wrote:
> > > > On Wed, Jun 25, 2025 at 06:22:53PM +0530, Dev Ja
On Thu, Jun 26, 2025 at 09:27:30AM +0530, Dev Jain wrote:
>
> On 25/06/25 10:47 pm, Donet Tom wrote:
> > On Wed, Jun 25, 2025 at 06:22:53PM +0530, Dev Jain wrote:
> > > On 19/06/25 1:53 pm, Donet Tom wrote:
> > > > On Wed, Jun 18, 2025 at 08:13:54PM +0530, Dev Ja
On Wed, Jun 25, 2025 at 06:22:53PM +0530, Dev Jain wrote:
>
> On 19/06/25 1:53 pm, Donet Tom wrote:
> > On Wed, Jun 18, 2025 at 08:13:54PM +0530, Dev Jain wrote:
> > > On 18/06/25 8:05 pm, Lorenzo Stoakes wrote:
> > > > On Wed, Jun 18, 2025 at 07:47:18PM +0530, D
eOn Tue, Jun 24, 2025 at 11:45:09AM +0530, Dev Jain wrote:
>
> On 23/06/25 11:02 pm, Donet Tom wrote:
> > On Mon, Jun 23, 2025 at 10:23:02AM +0530, Dev Jain wrote:
> > > On 21/06/25 11:25 pm, Donet Tom wrote:
> > > > On Fri, Jun 20, 2025 at 08:15:25PM +0530, Dev
On Mon, Jun 23, 2025 at 10:23:02AM +0530, Dev Jain wrote:
>
> On 21/06/25 11:25 pm, Donet Tom wrote:
> > On Fri, Jun 20, 2025 at 08:15:25PM +0530, Dev Jain wrote:
> > > On 19/06/25 1:53 pm, Donet Tom wrote:
> > > > On Wed, Jun 18, 2025 at 08:13:54PM +0530, Dev Ja
On Fri, Jun 20, 2025 at 08:15:25PM +0530, Dev Jain wrote:
>
> On 19/06/25 1:53 pm, Donet Tom wrote:
> > On Wed, Jun 18, 2025 at 08:13:54PM +0530, Dev Jain wrote:
> > > On 18/06/25 8:05 pm, Lorenzo Stoakes wrote:
> > > > On Wed, Jun 18, 2025 at 07:47:18PM +0530, D
t_fail_msg("Bad address %lx\n", addr);
This looks good to me. Feel free to add
Reviewed-by: Donet Tom
eOn Thu, Jun 19, 2025 at 02:32:19PM +0530, Dev Jain wrote:
>
> On 19/06/25 1:53 pm, Donet Tom wrote:
> > On Wed, Jun 18, 2025 at 08:13:54PM +0530, Dev Jain wrote:
> > > On 18/06/25 8:05 pm, Lorenzo Stoakes wrote:
> > > > On Wed, Jun 18, 2025 at 07:47:18PM +0530, D
On Wed, Jun 18, 2025 at 08:13:54PM +0530, Dev Jain wrote:
>
> On 18/06/25 8:05 pm, Lorenzo Stoakes wrote:
> > On Wed, Jun 18, 2025 at 07:47:18PM +0530, Dev Jain wrote:
> > > On 18/06/25 7:37 pm, Lorenzo Stoakes wrote:
> > > > On Wed, Jun 18, 2025 at 07:28:16PM +0530, Dev Jain wrote:
> > > > > On 1
On Mon, Jun 16, 2025 at 09:57:10PM +0530, Dev Jain wrote:
>
Hi Dev
> On 16/06/25 9:36 pm, Aboorva Devarajan wrote:
> > From: Donet Tom
> >
> > In this patch, we are fixing three issues in the virtual_address_range
> > test.
> >
> > 1. validate_addr()
> Co-developed-by: Sean Christopherson
> Signed-off-by: Sean Christopherson
> Co-developed-by: Pratik R. Sampat
> Signed-off-by: Pratik R. Sampat
> Signed-off-by: Ashish Kalra
One comment below, otherwise:
Reviewed-by: Tom Lendacky
> ---
> arch/x86/kvm/svm/sev.c | 44
set_cpu_caps(void)
>>> }
>>> }
>>>
>>> +static bool sev_is_snp_initialized(void)
>>
>> s/sev_is_snp_initialized/is_sev_snp_initalized looks better.
>>
>
> Actually the convention is sev_is_xx().
Except that it is a static, so doesn't need to start with sev_. See
is_pfn_range_shared(), max_level_for_order(), etc. in the same file.
Thanks,
Tom
>
>>> +{
p(void)
> sev_snp_supported = sev_snp_enabled &&
> cc_platform_has(CC_ATTR_HOST_SEV_SNP);
>
> out:
> + if (sev_enabled) {
> + init_args.probe = true;
> + if (sev_platform_init(&init_args))
> + sev_supported = sev_es_supported = sev_snp_sup
soft-dirty
CC protection_keys
CC va_high_addr_switch
CC virtual_address_range
CC write_to_hugetlbfs
Reviewed-by:Donet Tom
Tested-by: Donet Tom
/* 4-byte instructions * 16384 = 64K page */
-#define __page_o_noops() asm(".rept 16384 ; nop; .endr")
+#define __page_o
: 52428800
Populating.
Not writing to memory.
Using method=0
Shared mapping.
RESERVE mapping.
Allocating using HUGETLBFS.
Assert memory charged correctly for child only use.
actual = 10 MB
expected = 0 MB
cleanup
Feel free to add
Tested-by Donet Tom
Signed-off-by: Li Wang
Cc: Waiman Long
Cc
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #undef pr_fmt
>> #define pr_fmt(fmt) "vmware: " fmt
>> @@ -429,6 +432,10 @@ static void __init vmware_platform_setup(void)
>> pr_warn("Failed t
#
Signed-off-by: Donet Tom
---
tools/testing/selftests/mm/migration.c | 99 ++
1 file changed, 99 insertions(+)
diff --git a/tools/testing/selftests/mm/migration.c
b/tools/testing/selftests/mm/migration.c
index 64bcbb7151cf..1e3a595fbf01 100644
--- a/tools/testing/selftests
On 11/28/24 18:14, Mark Brown wrote:
On Thu, Nov 28, 2024 at 10:46:56AM +0530, Donet Tom wrote:
On 11/27/24 21:44, Mark Brown wrote:
+ ksft_test_result(free_hpage_a == free_hpage_b,
+"free huge pages from %u-%u\n", start_off, end_off);
This test a
On 11/27/24 21:44, Mark Brown wrote:
The string logged when a test passes or fails is used by the selftest
framework to identify which test is being reported. The hugetlb_dio test
not only uses the same strings for every test that is run but it also uses
different strings for test passes and fa
On 11/10/24 12:19, Donet Tom wrote:
This test verifies that a hugepage, used as a user buffer for
DIO operations, is correctly freed upon unmapping. To test this,
we read the count of free hugepages before and after the mmap,
DIO, and munmap operations, then check if the free hugepage count
is
On 11/10/24 12:19, Donet Tom wrote:
This test verifies that a hugepage, used as a user buffer for
DIO operations, is correctly freed upon unmapping. To test this,
we read the count of free hugepages before and after the mmap,
DIO, and munmap operations, then check if the free hugepage count
is
"selftests: hugetlb_dio: check for initial conditions to
skip in the start")
Signed-off-by: Donet Tom
---
tools/testing/selftests/mm/hugetlb_dio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/testing/selftests/mm/hugetlb_dio.c
b/tools/testing/selftests/mm/hugetlb_dio.
On 11/8/24 16:05, Donet Tom wrote:
On 11/1/24 19:45, Muhammad Usama Anjum wrote:
The test should be skipped if initial conditions aren't fulfilled in
the start instead of failing and outputting non-compliant TAP logs. This
kind of failure pollutes the results. The initial condition
On 11/1/24 19:45, Muhammad Usama Anjum wrote:
The test should be skipped if initial conditions aren't fulfilled in
the start instead of failing and outputting non-compliant TAP logs. This
kind of failure pollutes the results. The initial conditions are:
- The test should only execute if /tmp fi
On 9/27/24 12:48, Muhammad Usama Anjum wrote:
On 9/27/24 10:07 AM, Donet Tom wrote:
The hmm2 double_map test was failing due to an incorrect
buffer->mirror size. The buffer->mirror size was 6, while buffer->ptr
size was 6 * PAGE_SIZE. The test failed because the kernel's
copy_to
#OK hmm2.hmm2_device_private.double_map
ok 53 hmm2.hmm2_device_private.double_map
Signed-off-by: Donet Tom
---
tools/testing/selftests/mm/hmm-tests.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mm/hmm-tests.c
b/tools/testing/selftests/mm/hmm-tests.c
index d2c
> * To test, select CONFIG_SYNTH_EVENT_GEN_TEST and build the module.
> * Then:
> *
> * # insmod kernel/trace/synth_event_gen_test.ko
> * # cat /sys/kernel/tracing/trace
> *
> * You should see several events in the trace buffer -
> * "create_synth_test",
p *map, void *key,
> bool lookup_only)
> }
>
> memcpy(elt->key, key, map->key_size);
> - entry->val = elt;
> + /*
> + * Ensure the initialization is visible and
> + * publish the elt.
> + */
> + smp_wmb();
> + WRITE_ONCE(entry->val, elt);
> atomic64_inc(&map->hits);
>
> return entry->val;
>
> base-commit: 9d1694dc91ce7b80bc96d6d8eaf1a1eca668d847
Makes sense, thanks for fixing this!
Acked-by: Tom Zanussi
Tom
On Sat, Dec 9, 2023 at 6:18 PM Masahiro Yamada wrote:
> On Fri, Dec 8, 2023 at 8:14 PM Tom Cook wrote:
> >
> > I'm trying to build a signed .deb kernel package of
> > https://github.com/torvalds/linux/tree/v6.6. I've copied
> > certs/default_x509.genkey to c
Smatch reports this issue
security.c:416:6: warning: symbol '__nvdimm_security_overwrite_query' was not
declared. Should it be static?
__nvdimm_security_overwrite_query is only used in security.c so change
its storage-class specifier to static
Signed-off-by: Tom Rix
---
driv
if (offset >= len) {
+ dev_warn(&pcidev->dev, "bad port offset %u >=
%pa\n",
+offset, &len);
why %pa,&len for instead of %u,len ?
Tom
+ continue;
+ }
+ len
Hi Vinod,
On 4/20/2021 6:11 AM, Vinod Koul wrote:
On 03-04-21, 11:45, Tom Zanussi wrote:
+config INTEL_IDXD_PERFMON
+ bool "Intel Data Accelerators performance monitor support"
+ depends on INTEL_IDXD
+ default y
default y..?
Will change to n.
/* IDX
4.109-rt55 by applying the incremental patch:
https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch-5.4.109-rt55-rt56.patch.xz
Enjoy!
Tom
Changes from v5.4.109-rt55:
---
Sebastian Andrzej Siewior (1):
mm: slub: Don't resize the location tracking cache on PREEMPT_RT
T
On 4/15/21 11:09 AM, Paolo Bonzini wrote:
> On 07/04/21 20:00, Tom Lendacky wrote:
>> For the series:
>>
>> Acked-by: Tom Lendacky
>
> Shall I take this as a request (or permission, whatever :)) to merge it
> through the KVM tree?
Adding Herbert. Here&
3.html
https://github.com/Xilinx/dma_ip_drivers
Maybe its kernel or dpdk driver has what you need.
Tom
_LEGACY_INVALID 0x
+/* Secure update doorbell register, in system register region */
+#define M10BMC_DOORBELL0x400
To be consistent with the existing register #defines,
The bit values for the register should follow the register and have a
M10BMC_ prefix
To
On 4/9/21 11:50 AM, Max Zhen wrote:
Hi Tom,
On 3/31/21 6:03 AM, Tom Rix wrote:
On 3/23/21 10:29 PM, Lizhi Hou wrote:
The PCIE device driver which attaches to management function on Alveo
devices. It instantiates one or more group drivers which, in turn,
instantiate platform drivers. The
Acked-by: Lee Jones
lgtm
Reviewed-by: Tom Rix
---
v2: change variable name from m10bmc_bmc_subdevs to m10bmc_d5005_subdevs
added Acked-by: Lee Jones
---
drivers/hwmon/intel-m10-bmc-hwmon.c | 122
drivers/mfd/intel-m10-bmc.c | 10 +++
2
return PTR_ERR(aspi->base);
+ }
+
+ aspi->regmap = devm_regmap_init(dev, NULL, aspi, &indirect_regbus_cfg);
+ if (IS_ERR(aspi->regmap))
+ return PTR_ERR(aspi->regmap);
+
+ aspi->altr_spi = create_cntrl(dev, aspi->base, &m10_bmc_
On 4/12/2021 6:48 PM, Jason Gunthorpe wrote:
On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
So the issue is only in testing all the providers and platforms,
to be sure this new behavior isn't tickling anything that went
unnoticed all along, because no RDMA provider ever issu
of removing this function.
It should have been used in xlnx_pr_decoupler_enable_show() instead of
the bare readl().
So use it in this function, and for consistency rename to
xlnx_pr_decoupler_read()
that is 'decouple' -> 'decoupler'
Tom
static int xlnx_pr_decouple
On 4/12/2021 2:32 PM, Haakon Bugge wrote:
On 10 Apr 2021, at 15:30, David Laight wrote:
From: Tom Talpey
Sent: 09 April 2021 18:49
On 4/9/2021 12:27 PM, Haakon Bugge wrote:
On 9 Apr 2021, at 17:32, Tom Talpey wrote:
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10
-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917
> Suggested-by: Simon Glass
> Signed-off-by: Nathan Chancellor
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
On 4/9/2021 12:27 PM, Haakon Bugge wrote:
On 9 Apr 2021, at 17:32, Tom Talpey wrote:
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote
On 4/9/2021 12:40 PM, Jason Gunthorpe wrote:
On Fri, Apr 09, 2021 at 10:26:21AM -0400, Tom Talpey wrote:
My belief is that the biggest risk is from situations where completions
are batched, and therefore polling is used to detect them without
interrupts (which explicitly).
We don't do
On 4/9/21 9:38 AM, Tom Lendacky wrote:
> From: Tom Lendacky
>
> Access to the GHCB is mainly in the VMGEXIT path and it is known that the
> GHCB will be mapped. But there are two paths where it is possible the GHCB
> might not be mapped.
>
> The sev_vcpu_deliver_sipi_
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
We need to get a better idea what correctness testing has been done,
and whether
On 4/8/21 2:48 PM, Sean Christopherson wrote:
> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>>
>>
>> On 4/8/21 12:37 PM, Sean Christopherson wrote:
>>> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>>>> On 4/8/21 12:10 PM, Sean Christopherson wrote:
>
From: Tom Lendacky
Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold
e should test on the platforms they have.
Yes, and "test" be taken seriously with focus on ULP data integrity.
Speedups will mean nothing if the data is ever damaged.
Tom.
On 4/8/21 12:37 PM, Sean Christopherson wrote:
> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>> On 4/8/21 12:10 PM, Sean Christopherson wrote:
>>> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>>>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>>
On 4/8/21 12:10 PM, Sean Christopherson wrote:
> On Thu, Apr 08, 2021, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> Access to the GHCB is mainly in the VMGEXIT path and it is known that the
>> GHCB will be mapped. But there are two paths where it is possible the
F(VIRT_SSBD) |
> - F(AMD_SSB_NO) | F(AMD_STIBP) | F(AMD_STIBP_ALWAYS_ON)
> + F(AMD_SSB_NO) | F(AMD_STIBP) | F(AMD_STIBP_ALWAYS_ON) |
> F(AMD_PSFD)
Please note that this patch has a pre-req against the PSFD support that
defines this feature:
https://lore.kernel.org/lkml/20210406155004.230790-2-rsari...@amd.com/#t
Thanks,
Tom
> );
>
> /*
>
From: Tom Lendacky
Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold
On 4/8/21 11:14 AM, Paolo Bonzini wrote:
> On 08/04/21 18:04, Tom Lendacky wrote:
>>>>> + if (!err || !sev_es_guest(vcpu->kvm) ||
>>>>> !WARN_ON_ONCE(svm->ghcb))
>>>> This should be WARN_ON_ONCE(!svm->ghcb), otherwise you'll g
On 4/7/21 4:07 PM, Sean Christopherson wrote:
> On Wed, Apr 07, 2021, Tom Lendacky wrote:
>> On 4/7/21 3:08 PM, Sean Christopherson wrote:
>>> On Wed, Apr 07, 2021, Tom Lendacky wrote:
>>>> From: Tom Lendacky
>>>>
>>>> The sev_vcpu_delive
On 4/7/21 2:45 PM, Borislav Petkov wrote:
> On Wed, Apr 07, 2021 at 01:25:55PM +0200, Borislav Petkov wrote:
>> On Tue, Apr 06, 2021 at 02:42:43PM -0500, Tom Lendacky wrote:
>>> The GHCB spec only defines the "0" reason code set. We could provide Linux
>>> it
On 4/7/21 3:08 PM, Sean Christopherson wrote:
> On Wed, Apr 07, 2021, Tom Lendacky wrote:
>> From: Tom Lendacky
>>
>> The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
>> the caller of the AP Reset Hold NAE event that a SIPI has been delivere
From: Tom Lendacky
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB may not be mapped, which will result in a
orary
> patch (definitely feel free to drop the patch if it's not worth
> backporting). [Christophe]
> - s/intput/input/. [Tom]
> - Add a patch to free "sev" if init fails. This is not strictly
> necessary (I think; I suck horribly when it comes to the
quired for SEV-SNP guests.
The final version of the spec documents that and should be published
within the next few days.
Thanks,
Tom
>
>
>>
>>> because the hypervisor may prefer that a guest use a consistent and/or
>>> specific GPA for the GHCB associated with a
.
> While exiting from the decompression the sev_es_shutdown_ghcb() is
> called to deinit the GHCB.
>
> sev_es_shutdown_ghcb()
>
> set_page_encrypted()
>
> sev_snp_set_page_private()
>
> Now that sev_snp_set_private() is called after the GHCB is established.
I believe the
configuration
+#
+
+config FPGA_XRT_XMGMT
+ tristate "Xilinx Alveo Management Driver"
+ depends on FPGA_XRT_LIB
+ select FPGA_XRT_METADATA
If the XRT driver depends on these other two configs and it does not
make sense to build these two seperately, could you remove th
res || !strncmp(res->name, gate->ep_name, strlen(res->name) + 1)) {
+ xleaf_put_leaf(pdev, leaf);
+ return;
+ }
+
+ /* higher level axigate instance created, make sure the gate is opened.
*/
ok
only minor ws issue, otherwise good to go
Reviewed-by:
}
+
+ if (status & BIT(0))
+ break;
+ msleep(XRT_CALIB_READ_INTERVAL);
ok
Reviewed-by: Tom Rix
+ times--;
+ }
+
+ if (!times) {
+ xrt_err(calib->pdev,
+ "MIG calibration ti
goto failed;
+ }
+
+ CLKFREQ_INFO(clkfreq, "successfully initialized clkfreq subdev");
+
+ return 0;
+
+failed:
+ return ret;
+}
+
+static struct xrt_subdev_endpoints xrt_clkfreq_endpoints[] = {
+ {
+ .xse_names = (struct xrt_subdev_ep_names[]) {
me, NULL, XRT_MD_PROP_CLK_FREQ,
+ (const void **)&freq, NULL);
+ if (err) {
+ xrt_info(clock->pdev, "no default freq");
+ return 0;
+ }
+
+ err = set_freq(clock, be16_to_cpu(*freq));
+
+ return err;
+}
+
+s
ecial like
>>
>> GHCB_SEV_ES_REASON_PSC_FAILURE
>>
>> or so, so that users know what has happened?
>
>
> Current GHCB does not have special code for this. But I think Linux
> guest can define a special code which can be used to indicate the
> termination reason
the situation *TODAY*, even ignoring TDX.
>
> BTW, I'm pretty sure I know the answer to the "why would you expose this
> to userspace" question: it's what QEMU/KVM did alreadhy for
> non-encrypted memory, so this was the quickest way to get SEV working.
>
> So, I don't like the #MC either. But, this series is a step in the
> right direction for TDX *AND* SEV.
So, yes, this is a step in the right direction.
Thanks,
Tom
>
p_bulk_read(devctl->regmap[rw_arg->xdr_id],
rw_arg->xdr_offset,
+ rw_arg->xdr_buf,
+ rw_arg->xdr_len /
devctl_regmap_config.reg_stride);
+ break;
+ }
ok, *_WRITE removed.
Thanks for
failed:
+ mutex_unlock(&icap->icap_lock);
+
+ return err;
+}
+
+/*
+ * Discover the FPGA IDCODE using special sequence of canned commands
+ */
+static int icap_probe_chip(struct icap *icap)
+{
+ int err;
+ u32 val = 0;
ok, thanks for demagic-ing this function.
Lo
aham I
> ---
> .../pci/controller/cadence/pcie-cadence-ep.c | 207 --
> drivers/pci/controller/cadence/pcie-cadence.h | 7 +
> 2 files changed, 197 insertions(+), 17 deletions(-)
>
Acked-by: Tom Joseph
https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/patch-5.4.109-rt55.patch.xz
Enjoy!
Tom
if (acc & ~IB_ACCESS_LOCAL_WRITE) {
dev_warn(&dev->pdev->dev,
"unsupported dma mr access flags %#x\n", acc);
Why does the pvrdma driver require relaxed ordering to be off?
Tom.
gest making this the default behavior
without extensive testing.
Tom.
On 4/5/21 11:33 AM, Sean Christopherson wrote:
> On Mon, Apr 05, 2021, Tom Lendacky wrote:
>> On 4/2/21 6:36 PM, Sean Christopherson wrote:
>>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>>> index 6556d220713b..4c513318f16a 100644
>&
on-zero length and are not known to the kernel. This is not an
> explicit goal, but arguably the side effect is a good thing from the
> kernel's perspective.
>
> Cc: Brijesh Singh
> Cc: Borislav Petkov
> Cc: Tom Lendacky
> Signed-off-by: Sean Christopherson
>
From: Tom Zanussi
Hi,
This is v2 of the IDXD pmu support patch, which is the same as v1 but
removes a few assigned-but-unused variables reported by kernel test
robot .
Thanks,
Tom
-- original v1 text --
Hi,
This patchset implements initial pmu support for the Intel DSA (Data
Streaming
ation.html
[ Based on work originally by Jing Lin. ]
Reviewed-by: Dave Jiang
Reviewed-by: Kan Liang
Signed-off-by: Tom Zanussi
---
drivers/dma/Kconfig | 13 +
drivers/dma/idxd/Makefile| 2 +
drivers/dma/idxd/idxd.h | 45 +++
drivers/dma/idxd/init.c | 9 +
drivers/dma/idx
ation.html
[ Based on work originally by Jing Lin. ]
Reviewed-by: Dave Jiang
Reviewed-by: Kan Liang
Signed-off-by: Tom Zanussi
---
drivers/dma/Kconfig | 13 +
drivers/dma/idxd/Makefile| 2 +
drivers/dma/idxd/idxd.h | 45 +++
drivers/dma/idxd/init.c | 9 +
drivers/dma/idx
t, but would be willing to try if there would be
some interest in it, especially considering there will probably be
future pmu support added that could benefit from it.
Thanks,
Tom
[1]:
https://software.intel.com/content/www/us/en/develop/download/intel-data-streaming-accele
Please add to this patch cover letter what you want to discuss.
Got this new feature, not sure about ...
Tom
On 4/2/21 2:09 AM, Nava kishore Manne wrote:
> Nava kishore Manne (3):
> fpga: region: Add fpga-region property 'fpga-config-from-dmabuf'
> fpga: support loading f
XRT_SUBDEV_CLOCK, instance);
> + if (!leaf) {
> + xrt_err(pdev, "does not get clock subdev");
> + return;
> + }
> +
> + xleaf_call(leaf, XRT_CLOCK_VERIFY, NULL);
> + xleaf_put_leaf(pdev, leaf);
> +}
ok on removing ucs_
xrt_err(vsec->pdev, "Map failed");
> + return -EIO;
> + }
> +
> + vsec->regmap = devm_regmap_init_mmio(&vsec->pdev->dev, base,
> &vsec_regmap_config);
> + if (IS_ERR(vsec->regmap)) {
> + xrt_err(vsec->pdev, &quo
that wrappers around core memory allocators are to
be avoided.
Tom.
get->xmmigas_section_kind,
> + &get->xmmigas_section,
> +
> &get->xmmigas_section_size);
> + }
> + break;
> + }
> +
egion = fpga_region_class_find(NULL, &arg,
> xmgmt_region_match);
> + if (!compat_region) {
> + xrt_err(pdev, "failed to get compatible region");
> + rc = -ENOENT;
> + goto failed;
> + }
>
tl &
> ~PCI_EXP_DEVCTL_FERE));
> + pci_read_config_byte(bus->self, PCI_BRIDGE_CONTROL, &pci_bctl);
> + pci_write_config_byte(bus->self, PCI_BRIDGE_CONTROL, pci_bctl |
> PCI_BRIDGE_CTL_BUS_RESET);
ok
> + msleep(100);
> + pci_write_config_byte(bus->se
(pdev)));
> + }
> + return 0;
> +}
> +
> +void xrt_subdev_pool_trigger_event(struct xrt_subdev_pool *spool, enum
> xrt_events e)
> +{
> + struct platform_device *tgt = NULL;
> + struct xrt_subdev *sdev = NULL;
> + struct xrt_event evt;
> +
> +
ruct xroot *xr)
ok
> +{
> + xrt_subdev_pool_init(DEV(xr->pdev), &xr->groups.pool);
> + INIT_WORK(&xr->groups.bringup_work, xroot_bringup_group_work);
> + atomic_set(&xr->groups.bringup_pending, 0);
> + atomic_set(&xr->groups.bringup_failed, 0
, sizeof(fname), "%s/%s/%s.%s", XRT_CDEV_DIR,
> + DEV_PDATA(pdev)->xsp_root_name, file_name, inst_name);
> + }
> + sysdev = device_create(xrt_class, NULL, cdevp->dev, NULL, "%s", fname);
> + if (IS_ERR(sysdev)) {
> +
xrt_drv_name(did), ret);
> + }
> + if (!dtb) {
> + /*
> + * No more dtb to cut or bad things happened
> for this instance,
> +
#x27;s are not supported.
> +static void (*leaf_init_fini_cbs[])(bool) = {
> + group_leaf_init_fini,
> + vsec_leaf_init_fini,
> + devctl_leaf_init_fini,
> + axigate_leaf_init_fini,
> + icap_leaf_init_fini,
> + calib_leaf_init_fini,
> + clkfreq_leaf_init_fini,
> + clock_leaf_init_fini,
> + ucs_leaf_init_fini,
> +};
> +
> +static __init int xrt_lib_init(void)
> +{
> + int i;
> +
> + xrt_class = class_create(THIS_MODULE, XRT_IPLIB_MODULE_NAME);
> + if (IS_ERR(xrt_class))
> + return PTR_ERR(xrt_class);
> +
> + for (i = 0; i < ARRAY_SIZE(leaf_init_fini_cbs); i++)
> + leaf_init_fini_cbs[i](true);
> + return 0;
> +}
> +
> +static __exit void xrt_lib_fini(void)
> +{
> + struct xrt_drv_map *map;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(leaf_init_fini_cbs); i++)
> + leaf_init_fini_cbs[i](false);
> +
> + mutex_lock(&xrt_lib_lock);
> +
> + while (!list_empty(&xrt_drv_maps)) {
> + map = list_first_entry_or_null(&xrt_drv_maps, struct
> xrt_drv_map, list);
> + pr_err("Unloading module with %s still registered\n",
> XRT_DRVNAME(map->drv));
> + list_del(&map->list);
> + mutex_unlock(&xrt_lib_lock);
> + xrt_drv_unregister_driver(map);
> + kfree(map);
> + mutex_lock(&xrt_lib_lock);
> + }
> +
> + mutex_unlock(&xrt_lib_lock);
> +
> + class_destroy(xrt_class);
> +}
> +
> +module_init(xrt_lib_init);
> +module_exit(xrt_lib_fini);
> +
> +MODULE_VERSION(XRT_IPLIB_MODULE_VERSION);
> +MODULE_AUTHOR("XRT Team ");
> +MODULE_DESCRIPTION("Xilinx Alveo IP Lib driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/fpga/xrt/lib/lib-drv.h b/drivers/fpga/xrt/lib/lib-drv.h
> new file mode 100644
> index ..a94c58149cb4
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/lib-drv.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + * Cheng Zhen
> + */
> +
> +#ifndef _LIB_DRV_H_
> +#define _LIB_DRV_H_
> +
> +const char *xrt_drv_name(enum xrt_subdev_id id);
bisectablity may be /is still an issue.
Tom
> +int xrt_drv_get_instance(enum xrt_subdev_id id);
> +void xrt_drv_put_instance(enum xrt_subdev_id id, int instance);
> +struct xrt_subdev_endpoints *xrt_drv_get_endpoints(enum xrt_subdev_id id);
> +
> +#endif /* _LIB_DRV_H_ */
1 - 100 of 2579 matches
Mail list logo
