Re: [PATCH 0/3] tracing: Fix some selftest issues
Hi Masami, On Wed, 2024-05-29 at 08:38 +0900, Masami Hiramatsu wrote: > On Wed, 29 May 2024 01:46:40 +0900 > Masami Hiramatsu (Google) wrote: > > > On Mon, 27 May 2024 19:29:07 -0400 > > Steven Rostedt wrote: > > > > > On Sun, 26 May 2024 19:10:57 +0900 > > > "Masami Hiramatsu (Google)" wrote: > > > > > > > Hi, > > > > > > > > Here is a series of some fixes/improvements for the test > > > > modules and boot > > > > time selftest of kprobe events. I found a WARNING message with > > > > some boot > > > > time selftest configuration, which came from the combination of > > > > embedded > > > > kprobe generate API tests module and ftrace boot-time selftest. > > > > So the main > > > > problem is that the test module should not be built-in. But I > > > > also think > > > > this WARNING message is useless (because there are warning > > > > messages already) > > > > and the cleanup code is redundant. This series fixes those > > > > issues. > > > > > > Note, when I enable trace tests as builtin instead of modules, I > > > just > > > disable the bootup self tests when it detects this. This helps > > > with > > > doing tests via config options than having to add user space code > > > that > > > loads modules. > > > > > > Could you do something similar? > > > > OK, in that case, I would like to move the test cleanup code in > > module_exit function into the end of module_init function. > > It looks there is no reason to split those into 2 parts. > > Wait, I would like to hear Tom's opinion. I found following usage > comments > in the code. > > * Following that are a few examples using the created events to test > * various ways of tracing a synthetic event. > * > * 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", "empty_synth_test", and several instances of > * "gen_synth_test". > * > * To remove the events, remove the module: > * > * # rmmod synth_event_gen_test > > Tom, is that intended behavior ? and are you expected to reuse these > events outside of the module? e.g. load the test module and run some > test script in user space which uses those events? > Yeah, this module was meant as a sample module showing how to create and generate synthetic events in-kernel. So the interested user insmods the module, looks at the trace stream and sees, ok the events are there as expected, so it does work, great, let's remove the module to get rid of them and go write our own. Having both the creation and cleanup in module_init() wouldn't allow the user the opportunity to do that i.e. verify the results by reading the trace file. Tom > As far as I can see, those tests are not intended to be embedded in > the > kernel because those are expected to be removed. > > Thank you, > > > > > Thank you, > > > > > > > > -- Steve > > > > > > > > > > > > > > Thank you, > > > > > > > > --- > > > > > > > > Masami Hiramatsu (Google) (3): > > > > tracing: Build event generation tests only as modules > > > > tracing/kprobe: Remove unneeded WARN_ON_ONCE() in > > > > selftests > > > > tracing/kprobe: Remove cleanup code unrelated to selftest > > > > > > > > > > -- > > Masami Hiramatsu (Google) > >
Re: [PATCH] tracing: Ensure visibility when inserting an element into tracing_map
new key. Subsequent updates targeting the same key remain unaffected.
>
> From the user's perspective, the issue was introduced by commit
> c193707dde77 ("tracing: Remove code which merges duplicates"), which
> followed commit cbf4100efb8f ("tracing: Add support to detect and avoid
> duplicates"). The previous code operated differently; it inherently
> expected potential races which result in duplicates but merged them
> later when they occurred.
>
> Fixes: c193707dde77 ("tracing: Remove code which merges duplicates")
> Signed-off-by: Petr Pavlu
> ---
> kernel/trace/tracing_map.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c
> index c774e560f2f9..a4dcf0f24352 100644
> --- a/kernel/trace/tracing_map.c
> +++ b/kernel/trace/tracing_map.c
> @@ -574,7 +574,12 @@ __tracing_map_insert(struct tracing_map *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(>hits);
>
> return entry->val;
>
> base-commit: 9d1694dc91ce7b80bc96d6d8eaf1a1eca668d847
Makes sense, thanks for fixing this!
Acked-by: Tom Zanussi
Tom
Re: Building signed debs
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 certs/x509.genkey. The .config is the > > one from Ubuntu 23.10's default kernel with all new options accepted > > at their default and CONFIG_SYSTEM_TRUSTED_KEYS="" and > > CONFIG_SYSTEM_REVOCATION_KEYS="". > > > > This builds the kernel and modules, signs the modules, compresses the > > modules and then attempts to sign the modules again. That fails, > > because the .ko module files are now .ko.zst files and the file it's > > trying to sign isn't there. Full failure is pasted below. > > > > Modules are signed before the compression. Reading back through my earlier email, I wasn't clear that when I said "This builds the kernel..." I meant "`make deb-pkg` builds the kernel". I'm not doing anything outlandish here, I think, just expecting the build system to work. Regards, Tom
[PATCH] libnvdimm/security: change __nvdimm_security_overwrite_query from global to static
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
---
drivers/nvdimm/security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c
index 4b80150e4afa..d3e782662bf4 100644
--- a/drivers/nvdimm/security.c
+++ b/drivers/nvdimm/security.c
@@ -413,7 +413,7 @@ static int security_overwrite(struct nvdimm *nvdimm,
unsigned int keyid)
return rc;
}
-void __nvdimm_security_overwrite_query(struct nvdimm *nvdimm)
+static void __nvdimm_security_overwrite_query(struct nvdimm *nvdimm)
{
struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(>dev);
int rc;
--
2.27.0
Re: [PATCH] fpga: dfl: pci: gracefully handle misconfigured port entries
On 4/20/21 10:27 AM, matthew.gerl...@linux.intel.com wrote:
From: Matthew Gerlach
Gracefully ignore misconfigured port entries encountered in
incorrect FPGA images.
Signed-off-by: Matthew Gerlach
---
drivers/fpga/dfl-pci.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index b44523e..660d3b6 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -212,6 +212,7 @@ static int find_dfls_by_default(struct pci_dev *pcidev,
Does something similar need to be added to find_dfls_by_vsec ?
int port_num, bar, i, ret = 0;
resource_size_t start, len;
void __iomem *base;
+ int bars = 0;
u32 offset;
u64 v;
@@ -228,6 +229,7 @@ static int find_dfls_by_default(struct pci_dev *pcidev,
if (dfl_feature_is_fme(base)) {
start = pci_resource_start(pcidev, 0);
len = pci_resource_len(pcidev, 0);
+ bars |= BIT(0);
dfl_fpga_enum_info_add_dfl(info, start, len);
@@ -253,9 +255,21 @@ static int find_dfls_by_default(struct pci_dev *pcidev,
*/
bar = FIELD_GET(FME_PORT_OFST_BAR_ID, v);
offset = FIELD_GET(FME_PORT_OFST_DFH_OFST, v);
+ if (bars & BIT(bar)) {
+ dev_warn(>dev, "skipping bad port BAR
%d\n", bar);
+ continue;
+ }
+
start = pci_resource_start(pcidev, bar) + offset;
- len = pci_resource_len(pcidev, bar) - offset;
+ len = pci_resource_len(pcidev, bar);
+ if (offset >= len) {
+ dev_warn(>dev, "bad port offset %u >=
%pa\n",
+offset, );
why %pa, for instead of %u,len ?
Tom
+ continue;
+ }
+ len -= offset;
+ bars |= BIT(bar);
dfl_fpga_enum_info_add_dfl(info, start, len);
}
} else if (dfl_feature_is_port(base)) {
Re: [PATCH v2 1/1] dmaengine: idxd: Add IDXD performance monitor support
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.
/* IDXD software descriptor */
@@ -369,4 +399,19 @@ int idxd_cdev_get_major(struct idxd_device *idxd);
int idxd_wq_add_cdev(struct idxd_wq *wq);
void idxd_wq_del_cdev(struct idxd_wq *wq);
+/* perfmon */
+#ifdef CONFIG_INTEL_IDXD_PERFMON
maybe use IS_ENABLED()
@@ -556,6 +562,8 @@ static int __init idxd_init_module(void)
for (i = 0; i < IDXD_TYPE_MAX; i++)
idr_init(_idrs[i]);
+ perfmon_init();
+
err = idxd_register_bus_type();
if (err < 0)
return err;
@@ -589,5 +597,6 @@ static void __exit idxd_exit_module(void)
pci_unregister_driver(_pci_driver);
idxd_cdev_remove();
idxd_unregister_bus_type();
+ perfmon_exit();
Ideally would make sense to add perfmon module first and then add use in
idxd..
OK, I'll separate this out into a separate patch.
+static ssize_t cpumask_show(struct device *dev, struct device_attribute *attr,
+ char *buf);
+
+static cpumask_t perfmon_dsa_cpu_mask;
+static boolcpuhp_set_up;
+static enum cpuhp_statecpuhp_slot;
+
+static DEVICE_ATTR_RO(cpumask);
Pls document these new attributes added
+static int perfmon_collect_events(struct idxd_pmu *idxd_pmu,
+ struct perf_event *leader,
+ bool dogrp)
dogrp..?
Yeah, bad name, first thought on seeing it is always 'dog'. ;-)
+static int perfmon_validate_group(struct idxd_pmu *pmu,
+ struct perf_event *event)
+{
+ struct perf_event *leader = event->group_leader;
+ struct idxd_pmu *fake_pmu;
+ int i, ret = 0, n;
+
+ fake_pmu = kzalloc(sizeof(*fake_pmu), GFP_KERNEL);
+ if (!fake_pmu)
+ return -ENOMEM;
+
+ fake_pmu->pmu.name = pmu->pmu.name;
+ fake_pmu->n_counters = pmu->n_counters;
+
+ n = perfmon_collect_events(fake_pmu, leader, true);
+ if (n < 0) {
+ ret = n;
+ goto out;
+ }
+
+ fake_pmu->n_events = n;
+ n = perfmon_collect_events(fake_pmu, event, false);
+ if (n < 0) {
+ ret = n;
+ goto out;
+ }
+
+ fake_pmu->n_events = n;
+
+ for (i = 0; i < n; i++) {
+ int idx;
lets move it to top of the function please
+static inline u64 perfmon_pmu_read_counter(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = >hw;
+ struct idxd_device *idxd;
+ int cntr = hwc->idx;
+ u64 cntrdata;
+
+ idxd = event_to_idxd(event);
+
+ cntrdata = ioread64(CNTRDATA_REG(idxd, cntr));
+
+ return cntrdata;
return ioread64() ?
Yeah, I removed some intervening code and didn't change this, will do.
Thanks for reviewing this,
Tom
[ANNOUNCE] 5.4.109-rt56
Hello RT Folks! I'm pleased to announce the 5.4.109-rt56 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v5.4-rt Head SHA1: a84a83ce44cafc96cb9cf419378a713dcdea00ac Or to build 5.4.109-rt56 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.4.tar.xz https://www.kernel.org/pub/linux/kernel/v5.x/patch-5.4.109.xz https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/patch-5.4.109-rt56.patch.xz You can also build from 5.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 Tom Zanussi (1): Linux 5.4.109-rt56 --- localversion-rt | 2 +- mm/slub.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) --- diff --git a/localversion-rt b/localversion-rt index 51b05e9abe6f..fdb0f880c7e9 100644 --- a/localversion-rt +++ b/localversion-rt @@ -1 +1 @@ --rt55 +-rt56 diff --git a/mm/slub.c b/mm/slub.c index 1815e28852fe..0d78368d149a 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4647,6 +4647,9 @@ static int alloc_loc_track(struct loc_track *t, unsigned long max, gfp_t flags) struct location *l; int order; + if (IS_ENABLED(CONFIG_PREEMPT_RT) && flags == GFP_ATOMIC) + return 0; + order = get_order(sizeof(struct location) * max); l = (void *)__get_free_pages(flags, order);
Re: [PATCH v2 0/8] ccp: KVM: SVM: Use stack for SEV command buffers
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's a link to the series:
https://lore.kernel.org/kvm/88eef561-6fd8-a495-0d60-ff688070c...@redhat.com/T/#m2bbdd12452970d3bd7d0b1464c22bf2f0227a9f1
I'm not sure how you typically do the cross-tree stuff. Patch 8 has a
requirement on patches 1-7. The arch/x86/kvm/svm/sev.c file tends to have
more activity/changes than drivers/crypto/ccp/sev-dev.{c,h}, so it would
make sense to take it through the KVM tree. But I think you need to verify
that with Herbert.
Thanks,
Tom
>
> Paolo
>
Re: Proposal of improvement for DMA - direct passing of hugepages to the SG list
On 4/14/21 4:58 AM, w...@ise.pw.edu.pl wrote: Hi, I'm working both on DMA engines implementations in FPGA and their Linux drivers. Now I need to create an engine that takes the hugepages-backed buffer allocated by the user-space application and passes it to the device. My current solution: https://forums.xilinx.com/t5/Embedded-Linux/How-to-pass-efficiently-the-hugepages-backed-buffer-to-the-BM/m-p/1229340/highlight/true#M49777 or https://stackoverflow.com/a/67065962/1735409 uses the get_user_pages_fast function, to create the kernel mapping, and then uses sg_alloc_table_from_pages to build sg_table for it. I have verified that the created sg_table has one entry for each individual hugepage (so I can efficiently map it for my SG-capable DMA device). The disadvantage of that solution is that I need to create and keep a huge set of standard-size pages. Because the "struct page" occupies between 56 and 80 bytes, I get the overhead up to 80/4096 which is approx. 2%. The open question is if I can free those pages as soon as the sg_table is created? (As far as I know, the hugepages are locked automatically). Of course it is unclear what happens if the application crashes and its mmaped hugepage-based buffer gets freed. Will the driver be notified about closing the file so that it can disable DMA before that memory can be taken for other purposes? To be sure that it doesn't happen maybe it is good to keep those pages locked in the kernel as well. The big improvement would be if we could have the get_user_hugepages_fast function. The user should be allowed to create a smaller number of page structs. The function should check if the requested region really consists of hugepages and return an error if it doesn't. Another important fact is that we don't need a kernel mapping for those pages at all. So it would be good to have yet another function: sg_alloc_table_from_user_pages which should take an additional "flag" argument enabling the user to decide if the area used consists of normal pages or of hugepages. The function should return an error in case if the flag does not match the properties of the region. Of course the function should also lock the pages, and sg_free_table should unlock them (protecting against the danger of application crash, that I described above). As a temporary workaround, is it possible to "manually" walk the pages creating the application-delivered buffer, verify that they are hugepages, lock them and create the sg_table? What functions/macros should be used for that to ensure that the implemented solution be portable and keeps working in a reasonable number of future versions of the Linux kernel? I'll appreciate comments, suggestions and considering of the above proposal. With best regards, Wojtek Do you have trial patch you could RFC ? Are you aware of the xilinx qdma patchset ? https://www.xilinx.com/support/answers/71453.html https://github.com/Xilinx/dma_ip_drivers Maybe its kernel or dpdk driver has what you need. Tom
Re: [PATCH v9 1/1] mfd: intel-m10-bmc: support for MAX10 BMC Secure Updates
On 4/12/21 12:53 PM, Russ Weight wrote: Add macros and definitions required by the MAX10 BMC Secure Update driver. Signed-off-by: Russ Weight Acked-by: Lee Jones --- v9: - Rebased on next-20210412 v8: - Previously patch 1/6 in "Intel MAX10 BMC Secure Update Driver" - Rebased on next-20210121 v7: - No change v6: - No change v5: - Renamed USER_FLASH_COUNT to STAGING_FLASH_COUNT v4: - No change v3: - Changed "MAX10 BMC Secure Engine driver" to "MAX10 BMC Secure Update driver" - Removed wrapper functions (m10bmc_raw_*, m10bmc_sys_*). The underlying functions will be called directly. v2: - These functions and macros were previously distributed among the patches that needed them. They are now grouped together in a single patch containing changes to the Intel MAX10 BMC driver. - Added DRBL_ prefix to some definitions - Some address definitions were moved here from the .c files that use them. --- include/linux/mfd/intel-m10-bmc.h | 85 +++ 1 file changed, 85 insertions(+) diff --git a/include/linux/mfd/intel-m10-bmc.h b/include/linux/mfd/intel-m10-bmc.h index c4eb38c13eda..f0044b14136e 100644 --- a/include/linux/mfd/intel-m10-bmc.h +++ b/include/linux/mfd/intel-m10-bmc.h @@ -16,6 +16,9 @@ #define M10BMC_FLASH_END 0x1fff #define M10BMC_MEM_ENDM10BMC_FLASH_END +#define M10BMC_STAGING_BASE 0x1800 +#define M10BMC_STAGING_SIZE0x380 + /* Register offset of system registers */ #define NIOS2_FW_VERSION 0x0 #define M10BMC_MAC_LOW0x10 @@ -33,6 +36,88 @@ #define M10BMC_VER_PCB_INFO_MSK GENMASK(31, 24) #define M10BMC_VER_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 Tom + +/* Authorization Result register, in system register region */ +#define M10BMC_AUTH_RESULT 0x404 + +/* Doorbell register fields */ +#define DRBL_RSU_REQUEST BIT(0) +#define DRBL_RSU_PROGRESS GENMASK(7, 4) +#define DRBL_HOST_STATUS GENMASK(11, 8) +#define DRBL_RSU_STATUSGENMASK(23, 16) +#define DRBL_PKVL_EEPROM_LOAD_SEC BIT(24) +#define DRBL_PKVL1_POLL_EN BIT(25) +#define DRBL_PKVL2_POLL_EN BIT(26) +#define DRBL_CONFIG_SELBIT(28) +#define DRBL_REBOOT_REQBIT(29) +#define DRBL_REBOOT_DISABLED BIT(30) + +/* Progress states */ +#define RSU_PROG_IDLE 0x0 +#define RSU_PROG_PREPARE 0x1 +#define RSU_PROG_READY 0x3 +#define RSU_PROG_AUTHENTICATING0x4 +#define RSU_PROG_COPYING 0x5 +#define RSU_PROG_UPDATE_CANCEL 0x6 +#define RSU_PROG_PROGRAM_KEY_HASH 0x7 +#define RSU_PROG_RSU_DONE 0x8 +#define RSU_PROG_PKVL_PROM_DONE0x9 + +/* Device and error states */ +#define RSU_STAT_NORMAL0x0 +#define RSU_STAT_TIMEOUT 0x1 +#define RSU_STAT_AUTH_FAIL 0x2 +#define RSU_STAT_COPY_FAIL 0x3 +#define RSU_STAT_FATAL 0x4 +#define RSU_STAT_PKVL_REJECT 0x5 +#define RSU_STAT_NON_INC 0x6 +#define RSU_STAT_ERASE_FAIL0x7 +#define RSU_STAT_WEAROUT 0x8 +#define RSU_STAT_NIOS_OK 0x80 +#define RSU_STAT_USER_OK 0x81 +#define RSU_STAT_FACTORY_OK0x82 +#define RSU_STAT_USER_FAIL 0x83 +#define RSU_STAT_FACTORY_FAIL 0x84 +#define RSU_STAT_NIOS_FLASH_ERR0x85 +#define RSU_STAT_FPGA_FLASH_ERR0x86 + +#define HOST_STATUS_IDLE 0x0 +#define HOST_STATUS_WRITE_DONE 0x1 +#define HOST_STATUS_ABORT_RSU 0x2 + +#define rsu_prog(doorbell) FIELD_GET(DRBL_RSU_PROGRESS, doorbell) +#define rsu_stat(doorbell) FIELD_GET(DRBL_RSU_STATUS, doorbell) + +/* interval 100ms and timeout 5s */ +#define NIOS_HANDSHAKE_INTERVAL_US (100 * 1000) +#define NIOS_HANDSHAKE_TIMEOUT_US (5 * 1000 * 1000) + +/* RSU PREP Timeout (2 minutes) to erase flash staging area */ +#define RSU_PREP_INTERVAL_MS 100 +#define RSU_PREP_TIMEOUT_MS(2 * 60 * 1000) + +/* RSU Complete Timeout (40 minutes) for full flash update */ +#define RSU_COMPLETE_INTERVAL_MS 1000 +#define RSU_COMPLETE_TIMEOUT_MS(40 * 60 * 1000) + +/* Addresses for security related data in FLASH */ +#define BMC_REH_ADDR 0x17ffc004 +#define BMC_PROG_ADDR 0x17ffc000 +#define BMC_PROG_MAGIC 0x5746 + +#define SR_REH_ADDR0x17ffd004 +#define SR_PROG_ADDR 0x17ffd000 +#define SR_PROG_MAGIC
Re: [PATCH V4 XRT Alveo 09/20] fpga: xrt: management physical function driver (root)
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 instantiation of group and platform
drivers is completely dtb driven.
Signed-off-by: Sonal Santan
Signed-off-by: Max Zhen
Signed-off-by: Lizhi Hou
---
drivers/fpga/xrt/mgmt/root.c | 333
+++
1 file changed, 333 insertions(+)
create mode 100644 drivers/fpga/xrt/mgmt/root.c
diff --git a/drivers/fpga/xrt/mgmt/root.c
b/drivers/fpga/xrt/mgmt/root.c
new file mode 100644
index ..f97f92807c01
--- /dev/null
+++ b/drivers/fpga/xrt/mgmt/root.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo Management Function Driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Cheng Zhen
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "xroot.h"
+#include "xmgnt.h"
+#include "metadata.h"
+
+#define XMGMT_MODULE_NAME "xrt-mgmt"
ok
+#define XMGMT_DRIVER_VERSION "4.0.0"
+
+#define XMGMT_PDEV(xm) ((xm)->pdev)
+#define XMGMT_DEV(xm) (&(XMGMT_PDEV(xm)->dev))
+#define xmgmt_err(xm, fmt, args...) \
+ dev_err(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define xmgmt_warn(xm, fmt, args...) \
+ dev_warn(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define xmgmt_info(xm, fmt, args...) \
+ dev_info(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define xmgmt_dbg(xm, fmt, args...) \
+ dev_dbg(XMGMT_DEV(xm), "%s: " fmt, __func__, ##args)
+#define XMGMT_DEV_ID(_pcidev) \
+ ({ typeof(_pcidev) (pcidev) = (_pcidev); \
+ ((pci_domain_nr((pcidev)->bus) << 16) | \
+ PCI_DEVID((pcidev)->bus->number, 0)); })
+
+static struct class *xmgmt_class;
+
+/* PCI Device IDs */
add a comment on what a golden image is here something like
/*
* Golden image is preloaded on the device when it is shipped to
customer.
* Then, customer can load other shells (from Xilinx or some other
vendor).
* If something goes wrong with the shell, customer can always go back to
* golden and start over again.
*/
Will do.
+#define PCI_DEVICE_ID_U50_GOLDEN 0xD020
+#define PCI_DEVICE_ID_U50 0x5020
+static const struct pci_device_id xmgmt_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_XILINX, PCI_DEVICE_ID_U50_GOLDEN),
}, /* Alveo U50 (golden) */
+ { PCI_DEVICE(PCI_VENDOR_ID_XILINX, PCI_DEVICE_ID_U50), }, /*
Alveo U50 */
+ { 0, }
+};
+
+struct xmgmt {
+ struct pci_dev *pdev;
+ void *root;
+
+ bool ready;
+};
+
+static int xmgmt_config_pci(struct xmgmt *xm)
+{
+ struct pci_dev *pdev = XMGMT_PDEV(xm);
+ int rc;
+
+ rc = pcim_enable_device(pdev);
+ if (rc < 0) {
+ xmgmt_err(xm, "failed to enable device: %d", rc);
+ return rc;
+ }
+
+ rc = pci_enable_pcie_error_reporting(pdev);
+ if (rc)
ok
+ xmgmt_warn(xm, "failed to enable AER: %d", rc);
+
+ pci_set_master(pdev);
+
+ rc = pcie_get_readrq(pdev);
+ if (rc > 512)
512 is magic number, change this to a #define
Will do.
+ pcie_set_readrq(pdev, 512);
+ return 0;
+}
+
+static int xmgmt_match_slot_and_save(struct device *dev, void *data)
+{
+ struct xmgmt *xm = data;
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (XMGMT_DEV_ID(pdev) == XMGMT_DEV_ID(xm->pdev)) {
+ pci_cfg_access_lock(pdev);
+ pci_save_state(pdev);
+ }
+
+ return 0;
+}
+
+static void xmgmt_pci_save_config_all(struct xmgmt *xm)
+{
+ bus_for_each_dev(_bus_type, NULL, xm,
xmgmt_match_slot_and_save);
refactor expected in v5 when pseudo bus change happens.
There might be some mis-understanding here...
No matter how we reorganize our code (using platform_device bus type
or defining our own bus type), it's a driver that drives a PCIE device
after all. So, this mgmt/root.c must be a PCIE driver, which may
interact with a whole bunch of IP drivers through a pseudo bus we are
about to create.
What this code is doing here is completely of PCIE business (PCIE
config space access). So, I think it is appropriate code in a PCIE
driver.
The PCIE device we are driving is a multi-function device. The mgmt pf
is of function 0, which, according to PCIE spec, can manage other
functions on the same device. So, I think it's appropriate for mgmt pf
driver (this root driver) to find it's peer function (through PCIE bus
type) on the same device and do something about it in certain special
cases.
Please let me know why you expect this code to be refactored and how
you want it to be refactored. I might have missed something here...
ok, i get it.
Re: [PATCH v2 2/2] hwmon: intel-m10-bmc-hwmon: add sensor support of Intel D5005 card
On 4/13/21 3:58 PM, matthew.gerl...@linux.intel.com wrote:
From: Matthew Gerlach
Like the Intel N3000 card, the Intel D5005 has a MAX10 based
BMC. This commit adds support for the D5005 sensors that are
monitored by the MAX10 BMC.
Signed-off-by: Matthew Gerlach
Signed-off-by: Russ Weight
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 files changed, 132 insertions(+)
diff --git a/drivers/hwmon/intel-m10-bmc-hwmon.c
b/drivers/hwmon/intel-m10-bmc-hwmon.c
index 17d5e6b..bd7ed2e 100644
--- a/drivers/hwmon/intel-m10-bmc-hwmon.c
+++ b/drivers/hwmon/intel-m10-bmc-hwmon.c
@@ -99,6 +99,50 @@ struct m10bmc_hwmon {
NULL
};
+static const struct m10bmc_sdata d5005bmc_temp_tbl[] = {
+ { 0x100, 0x104, 0x108, 0x10c, 0x0, 500, "Board Inlet Air Temperature" },
+ { 0x110, 0x114, 0x118, 0x0, 0x0, 500, "FPGA Core Temperature" },
+ { 0x11c, 0x120, 0x124, 0x128, 0x0, 500, "Board Exhaust Air Temperature"
},
+ { 0x12c, 0x130, 0x134, 0x0, 0x0, 500, "FPGA Transceiver Temperature" },
+ { 0x138, 0x13c, 0x140, 0x144, 0x0, 500, "RDIMM0 Temperature" },
+ { 0x148, 0x14c, 0x150, 0x154, 0x0, 500, "RDIMM1 Temperature" },
+ { 0x158, 0x15c, 0x160, 0x164, 0x0, 500, "RDIMM2 Temperature" },
+ { 0x168, 0x16c, 0x170, 0x174, 0x0, 500, "RDIMM3 Temperature" },
+ { 0x178, 0x17c, 0x180, 0x0, 0x0, 500, "QSFP0 Temperature" },
+ { 0x188, 0x18c, 0x190, 0x0, 0x0, 500, "QSFP1 Temperature" },
+ { 0x1a0, 0x1a4, 0x1a8, 0x0, 0x0, 500, "3.3v Temperature" },
+ { 0x1bc, 0x1c0, 0x1c4, 0x0, 0x0, 500, "VCCERAM Temperature" },
+ { 0x1d8, 0x1dc, 0x1e0, 0x0, 0x0, 500, "VCCR Temperature" },
+ { 0x1f4, 0x1f8, 0x1fc, 0x0, 0x0, 500, "VCCT Temperature" },
+ { 0x210, 0x214, 0x218, 0x0, 0x0, 500, "1.8v Temperature" },
+ { 0x22c, 0x230, 0x234, 0x0, 0x0, 500, "12v Backplane Temperature" },
+ { 0x248, 0x24c, 0x250, 0x0, 0x0, 500, "12v AUX Temperature" },
+};
+
+static const struct m10bmc_sdata d5005bmc_in_tbl[] = {
+ { 0x184, 0x0, 0x0, 0x0, 0x0, 1, "QSFP0 Supply Voltage" },
+ { 0x194, 0x0, 0x0, 0x0, 0x0, 1, "QSFP1 Supply Voltage" },
+ { 0x198, 0x0, 0x0, 0x0, 0x0, 1, "FPGA Core Voltage" },
+ { 0x1ac, 0x1b0, 0x1b4, 0x0, 0x0, 1, "3.3v Voltage" },
+ { 0x1c8, 0x1cc, 0x1d0, 0x0, 0x0, 1, "VCCERAM Voltage" },
+ { 0x1e4, 0x1e8, 0x1ec, 0x0, 0x0, 1, "VCCR Voltage" },
+ { 0x200, 0x204, 0x208, 0x0, 0x0, 1, "VCCT Voltage" },
+ { 0x21c, 0x220, 0x224, 0x0, 0x0, 1, "1.8v Voltage" },
+ { 0x238, 0x0, 0x0, 0x0, 0x23c, 1, "12v Backplane Voltage" },
+ { 0x254, 0x0, 0x0, 0x0, 0x258, 1, "12v AUX Voltage" },
+};
+
+static const struct m10bmc_sdata d5005bmc_curr_tbl[] = {
+ { 0x19c, 0x0, 0x0, 0x0, 0x0, 1, "FPGA Core Current" },
+ { 0x1b8, 0x0, 0x0, 0x0, 0x0, 1, "3.3v Current" },
+ { 0x1d4, 0x0, 0x0, 0x0, 0x0, 1, "VCCERAM Current" },
+ { 0x1f0, 0x0, 0x0, 0x0, 0x0, 1, "VCCR Current" },
+ { 0x20c, 0x0, 0x0, 0x0, 0x0, 1, "VCCT Current" },
+ { 0x228, 0x0, 0x0, 0x0, 0x0, 1, "1.8v Current" },
+ { 0x240, 0x244, 0x0, 0x0, 0x0, 1, "12v Backplane Current" },
+ { 0x25c, 0x260, 0x0, 0x0, 0x0, 1, "12v AUX Current" },
+};
+
static const struct m10bmc_hwmon_board_data n3000bmc_hwmon_bdata = {
.tables = {
[hwmon_temp] = n3000bmc_temp_tbl,
@@ -110,6 +154,80 @@ struct m10bmc_hwmon {
.hinfo = n3000bmc_hinfo,
};
+static const struct hwmon_channel_info *d5005bmc_hinfo[] = {
+ HWMON_CHANNEL_INFO(temp,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
+ HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_CRIT |
+ HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_LABEL,
+
Re: [PATCH v2 1/2] spi: Add DFL bus driver for Altera SPI Master
ned int val)
+{
+ struct dfl_altera_spi *aspi = context;
+ void __iomem *base = aspi->base;
+ int loops;
+
+ writeq(val, base + INDIRECT_WR_DATA);
+ writeq((reg >> 2) | INDIRECT_WR, base + INDIRECT_ADDR);
+
+ loops = 0;
+ while ((readq(base + INDIRECT_ADDR) & INDIRECT_WR) &&
+ (loops++ < INDIRECT_TIMEOUT))
+ cpu_relax();
+
+ if (loops >= INDIRECT_TIMEOUT) {
+ pr_err("%s timed out %d\n", __func__, loops);
+ return -ETIME;
+ }
+ return 0;
+}
+
+static const struct regmap_config indirect_regbus_cfg = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+ .max_register = 24,
+
+ .reg_write = indirect_bus_reg_write,
+ .reg_read = indirect_bus_reg_read,
+};
+
+static struct spi_board_info m10_bmc_info = {
+ .modalias = "m10-d5005",
+ .max_speed_hz = 1250,
+ .bus_num = 0,
+ .chip_select = 0,
+};
+
+static struct platform_device *create_cntrl(struct device *dev,
+ void __iomem *base,
+ struct spi_board_info *m10_info)
+{
could this function be inlined to probe ?
+ struct altera_spi_platform_data pdata;
+ struct platform_device_info pdevinfo;
+ u64 v;
+
+ v = readq(base + SPI_CORE_PARAMETER);
move down two lines to before the if-checks that use it
+
+ memset(, 0, sizeof(pdata));
+ pdata.mode_bits = SPI_CS_HIGH;
+ if (FIELD_GET(CLK_POLARITY, v))
+ pdata.mode_bits |= SPI_CPOL;
+ if (FIELD_GET(CLK_PHASE, v))
+ pdata.mode_bits |= SPI_CPHA;
+
+ pdata.num_chipselect = FIELD_GET(NUM_CHIPSELECT, v);
+ pdata.bits_per_word_mask =
+ SPI_BPW_RANGE_MASK(1, FIELD_GET(DATA_WIDTH, v));
+
+ pdata.num_devices = 1;
+ pdata.devices = m10_info;
+
+ dev_dbg(dev, "%s cs %u bpm 0x%x mode 0x%x\n", __func__,
+ pdata.num_chipselect, pdata.bits_per_word_mask,
+ pdata.mode_bits);
+
+ memset(, 0, sizeof(pdevinfo));
+
+ pdevinfo.name = "subdev_spi_altera";
+ pdevinfo.id = PLATFORM_DEVID_AUTO;
+ pdevinfo.parent = dev;
+ pdevinfo.data =
+ pdevinfo.size_data = sizeof(pdata);
+
+ return platform_device_register_full();
+}
+static int dfl_spi_altera_probe(struct dfl_device *dfl_dev)
+{
+ struct device *dev = _dev->dev;
+ struct dfl_altera_spi *aspi;
+
+ aspi = devm_kzalloc(dev, sizeof(*aspi), GFP_KERNEL);
+
+ if (!aspi)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, aspi);
+
+ aspi->dev = dev;
+
+ aspi->base = devm_ioremap_resource(dev, _dev->mmio_res);
+
+ if (IS_ERR(aspi->base)) {
+ dev_err(dev, "%s get mem resource fail!\n", __func__);
+ return PTR_ERR(aspi->base);
+ }
+
+ aspi->regmap = devm_regmap_init(dev, NULL, aspi, _regbus_cfg);
+ if (IS_ERR(aspi->regmap))
+ return PTR_ERR(aspi->regmap);
+
+ aspi->altr_spi = create_cntrl(dev, aspi->base, _bmc_info);
it does not seem like this can fail for device reasons. is there a
sanity check on the reg values that could be done ?
Tom
+
+ if (IS_ERR(aspi->altr_spi)) {
+ dev_err(dev, "%s failed to create spi platform driver\n",
+ __func__);
+ return PTR_ERR(aspi->base);
+ }
+
+ return 0;
+}
+
+static void dfl_spi_altera_remove(struct dfl_device *dfl_dev)
+{
+ struct dfl_altera_spi *aspi = dev_get_drvdata(_dev->dev);
+
+ platform_device_unregister(aspi->altr_spi);
+}
+
+#define FME_FEATURE_ID_MAX10_SPI0xe
+
+static const struct dfl_device_id dfl_spi_altera_ids[] = {
+ { FME_ID, FME_FEATURE_ID_MAX10_SPI },
+ { }
+};
+
+static struct dfl_driver dfl_spi_altera_driver = {
+ .drv= {
+ .name = "dfl-spi-altera",
+ },
+ .id_table = dfl_spi_altera_ids,
+ .probe = dfl_spi_altera_probe,
+ .remove = dfl_spi_altera_remove,
+};
+
+module_dfl_driver(dfl_spi_altera_driver);
+
+MODULE_DEVICE_TABLE(dfl, dfl_spi_altera_ids);
+MODULE_DESCRIPTION("DFL spi altera driver");
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL v2");
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
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 issued RO. The mlx5 ethernet driver has run in RO mode for a long time, and it operates in basically the same way as RDMA. The issues with Haswell have been worked out there already. The only open question is if the ULPs have errors in their implementation, which I don't think we can find out until we apply this series and people start running their tests aggressively. I agree that the core RO support should go in. But turning it on by default for a ULP should be the decision of each ULP maintainer. It's a huge risk to shift all the storage drivers overnight. How do you propose to ensure the aggressive testing happens? One thing that worries me is the patch02 on-by-default for the dma_lkey. There's no way for a ULP to prevent IB_ACCESS_RELAXED_ORDERING from being set in __ib_alloc_pd(). Tom.
Re: [PATCH] fpga: xilinx-pr-decoupler: remove useless function
On 4/12/21 8:51 PM, Jiapeng Chong wrote:
Fix the following gcc warning:
drivers/fpga/xilinx-pr-decoupler.c:32:19: warning: unused function
'xlnx_pr_decouple_read' [-Wunused-function].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/fpga/xilinx-pr-decoupler.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/fpga/xilinx-pr-decoupler.c
b/drivers/fpga/xilinx-pr-decoupler.c
index 7d69af2..f407cb2 100644
--- a/drivers/fpga/xilinx-pr-decoupler.c
+++ b/drivers/fpga/xilinx-pr-decoupler.c
@@ -29,12 +29,6 @@ static inline void xlnx_pr_decoupler_write(struct
xlnx_pr_decoupler_data *d,
writel(val, d->io_base + offset);
}
-static inline u32 xlnx_pr_decouple_read(const struct xlnx_pr_decoupler_data *d,
- u32 offset)
-{
- return readl(d->io_base + offset);
-}
-
I am not in favor 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_decoupler_enable_set(struct fpga_bridge *bridge, bool
enable)
{
int err;
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
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: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 positive correctness testing results can be replicated on a variety of platforms. RO has been rolling out slowly on mlx5 over a few years and storage ULPs are the last to change. eg the mlx5 ethernet driver has had RO turned on for a long time, userspace HPC applications have been using it for a while now too. I'd love to see RO be used more, it was always something the RDMA specs supported and carefully architected for. My only concern is that it's difficult to get right, especially when the platforms have been running strictly-ordered for so long. The ULPs need testing, and a lot of it. We know there are platforms with broken RO implementations (like Haswell) but the kernel is supposed to globally turn off RO on all those cases. I'd be a bit surprised if we discover any more from this series. On the other hand there are platforms that get huge speed ups from turning this on, AMD is one example, there are a bunch in the ARM world too. 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). The RO pipeline will completely reorder DMA writes, and consumers which infer ordering from memory contents may break. This can even apply within the provider code, which may attempt to poll WR and CQ structures, and be tripped up. You are referring specifically to RPC/RDMA depending on Receive completions to guarantee that previous RDMA Writes have been retired? Or is there a particular implementation practice in the Linux RPC/RDMA code that worries you? Nothing in the RPC/RDMA code, which is IMO correct. The worry, which is hopefully unfounded, is that the RO pipeline might not have flushed when a completion is posted *after* posting an interrupt. Something like this... RDMA Write arrives PCIe RO Write for data PCIe RO Write for data ... RDMA Write arrives PCIe RO Write for data ... RDMA Send arrives PCIe RO Write for receive data PCIe RO Write for receive descriptor Do you mean the Write of the CQE? It has to be Strongly Ordered for a correct implementation. Then it will shure prior written RO date has global visibility when the CQE can be observed. I wasn't aware that a strongly-ordered PCIe Write will ensure that prior relaxed-ordered writes went first. If that's the case, I'm fine with it - as long as the providers are correctly coded!! The PCIe spec (Table Ordering Rules Summary) is quite clear here (A Posted request is Memory Write Request in this context): A Posted Request must not pass another Posted Request unless A2b applies. A2b: A Posted Request with RO Set is permitted to pass another Posted Request. Thxs, Håkon Ok, good - a non-RO write (for example, to a CQE), or an interrupt (which would be similarly non-RO), will "get behind" all prior writes. 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 issued RO. Honestly, the Haswell sounds like a great first candidate, because if it has a known-broken RO behavior, verifying that it works with this change is highly important. I'd have greater confidence in newer platforms, in other words. They *all* have to work, proveably. Tom. I remember trying to read the relevant section of the PCIe spec. (Possibly in a book that was trying to make it easier to understand!) It is about as clear as mud. I presume this is all about allowing PCIe targets (eg ethernet cards) to use relaxed ordering on write requests to host memory. And that such writes can be completed out of order? It isn't entirely clear that you aren't talking of letting the cpu do 'relaxed order' writes to PCIe targets! For a typical ethernet driver the receive interrupt just means 'go and look at the receive descriptor ring'. So there is an absolute requirement that the writes for data buffer complete before the write to the receive descriptor. There is no requirement for the interrupt (requested after the descriptor write) to have been seen by the cpu. Quite often the driver will find the 'receive complete' descriptor when processing frames from an earlier interrupt (and nothing to do in response to the interrupt itself). So the write to the receive descriptor would have to have RO clear to ensure that all the buffer writes comp
Re: [PATCH] MIPS: generic: Update node names to avoid unit addresses
On Fri, Apr 09, 2021 at 12:21:28PM -0700, Nathan Chancellor wrote: > With the latest mkimage from U-Boot 2021.04, the generic defconfigs no > longer build, failing with: > > /usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1 > > This is expected after the linked U-Boot commits because '@' is > forbidden in the node names due to the way that libfdt treats nodes with > the same prefix but different unit addresses. > > Switch the '@' in the node name to '-'. Drop the unit addresses from the > hash and kernel child nodes because there is only one node so they do > not need to have a number to differentiate them. > > Cc: sta...@vger.kernel.org > Link: > https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4 > Link: > https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917 > Suggested-by: Simon Glass > Signed-off-by: Nathan Chancellor Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
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: We need to get a better idea what correctness testing has been done, and whether positive correctness testing results can be replicated on a variety of platforms. RO has been rolling out slowly on mlx5 over a few years and storage ULPs are the last to change. eg the mlx5 ethernet driver has had RO turned on for a long time, userspace HPC applications have been using it for a while now too. I'd love to see RO be used more, it was always something the RDMA specs supported and carefully architected for. My only concern is that it's difficult to get right, especially when the platforms have been running strictly-ordered for so long. The ULPs need testing, and a lot of it. We know there are platforms with broken RO implementations (like Haswell) but the kernel is supposed to globally turn off RO on all those cases. I'd be a bit surprised if we discover any more from this series. On the other hand there are platforms that get huge speed ups from turning this on, AMD is one example, there are a bunch in the ARM world too. 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). The RO pipeline will completely reorder DMA writes, and consumers which infer ordering from memory contents may break. This can even apply within the provider code, which may attempt to poll WR and CQ structures, and be tripped up. You are referring specifically to RPC/RDMA depending on Receive completions to guarantee that previous RDMA Writes have been retired? Or is there a particular implementation practice in the Linux RPC/RDMA code that worries you? Nothing in the RPC/RDMA code, which is IMO correct. The worry, which is hopefully unfounded, is that the RO pipeline might not have flushed when a completion is posted *after* posting an interrupt. Something like this... RDMA Write arrives PCIe RO Write for data PCIe RO Write for data ... RDMA Write arrives PCIe RO Write for data ... RDMA Send arrives PCIe RO Write for receive data PCIe RO Write for receive descriptor Do you mean the Write of the CQE? It has to be Strongly Ordered for a correct implementation. Then it will shure prior written RO date has global visibility when the CQE can be observed. I wasn't aware that a strongly-ordered PCIe Write will ensure that prior relaxed-ordered writes went first. If that's the case, I'm fine with it - as long as the providers are correctly coded!! PCIe interrupt (flushes RO pipeline for all three ops above) Before the interrupt, the HCA will write the EQE (Event Queue Entry). This has to be a Strongly Ordered write to "push" prior written CQEs so that when the EQE is observed, the prior writes of CQEs have global visibility. And the MSI-X write likewise, to avoid spurious interrupts. Ok, and yes agreed the same principle would apply. Is there any implication if a PCIe switch were present on the motherboard? The switch is allowed to do some creative routing if the operation is relaxed, correct? Tom. Thxs, Håkon RPC/RDMA polls CQ Reaps receive completion RDMA Send arrives PCIe RO Write for receive data PCIe RO write for receive descriptor Does *not* interrupt, since CQ not armed RPC/RDMA continues to poll CQ Reaps receive completion PCIe RO writes not yet flushed Processes incomplete in-memory data Bzzzt Hopefully, the adapter performs a PCIe flushing read, or something to avoid this when an interrupt is not generated. Alternatively, I'm overly paranoid. Tom. The Mellanox adapter, itself, historically has strict in-order DMA semantics, and while it's great to relax that, changing it by default for all consumers is something to consider very cautiously. Still, obviously people 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. I agree that data integrity comes first. Since I currently don't have facilities to test RO in my lab, the community will have to agree on a set of tests and expected results that specifically exercise the corner cases you are concerned about. -- Chuck Lever
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
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 this in the kernel. All kernel ULPs only read data after they observe the CQE. We do not have "last data polling" and our interrupt model does not support some hacky "interrupt means go and use the data" approach. ULPs have to be designed this way to use the DMA API properly. Yep. Totally agree. My concern was about the data being written as relaxed, and the CQE racing it. I'll reply in the other fork. Fencing a DMA before it is completed by the HW will cause IOMMU errors. Userspace is a different story, but that will remain as-is with optional relaxed ordering. Jason
Re: [PATCH v3] KVM: SVM: Make sure GHCB is mapped before updating
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_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 might not be mapped (depending on the previous VMEXIT),
> which will result in a NULL pointer dereference.
>
> The svm_complete_emulated_msr() routine will update the GHCB to inform
> the caller of a RDMSR/WRMSR operation about any errors. While it is likely
> that the GHCB will be mapped in this situation, add a safe guard
> in this path to be certain a NULL pointer dereference is not encountered.
>
> Fixes: f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts
> under SEV-ES")
> Fixes: 647daca25d24 ("KVM: SVM: Add support for booting APs in an SEV-ES
> guest")
> Signed-off-by: Tom Lendacky
>
> ---
>
> Changes from v2:
> - Removed WARN_ON_ONCE() from the sev_vcpu_deliver_sipi_vector() path
> since it is guest triggerable and can crash systems with panic_on_warn
> and replaced with pr_warn_once().
I messed up the change-log here, the WARN_ON_ONCE() was dropped and *not*
replaced with a pr_warn_once().
Thanks,
Tom
>
> Changes from v1:
> - Added the svm_complete_emulated_msr() path as suggested by Sean
> Christopherson
> - Add a WARN_ON_ONCE() to the sev_vcpu_deliver_sipi_vector() path
> ---
> arch/x86/kvm/svm/sev.c | 3 +++
> arch/x86/kvm/svm/svm.c | 2 +-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 83e00e524513..0a539f8bc212 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu
> *vcpu, u8 vector)
>* the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a
>* non-zero value.
>*/
> + if (!svm->ghcb)
> + return;
> +
> ghcb_set_sw_exit_info_2(svm->ghcb, 1);
> }
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 271196400495..534e52ba6045 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -2759,7 +2759,7 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
> static int svm_complete_emulated_msr(struct kvm_vcpu *vcpu, int err)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
> - if (!sev_es_guest(vcpu->kvm) || !err)
> + if (!err || !sev_es_guest(vcpu->kvm) || WARN_ON_ONCE(!svm->ghcb))
> return kvm_complete_insn_gp(vcpu, err);
>
> ghcb_set_sw_exit_info_1(svm->ghcb, 1);
>
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
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 positive correctness testing results can be replicated on a variety of platforms. RO has been rolling out slowly on mlx5 over a few years and storage ULPs are the last to change. eg the mlx5 ethernet driver has had RO turned on for a long time, userspace HPC applications have been using it for a while now too. I'd love to see RO be used more, it was always something the RDMA specs supported and carefully architected for. My only concern is that it's difficult to get right, especially when the platforms have been running strictly-ordered for so long. The ULPs need testing, and a lot of it. We know there are platforms with broken RO implementations (like Haswell) but the kernel is supposed to globally turn off RO on all those cases. I'd be a bit surprised if we discover any more from this series. On the other hand there are platforms that get huge speed ups from turning this on, AMD is one example, there are a bunch in the ARM world too. 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). The RO pipeline will completely reorder DMA writes, and consumers which infer ordering from memory contents may break. This can even apply within the provider code, which may attempt to poll WR and CQ structures, and be tripped up. You are referring specifically to RPC/RDMA depending on Receive completions to guarantee that previous RDMA Writes have been retired? Or is there a particular implementation practice in the Linux RPC/RDMA code that worries you? Nothing in the RPC/RDMA code, which is IMO correct. The worry, which is hopefully unfounded, is that the RO pipeline might not have flushed when a completion is posted *after* posting an interrupt. Something like this... RDMA Write arrives PCIe RO Write for data PCIe RO Write for data ... RDMA Write arrives PCIe RO Write for data ... RDMA Send arrives PCIe RO Write for receive data PCIe RO Write for receive descriptor PCIe interrupt (flushes RO pipeline for all three ops above) RPC/RDMA polls CQ Reaps receive completion RDMA Send arrives PCIe RO Write for receive data PCIe RO write for receive descriptor Does *not* interrupt, since CQ not armed RPC/RDMA continues to poll CQ Reaps receive completion PCIe RO writes not yet flushed Processes incomplete in-memory data Bzzzt Hopefully, the adapter performs a PCIe flushing read, or something to avoid this when an interrupt is not generated. Alternatively, I'm overly paranoid. Tom. The Mellanox adapter, itself, historically has strict in-order DMA semantics, and while it's great to relax that, changing it by default for all consumers is something to consider very cautiously. Still, obviously people 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. I agree that data integrity comes first. Since I currently don't have facilities to test RO in my lab, the community will have to agree on a set of tests and expected results that specifically exercise the corner cases you are concerned about. -- Chuck Lever
Re: [PATCH v2] KVM: SVM: Make sure GHCB is mapped before updating
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: >>>>> On Thu, Apr 08, 2021, Tom Lendacky wrote: >>>>>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c >>>>>> index 83e00e524513..7ac67615c070 100644 >>>>>> --- a/arch/x86/kvm/svm/sev.c >>>>>> +++ b/arch/x86/kvm/svm/sev.c >>>>>> @@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu >>>>>> *vcpu, u8 vector) >>>>>> * the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a >>>>>> * non-zero value. >>>>>> */ >>>>>> +if (WARN_ON_ONCE(!svm->ghcb)) >>>>> >>>>> Isn't this guest triggerable? I.e. send a SIPI without doing the reset >>>>> hold? >>>>> If so, this should not WARN. >>>> >>>> Yes, it is a guest triggerable event. But a guest shouldn't be doing that, >>>> so I thought adding the WARN_ON_ONCE() just to detect it wasn't bad. >>>> Definitely wouldn't want a WARN_ON(). >>> >>> WARNs are intended only for host issues, e.g. a malicious guest shouldn't be >>> able to crash the host when running with panic_on_warn. >>> >> >> Ah, yeah, forgot about panic_on_warn. I can go back to the original patch >> or do a pr_warn_once(), any pref? > > No strong preference. If you think the print would be helpful for ongoing > development, then it's probably worth adding. For development, I'd want to see it all the time. But since it is guest triggerable, the _once() method is really needed in production. So in the latest version I just dropped the message/notification. Thanks, Tom >
[PATCH v3] KVM: SVM: Make sure GHCB is mapped before updating
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 NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB might not be mapped (depending on the previous VMEXIT),
which will result in a NULL pointer dereference.
The svm_complete_emulated_msr() routine will update the GHCB to inform
the caller of a RDMSR/WRMSR operation about any errors. While it is likely
that the GHCB will be mapped in this situation, add a safe guard
in this path to be certain a NULL pointer dereference is not encountered.
Fixes: f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts
under SEV-ES")
Fixes: 647daca25d24 ("KVM: SVM: Add support for booting APs in an SEV-ES guest")
Signed-off-by: Tom Lendacky
---
Changes from v2:
- Removed WARN_ON_ONCE() from the sev_vcpu_deliver_sipi_vector() path
since it is guest triggerable and can crash systems with panic_on_warn
and replaced with pr_warn_once().
Changes from v1:
- Added the svm_complete_emulated_msr() path as suggested by Sean
Christopherson
- Add a WARN_ON_ONCE() to the sev_vcpu_deliver_sipi_vector() path
---
arch/x86/kvm/svm/sev.c | 3 +++
arch/x86/kvm/svm/svm.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 83e00e524513..0a539f8bc212 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu,
u8 vector)
* the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a
* non-zero value.
*/
+ if (!svm->ghcb)
+ return;
+
ghcb_set_sw_exit_info_2(svm->ghcb, 1);
}
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 271196400495..534e52ba6045 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2759,7 +2759,7 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
static int svm_complete_emulated_msr(struct kvm_vcpu *vcpu, int err)
{
struct vcpu_svm *svm = to_svm(vcpu);
- if (!sev_es_guest(vcpu->kvm) || !err)
+ if (!err || !sev_es_guest(vcpu->kvm) || WARN_ON_ONCE(!svm->ghcb))
return kvm_complete_insn_gp(vcpu, err);
ghcb_set_sw_exit_info_1(svm->ghcb, 1);
--
2.31.0
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
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 positive correctness testing results can be replicated on a variety of platforms. RO has been rolling out slowly on mlx5 over a few years and storage ULPs are the last to change. eg the mlx5 ethernet driver has had RO turned on for a long time, userspace HPC applications have been using it for a while now too. I'd love to see RO be used more, it was always something the RDMA specs supported and carefully architected for. My only concern is that it's difficult to get right, especially when the platforms have been running strictly-ordered for so long. The ULPs need testing, and a lot of it. We know there are platforms with broken RO implementations (like Haswell) but the kernel is supposed to globally turn off RO on all those cases. I'd be a bit surprised if we discover any more from this series. On the other hand there are platforms that get huge speed ups from turning this on, AMD is one example, there are a bunch in the ARM world too. 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). The RO pipeline will completely reorder DMA writes, and consumers which infer ordering from memory contents may break. This can even apply within the provider code, which may attempt to poll WR and CQ structures, and be tripped up. The Mellanox adapter, itself, historically has strict in-order DMA semantics, and while it's great to relax that, changing it by default for all consumers is something to consider very cautiously. Still, obviously people 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.
Re: [PATCH v2] KVM: SVM: Make sure GHCB is mapped before updating
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 >>>> index 83e00e524513..7ac67615c070 100644 >>>> --- a/arch/x86/kvm/svm/sev.c >>>> +++ b/arch/x86/kvm/svm/sev.c >>>> @@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu >>>> *vcpu, u8 vector) >>>> * the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a >>>> * non-zero value. >>>> */ >>>> + if (WARN_ON_ONCE(!svm->ghcb)) >>> >>> Isn't this guest triggerable? I.e. send a SIPI without doing the reset >>> hold? >>> If so, this should not WARN. >> >> Yes, it is a guest triggerable event. But a guest shouldn't be doing that, >> so I thought adding the WARN_ON_ONCE() just to detect it wasn't bad. >> Definitely wouldn't want a WARN_ON(). > > WARNs are intended only for host issues, e.g. a malicious guest shouldn't be > able to crash the host when running with panic_on_warn. > Ah, yeah, forgot about panic_on_warn. I can go back to the original patch or do a pr_warn_once(), any pref? Thanks, Tom
Re: [PATCH v2] KVM: SVM: Make sure GHCB is mapped before updating
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 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 NAE event that a SIPI has been delivered.
>> However, if a SIPI is performed without a corresponding AP Reset Hold,
>> then the GHCB might not be mapped (depending on the previous VMEXIT),
>> which will result in a NULL pointer dereference.
>>
>> The svm_complete_emulated_msr() routine will update the GHCB to inform
>> the caller of a RDMSR/WRMSR operation about any errors. While it is likely
>> that the GHCB will be mapped in this situation, add a safe guard
>> in this path to be certain a NULL pointer dereference is not encountered.
>>
>> Fixes: f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts
>> under SEV-ES")
>> Fixes: 647daca25d24 ("KVM: SVM: Add support for booting APs in an SEV-ES
>> guest")
>> Signed-off-by: Tom Lendacky
>>
>> ---
>>
>> Changes from v1:
>> - Added the svm_complete_emulated_msr() path as suggested by Sean
>> Christopherson
>> - Add a WARN_ON_ONCE() to the sev_vcpu_deliver_sipi_vector() path
>> ---
>> arch/x86/kvm/svm/sev.c | 3 +++
>> arch/x86/kvm/svm/svm.c | 2 +-
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>> index 83e00e524513..7ac67615c070 100644
>> --- a/arch/x86/kvm/svm/sev.c
>> +++ b/arch/x86/kvm/svm/sev.c
>> @@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu
>> *vcpu, u8 vector)
>> * the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a
>> * non-zero value.
>> */
>> +if (WARN_ON_ONCE(!svm->ghcb))
>
> Isn't this guest triggerable? I.e. send a SIPI without doing the reset hold?
> If so, this should not WARN.
Yes, it is a guest triggerable event. But a guest shouldn't be doing that,
so I thought adding the WARN_ON_ONCE() just to detect it wasn't bad.
Definitely wouldn't want a WARN_ON().
Thanks,
Tom
>
>> +return;
>> +
>> ghcb_set_sw_exit_info_2(svm->ghcb, 1);
>> }
>> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
>> index 271196400495..534e52ba6045 100644
>> --- a/arch/x86/kvm/svm/svm.c
>> +++ b/arch/x86/kvm/svm/svm.c
>> @@ -2759,7 +2759,7 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
>> msr_data *msr_info)
>> static int svm_complete_emulated_msr(struct kvm_vcpu *vcpu, int err)
>> {
>> struct vcpu_svm *svm = to_svm(vcpu);
>> -if (!sev_es_guest(vcpu->kvm) || !err)
>> +if (!err || !sev_es_guest(vcpu->kvm) || WARN_ON_ONCE(!svm->ghcb))
>> return kvm_complete_insn_gp(vcpu, err);
>>
>> ghcb_set_sw_exit_info_1(svm->ghcb, 1);
>> --
>> 2.31.0
>>
Re: [PATCH 1/1] x86/kvm/svm: Implement support for PSFD
On 4/7/21 2:45 PM, Ramakrishna Saripalli wrote: > From: Ramakrishna Saripalli > > Expose Predictive Store Forwarding capability to guests. > Guests enable or disable PSF via SPEC_CTRL MSR. > > Signed-off-by: Ramakrishna Saripalli > --- > arch/x86/kvm/cpuid.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 6bd2f8b830e4..9c4af0fef6d7 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -448,6 +448,8 @@ void kvm_set_cpu_caps(void) > kvm_cpu_cap_set(X86_FEATURE_INTEL_STIBP); > if (boot_cpu_has(X86_FEATURE_AMD_SSBD)) > kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD); > + if (boot_cpu_has(X86_FEATURE_AMD_PSFD)) > + kvm_cpu_cap_set(X86_FEATURE_AMD_PSFD); > > kvm_cpu_cap_mask(CPUID_7_1_EAX, > F(AVX_VNNI) | F(AVX512_BF16) > @@ -482,7 +484,7 @@ void kvm_set_cpu_caps(void) > kvm_cpu_cap_mask(CPUID_8000_0008_EBX, > F(CLZERO) | F(XSAVEERPTR) | > F(WBNOINVD) | F(AMD_IBPB) | F(AMD_IBRS) | F(AMD_SSBD) | > 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 > ); > > /* >
[PATCH v2] KVM: SVM: Make sure GHCB is mapped before updating
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 NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB might not be mapped (depending on the previous VMEXIT),
which will result in a NULL pointer dereference.
The svm_complete_emulated_msr() routine will update the GHCB to inform
the caller of a RDMSR/WRMSR operation about any errors. While it is likely
that the GHCB will be mapped in this situation, add a safe guard
in this path to be certain a NULL pointer dereference is not encountered.
Fixes: f1c6366e3043 ("KVM: SVM: Add required changes to support intercepts
under SEV-ES")
Fixes: 647daca25d24 ("KVM: SVM: Add support for booting APs in an SEV-ES guest")
Signed-off-by: Tom Lendacky
---
Changes from v1:
- Added the svm_complete_emulated_msr() path as suggested by Sean
Christopherson
- Add a WARN_ON_ONCE() to the sev_vcpu_deliver_sipi_vector() path
---
arch/x86/kvm/svm/sev.c | 3 +++
arch/x86/kvm/svm/svm.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 83e00e524513..7ac67615c070 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu,
u8 vector)
* the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a
* non-zero value.
*/
+ if (WARN_ON_ONCE(!svm->ghcb))
+ return;
+
ghcb_set_sw_exit_info_2(svm->ghcb, 1);
}
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 271196400495..534e52ba6045 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2759,7 +2759,7 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
static int svm_complete_emulated_msr(struct kvm_vcpu *vcpu, int err)
{
struct vcpu_svm *svm = to_svm(vcpu);
- if (!sev_es_guest(vcpu->kvm) || !err)
+ if (!err || !sev_es_guest(vcpu->kvm) || WARN_ON_ONCE(!svm->ghcb))
return kvm_complete_insn_gp(vcpu, err);
ghcb_set_sw_exit_info_1(svm->ghcb, 1);
--
2.31.0
Re: [PATCH] KVM: SVM: Make sure GHCB is mapped before updating
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 get the right >>>> result, but get a stack trace immediately. >>> Doh, yep. >> Actually, because of the "or's", this needs to be: >> >> if (!err || !sev_es_guest(vcpu->kvm) || (sev_es_guest(vcpu->kvm) && >> WARN_ON_ONCE(!svm->ghcb))) > > No, || cuts the right-hand side if the left-hand side is true. So: > > - if err == 0, the rest is not evaluated > > - if !sev_es_guest(vcpu->kvm), WARN_ON_ONCE(!svm->ghcb) is not evaluated That's what I was doing in my head, but I guess I need more coffee... :) Thanks, Tom > > Paolo >
Re: [PATCH] KVM: SVM: Make sure GHCB is mapped before updating
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_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 NULL pointer
>>>> dereference.
>>>>
>>>> Check that the GHCB is mapped before attempting the update.
>>>
>>> It's tempting to say the ghcb_set_*() helpers should guard against this, but
>>> that would add a lot of pollution and the vast majority of uses are very
>>> clearly
>>> in the vmgexit path. svm_complete_emulated_msr() is the only other case
>>> that
>>> is non-obvious; would it make sense to sanity check svm->ghcb there as well?
>>
>> Hmm... I'm not sure if we can get here without having taken the VMGEXIT
>> path to start, but it certainly couldn't hurt to add it.
>
> Yeah, AFAICT it should be impossible to reach the callback without a valid
> ghcb,
> it'd be purely be a sanity check.
>
>> I can submit a v2 with that unless you want to submit it (with one small
>> change below).
>
> I'd say just throw it into v2.
>
>>> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
>>> index 019ac836dcd0..abe9c765628f 100644
>>> --- a/arch/x86/kvm/svm/svm.c
>>> +++ b/arch/x86/kvm/svm/svm.c
>>> @@ -2728,7 +2728,8 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
>>> msr_data *msr_info)
>>> static int svm_complete_emulated_msr(struct kvm_vcpu *vcpu, int err)
>>> {
>>> struct vcpu_svm *svm = to_svm(vcpu);
>>> - if (!sev_es_guest(vcpu->kvm) || !err)
>>> +
>>> + if (!err || !sev_es_guest(vcpu->kvm) || !WARN_ON_ONCE(svm->ghcb))
>>
>> This should be WARN_ON_ONCE(!svm->ghcb), otherwise you'll get the right
>> result, but get a stack trace immediately.
>
> Doh, yep.
Actually, because of the "or's", this needs to be:
if (!err || !sev_es_guest(vcpu->kvm) || (sev_es_guest(vcpu->kvm) &&
WARN_ON_ONCE(!svm->ghcb)))
Thanks,
Tom
>
Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate the memory used for the GHCB
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's own reason code set with some more specific reason codes for >>> failures, if that is needed. >> >> Why Linux only? >> >> Don't we want to have a generalized set of error codes which say what >> has happened so that people can debug? > > To quote Tom from IRC - and that is perfectly fine too, AFAIC: > > i'm ok with it, but i don't think it should be something dictated > by the spec. the problem is if you want to provide a new error code then the > spec has to be updated constantly > that's why i said, pick a "reason code set" value and say those > are what Linux will use. We could probably document them in Documentation/ > the error code thing was an issue when introduced as part of the > first spec. that's why only a small number of reason codes are specified > > Yap, makes sense. What we should do in the spec, though, is say: "This > range is for vendor-specific error codes". > > Also, is GHCBData[23:16] big enough and can we extend it simply? Or do > we need the spec to at least dictate some ranges so that it can use some bits > above, say, bit 32 or whatever the upper range of the extension is... Hopefully we won't have 255 different reason codes. But if we get to that point we should be able to expand the reason code field to 16-bits. Just need to be sure that if any new fields are added between now and then, they are added at bit 32 or above. Thanks, Tom > > Hmmm. >
Re: [PATCH] KVM: SVM: Make sure GHCB is mapped before updating
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 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 NULL pointer
>> dereference.
>>
>> Check that the GHCB is mapped before attempting the update.
>
> It's tempting to say the ghcb_set_*() helpers should guard against this, but
> that would add a lot of pollution and the vast majority of uses are very
> clearly
> in the vmgexit path. svm_complete_emulated_msr() is the only other case that
> is non-obvious; would it make sense to sanity check svm->ghcb there as well?
Hmm... I'm not sure if we can get here without having taken the VMGEXIT
path to start, but it certainly couldn't hurt to add it.
I can submit a v2 with that unless you want to submit it (with one small
change below).
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 019ac836dcd0..abe9c765628f 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -2728,7 +2728,8 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
> msr_data *msr_info)
> static int svm_complete_emulated_msr(struct kvm_vcpu *vcpu, int err)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
> - if (!sev_es_guest(vcpu->kvm) || !err)
> +
> + if (!err || !sev_es_guest(vcpu->kvm) || !WARN_ON_ONCE(svm->ghcb))
This should be WARN_ON_ONCE(!svm->ghcb), otherwise you'll get the right
result, but get a stack trace immediately.
Thanks,
Tom
> return kvm_complete_insn_gp(vcpu, err);
>
> ghcb_set_sw_exit_info_1(svm->ghcb, 1);
>
>> Fixes: 647daca25d24 ("KVM: SVM: Add support for booting APs in an SEV-ES
>> guest")
>> Signed-off-by: Tom Lendacky
>
> Either way:
>
> Reviewed-by: Sean Christopherson
>
>> ---
>> arch/x86/kvm/svm/sev.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>> index 83e00e524513..13758e3b106d 100644
>> --- a/arch/x86/kvm/svm/sev.c
>> +++ b/arch/x86/kvm/svm/sev.c
>> @@ -2105,5 +2105,6 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu
>> *vcpu, u8 vector)
>> * the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a
>> * non-zero value.
>> */
>> -ghcb_set_sw_exit_info_2(svm->ghcb, 1);
>> +if (svm->ghcb)
>> +ghcb_set_sw_exit_info_2(svm->ghcb, 1);
>> }
>> --
>> 2.31.0
>>
[PATCH] KVM: SVM: Make sure GHCB is mapped before updating
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 NULL pointer
dereference.
Check that the GHCB is mapped before attempting the update.
Fixes: 647daca25d24 ("KVM: SVM: Add support for booting APs in an SEV-ES guest")
Signed-off-by: Tom Lendacky
---
arch/x86/kvm/svm/sev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 83e00e524513..13758e3b106d 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2105,5 +2105,6 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu *vcpu,
u8 vector)
* the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a
* non-zero value.
*/
- ghcb_set_sw_exit_info_2(svm->ghcb, 1);
+ if (svm->ghcb)
+ ghcb_set_sw_exit_info_2(svm->ghcb, 1);
}
--
2.31.0
Re: [PATCH v2 0/8] ccp: KVM: SVM: Use stack for SEV command buffers
On 4/6/21 5:49 PM, Sean Christopherson wrote:
> This series teaches __sev_do_cmd_locked() to gracefully handle vmalloc'd
> command buffers by copying _all_ incoming data pointers to an internal
> buffer before sending the command to the PSP. The SEV driver and KVM are
> then converted to use the stack for all command buffers.
>
> Tested everything except sev_ioctl_do_pek_import(), I don't know anywhere
> near enough about the PSP to give it the right input.
>
> v2:
> - Rebase to kvm/queue, commit f96be2deac9b ("KVM: x86: Support KVM VMs
> sharing SEV context").
> - Unconditionally copy @data to the internal buffer. [Christophe, Brijesh]
> - Allocate a full page for the buffer. [Brijesh]
> - Drop one set of the "!"s. [Christophe]
> - Use virt_addr_valid() instead of is_vmalloc_addr() for the temporary
> 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 driver
> framework). But it felt wrong to not free cmd_buf on failure, and
> even more wrong to free cmd_buf but not sev.
>
> v1:
> -
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.kernel.org%2Fr%2F20210402233702.3291792-1-seanjc%40google.comdata=04%7C01%7Cthomas.lendacky%40amd.com%7Cecd38fba67954845323908d8f94e5405%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533462102772796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=SUN8Zp%2Fi%2BiHAjMSe%2Fjwvs9JmXg%2FRvi%2B8j01sLDipPg8%3Dreserved=0
>
> Sean Christopherson (8):
> crypto: ccp: Free SEV device if SEV init fails
> crypto: ccp: Detect and reject "invalid" addresses destined for PSP
> crypto: ccp: Reject SEV commands with mismatching command buffer
> crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> crypto: ccp: Use the stack for small SEV command buffers
> crypto: ccp: Use the stack and common buffer for status commands
> crypto: ccp: Use the stack and common buffer for INIT command
> KVM: SVM: Allocate SEV command structures on local stack
>
> arch/x86/kvm/svm/sev.c | 262 +--
> drivers/crypto/ccp/sev-dev.c | 197 +-
> drivers/crypto/ccp/sev-dev.h | 4 +-
> 3 files changed, 196 insertions(+), 267 deletions(-)
For the series:
Acked-by: Tom Lendacky
>
Re: [RFC Part1 PATCH 07/13] x86/compressed: register GHCB memory when SNP is active
On 4/7/21 12:34 PM, Brijesh Singh wrote:
>
> On 4/7/21 6:59 AM, Borislav Petkov wrote:
>> On Wed, Mar 24, 2021 at 11:44:18AM -0500, Brijesh Singh wrote:
>>> The SEV-SNP guest is required to perform GHCB GPA registration. This is
>> Why does it need to do that? Some additional security so as to not allow
>> changing the GHCB once it is established?
>>
>> I'm guessing that's enforced by the SNP fw and we cannot do that
>> retroactively for SEV...? Because it sounds like a nice little thing we
>> could do additionally.
>
> The feature is part of the GHCB version 2 and is enforced by the
> hypervisor. I guess it can be extended for the ES. Since this feature
> was not available in GHCB version 1 (base ES) so it should be presented
> as an optional for the ES ?
GHCB GPA registration is only supported and required 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 vCPU. For more information,
>>> see the GHCB specification section 2.5.2.
>> I think you mean
>>
>> "2.3.2 GHCB GPA Registration"
>>
>> Please use the section name too because that doc changes from time to
>> time.
>>
>> Also, you probably should update it here:
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D206537data=04%7C01%7Cbrijesh.singh%40amd.com%7Ce8ae7574ecc742be6c1a08d8f9bcac94%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533936070042328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NaHJ5R9Dfo%2FPnci%2B%2B6xK9ecpV0%2F%2FYbsdGl25%2BFj3TaU%3Dreserved=0
>>
>
> Yes, the section may have changed since I wrote the description. Noted.
> I will refer the section name.
>
>
>>> diff --git a/arch/x86/boot/compressed/sev-snp.c
>>> b/arch/x86/boot/compressed/sev-snp.c
>>> index 5c25103b0df1..a4c5e85699a7 100644
>>> --- a/arch/x86/boot/compressed/sev-snp.c
>>> +++ b/arch/x86/boot/compressed/sev-snp.c
>>> @@ -113,3 +113,29 @@ void sev_snp_set_page_shared(unsigned long paddr)
>>> {
>>> sev_snp_set_page_private_shared(paddr, SNP_PAGE_STATE_SHARED);
>>> }
>>> +
>>> +void sev_snp_register_ghcb(unsigned long paddr)
>> Right and let's prefix SNP-specific functions with "snp_" only so that
>> it is clear which is wcich when looking at the code.
>>
>>> +{
>>> + u64 pfn = paddr >> PAGE_SHIFT;
>>> + u64 old, val;
>>> +
>>> + if (!sev_snp_enabled())
>>> + return;
>>> +
>>> + /* save the old GHCB MSR */
>>> + old = sev_es_rd_ghcb_msr();
>>> +
>>> + /* Issue VMGEXIT */
>> No need for that comment.
>>
>>> + sev_es_wr_ghcb_msr(GHCB_REGISTER_GPA_REQ_VAL(pfn));
>>> + VMGEXIT();
>>> +
>>> + val = sev_es_rd_ghcb_msr();
>>> +
>>> + /* If the response GPA is not ours then abort the guest */
>>> + if ((GHCB_SEV_GHCB_RESP_CODE(val) != GHCB_REGISTER_GPA_RESP) ||
>>> + (GHCB_REGISTER_GPA_RESP_VAL(val) != pfn))
>>> + sev_es_terminate(GHCB_SEV_ES_REASON_GENERAL_REQUEST);
>> Yet another example where using a specific termination reason could help
>> with debugging guests. Looking at the GHCB spec, I hope GHCBData[23:16]
>> is big enough for all reasons. I'm sure it can be extended ofc ...
>
>
> Maybe we can request the GHCB version 3 to add the extended error code.
>
>
>> :-)
>>
>>> + /* Restore the GHCB MSR value */
>>> + sev_es_wr_ghcb_msr(old);
>>> +}
>>> diff --git a/arch/x86/include/asm/sev-snp.h b/arch/x86/include/asm/sev-snp.h
>>> index f514dad276f2..0523eb21abd7 100644
>>> --- a/arch/x86/include/asm/sev-snp.h
>>> +++ b/arch/x86/include/asm/sev-snp.h
>>> @@ -56,6 +56,13 @@ struct __packed snp_page_state_change {
>>> struct snp_page_state_entry entry[SNP_PAGE_STATE_CHANGE_MAX_ENTRY];
>>> };
>>>
>>> +/* GHCB GPA register */
>>> +#define GHCB_REGISTER_GPA_REQ 0x012UL
>>> +#defineGHCB_REGISTER_GPA_REQ_VAL(v)
>>> (GHCB_REGISTER_GPA_REQ | ((v) << 12))
>>> +
>>> +#define GHCB_REGISTER_GPA_RESP 0x013UL
>> Let's append "UL" to the other request numbers for consistency.
>>
>> Thx.
>>
Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate the memory used for the GHCB
On 4/7/21 8:35 AM, Brijesh Singh wrote:
>
> On 4/7/21 6:16 AM, Borislav Petkov wrote:
>> On Tue, Apr 06, 2021 at 10:47:18AM -0500, Brijesh Singh wrote:
>>> Before the GHCB is established the caller does not need to save and
>>> restore MSRs. The page_state_change() uses the GHCB MSR protocol and it
>>> can be called before and after the GHCB is established hence I am saving
>>> and restoring GHCB MSRs.
>> I think you need to elaborate on that, maybe with an example. What the
>> other sites using the GHCB MSR currently do is:
>>
>> 1. request by writing it
>> 2. read the response
>>
>> None of them save and restore it.
>>
>> So why here?
>
> GHCB provides two ways to exit from the guest to the hypervisor. The MSR
> protocol and NAEs. The MSR protocol is generally used before the GHCB is
> established. After the GHCB is established the guests typically uses the
> NAEs. All of the current call sites uses the MSR protocol before the
> GHCB is established so they do not need to save and restore the GHCB.
> The GHCB is established on the first #VC -
> arch/x86/boot/compressed/sev-es.c early_setup_sev_es(). The GHCB page
> must a shared page:
>
> early_setup_sev_es()
>
> set_page_decrypted()
>
> sev_snp_set_page_shared()
>
> The sev_snp_set_page_shared() called before the GHCB is established.
> 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 current SEV-ES code always sets the GHCB address in the GHCB
MSR before invoking VMGEXIT, so I think you're safe either way. Worth
testing at least.
Thanks,
Tom
>
> Since both the sev_snp_set_page_{shared, private}() uses the common
> routine to request the page change hence I choose the Page State Change
> MSR protocol. In one case the page state request happen before and after
> the GHCB is established. We need to save and restore GHCB otherwise will
> be loose the previously established GHCB GPA.
>
> If needed then we can avoid the save and restore. The GHCB provides a
> page state change NAE that can be used after the GHCB is established. If
> we go with it then code may look like this:
>
> 1. Read the GHCB MSR to determine whether the GHCB is established.
>
> 2. If GHCB is established then use the page state change NAE
>
> 3. If GHCB is not established then use the page state change MSR protocol.
>
> We can eliminate the restore but we still need the rdmsr. The code for
> using the NAE page state is going to be a bit larger. Since it is not in
> the hot path so I felt we stick with MSR protocol for the page state change.
>
> I am open to suggestions.
>
> -Brijesh
>
Re: [PATCH V4 XRT Alveo 20/20] fpga: xrt: Kconfig and Makefile updates for XRT drivers
TC_PATH=$(srctree)/scripts/dtc/libfdt + +obj-$(CONFIG_FPGA_XRT_LIB) += xrt-lib.o + +xrt-lib-objs :=\ + lib-drv.o \ + xroot.o \ + xclbin.o\ + subdev.o\ + cdev.o \ + group.o \ + xleaf/vsec.o\ + xleaf/axigate.o \ + xleaf/devctl.o \ + xleaf/icap.o\ + xleaf/clock.o \ + xleaf/clkfreq.o \ + xleaf/ucs.o \ + xleaf/ddr_calibration.o + +ccflags-y := -I$(FULL_XRT_PATH)/include \ + -I$(FULL_DTC_PATH) diff --git a/drivers/fpga/xrt/metadata/Kconfig b/drivers/fpga/xrt/metadata/Kconfig new file mode 100644 index ..129adda47e94 --- /dev/null +++ b/drivers/fpga/xrt/metadata/Kconfig @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# XRT Alveo FPGA device configuration +# + +config FPGA_XRT_METADATA + bool "XRT Alveo Driver Metadata Parser" + select LIBFDT + help + This option provides helper functions to parse Xilinx Alveo FPGA + firmware metadata. The metadata is in device tree format and the + XRT driver uses it to discover the HW subsystems behind PCIe BAR. diff --git a/drivers/fpga/xrt/metadata/Makefile b/drivers/fpga/xrt/metadata/Makefile new file mode 100644 index ..14f65ef1595c --- /dev/null +++ b/drivers/fpga/xrt/metadata/Makefile @@ -0,0 +1,16 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Copyright (C) 2020-2021 Xilinx, Inc. All rights reserved. +# +# Authors: sonal.san...@xilinx.com +# + +FULL_XRT_PATH=$(srctree)/$(src)/.. +FULL_DTC_PATH=$(srctree)/scripts/dtc/libfdt + +obj-$(CONFIG_FPGA_XRT_METADATA) += xrt-md.o + +xrt-md-objs := metadata.o + +ccflags-y := -I$(FULL_XRT_PATH)/include\ + -I$(FULL_DTC_PATH) diff --git a/drivers/fpga/xrt/mgmt/Kconfig b/drivers/fpga/xrt/mgmt/Kconfig new file mode 100644 index ..31e9e19fffb8 --- /dev/null +++ b/drivers/fpga/xrt/mgmt/Kconfig @@ -0,0 +1,15 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Xilinx XRT FPGA device 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 these configs and just use something like FPGA_XRT ? Tom + select FPGA_BRIDGE + select FPGA_REGION + help + Select this option to enable XRT PCIe driver for Xilinx Alveo FPGA. + This driver provides interfaces for userspace application to access + Alveo FPGA device. diff --git a/drivers/fpga/xrt/mgmt/Makefile b/drivers/fpga/xrt/mgmt/Makefile new file mode 100644 index ..acabd811f3fd --- /dev/null +++ b/drivers/fpga/xrt/mgmt/Makefile @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Copyright (C) 2020-2021 Xilinx, Inc. All rights reserved. +# +# Authors: sonal.san...@xilinx.com +# + +FULL_XRT_PATH=$(srctree)/$(src)/.. +FULL_DTC_PATH=$(srctree)/scripts/dtc/libfdt + +obj-$(CONFIG_FPGA_XRT_XMGMT) += xrt-mgmt.o + +xrt-mgmt-objs := root.o\ + main.o \ + fmgr-drv.o \ + main-region.o + +ccflags-y := -I$(FULL_XRT_PATH)/include\ + -I$(FULL_DTC_PATH)
Re: [PATCH V4 XRT Alveo 19/20] fpga: xrt: partition isolation platform driver
ot;, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int xrt_axigate_epname_idx(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret, i;
ok
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ xrt_err(pdev, "Empty Resource!");
+ return -EINVAL;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(xrt_axigate_epnames); i++) {
ok
+ ret = strncmp(xrt_axigate_epnames[i], res->name,
+ strlen(xrt_axigate_epnames[i]) + 1);
ok
+ if (!ret)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int xrt_axigate_close(struct platform_device *pdev)
+{
+ struct xrt_axigate *gate;
+ u32 status = 0;
+ int ret;
+
+ gate = platform_get_drvdata(pdev);
+
+ mutex_lock(>gate_lock);
+ ret = regmap_read(gate->regmap, XRT_AXIGATE_READ_REG, );
+ if (ret) {
+ xrt_err(pdev, "read gate failed %d", ret);
+ goto failed;
+ }
+ if (status) { /* gate is opened */
+ xleaf_broadcast_event(pdev, XRT_EVENT_PRE_GATE_CLOSE, false);
+ ret = close_gate(gate);
ok
+ if (ret)
+ goto failed;
+ }
+
+ gate->gate_closed = true;
ok
+
+failed:
+ mutex_unlock(>gate_lock);
+
+ xrt_info(pdev, "close gate %s", gate->ep_name);
+ return ret;
+}
+
+static int xrt_axigate_open(struct platform_device *pdev)
+{
+ struct xrt_axigate *gate;
+ u32 status;
+ int ret;
+
+ gate = platform_get_drvdata(pdev);
+
+ mutex_lock(>gate_lock);
+ ret = regmap_read(gate->regmap, XRT_AXIGATE_READ_REG, );
+ if (ret) {
+ xrt_err(pdev, "read gate failed %d", ret);
+ goto failed;
+ }
+ if (!status) { /* gate is closed */
+ ret = open_gate(gate);
+ if (ret)
+ goto failed;
+ xleaf_broadcast_event(pdev, XRT_EVENT_POST_GATE_OPEN, true);
+ /* xrt_axigate_open() could be called in event cb, thus
+* we can not wait for the completes
+*/
+ }
+
+ gate->gate_closed = false;
+
+failed:
+ mutex_unlock(>gate_lock);
+
+ xrt_info(pdev, "open gate %s", gate->ep_name);
+ return ret;
+}
+
+static void xrt_axigate_event_cb(struct platform_device *pdev, void *arg)
+{
+ struct xrt_axigate *gate = platform_get_drvdata(pdev);
+ struct xrt_event *evt = (struct xrt_event *)arg;
+ enum xrt_events e = evt->xe_evt;
+ struct platform_device *leaf;
+ enum xrt_subdev_id id;
+ struct resource *res;
+ int instance;
+
+ if (e != XRT_EVENT_POST_CREATION)
+ return;
+
+ instance = evt->xe_subdev.xevt_subdev_instance;
+ id = evt->xe_subdev.xevt_subdev_id;
+ if (id != XRT_SUBDEV_AXIGATE)
+ return;
ok
+
+ leaf = xleaf_get_leaf_by_id(pdev, id, instance);
+ if (!leaf)
+ return;
+
+ res = platform_get_resource(leaf, IORESOURCE_MEM, 0);
+ if (!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: Tom Rix
+ if (xrt_axigate_epname_idx(leaf) > xrt_axigate_epname_idx(pdev))
+ xrt_axigate_open(pdev);
+ else
+ xleaf_call(leaf, XRT_AXIGATE_OPEN, NULL);
+
+ xleaf_put_leaf(pdev, leaf);
+}
+
+static int
+xrt_axigate_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+ int ret = 0;
+
+ switch (cmd) {
+ case XRT_XLEAF_EVENT:
+ xrt_axigate_event_cb(pdev, arg);
+ break;
+ case XRT_AXIGATE_CLOSE:
+ ret = xrt_axigate_close(pdev);
+ break;
+ case XRT_AXIGATE_OPEN:
+ ret = xrt_axigate_open(pdev);
+ break;
+ default:
+ xrt_err(pdev, "unsupported cmd %d", cmd);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int xrt_axigate_probe(struct platform_device *pdev)
+{
+ struct xrt_axigate *gate = NULL;
+ void __iomem *base = NULL;
+ struct resource *res;
+ int ret;
+
+ gate = devm_kzalloc(>dev, sizeof(*gate), GFP_KERNEL);
+ if (!gate)
+ return -ENOMEM;
+
+ gate->pdev = pdev;
+ platform_set_drvdata(pdev, gate);
+
+ xrt_info(pdev, "probing...");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ xrt_err(pdev, &
Re: [PATCH V4 XRT Alveo 18/20] fpga: xrt: DDR calibration platform driver
On 3/23/21 10:29 PM, Lizhi Hou wrote:
Add DDR calibration driver. DDR calibration is a hardware function
discovered by walking firmware metadata. A platform device node will
be created for it. Hardware provides DDR calibration status through
this function.
Signed-off-by: Sonal Santan
Signed-off-by: Max Zhen
Signed-off-by: Lizhi Hou
---
.../fpga/xrt/include/xleaf/ddr_calibration.h | 28 +++
drivers/fpga/xrt/lib/xleaf/ddr_calibration.c | 226 ++
ok
2 files changed, 254 insertions(+)
create mode 100644 drivers/fpga/xrt/include/xleaf/ddr_calibration.h
create mode 100644 drivers/fpga/xrt/lib/xleaf/ddr_calibration.c
diff --git a/drivers/fpga/xrt/include/xleaf/ddr_calibration.h
b/drivers/fpga/xrt/include/xleaf/ddr_calibration.h
new file mode 100644
index ..878740c26ca2
--- /dev/null
+++ b/drivers/fpga/xrt/include/xleaf/ddr_calibration.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Cheng Zhen
+ */
+
+#ifndef _XRT_DDR_CALIBRATION_H_
+#define _XRT_DDR_CALIBRATION_H_
+
+#include "xleaf.h"
+#include
+
+/*
+ * Memory calibration driver leaf calls.
+ */
+enum xrt_calib_results {
+ XRT_CALIB_UNKNOWN = 0,
ok
+ XRT_CALIB_SUCCEEDED,
+ XRT_CALIB_FAILED,
+};
+
+enum xrt_calib_leaf_cmd {
+ XRT_CALIB_RESULT = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
+};
+
+#endif /* _XRT_DDR_CALIBRATION_H_ */
diff --git a/drivers/fpga/xrt/lib/xleaf/ddr_calibration.c
b/drivers/fpga/xrt/lib/xleaf/ddr_calibration.c
new file mode 100644
index ..5a9fa82946cb
--- /dev/null
+++ b/drivers/fpga/xrt/lib/xleaf/ddr_calibration.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo FPGA memory calibration driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * memory calibration
+ *
+ * Authors:
+ * Lizhi Hou
+ */
+#include
+#include
+#include "xclbin-helper.h"
+#include "metadata.h"
+#include "xleaf/ddr_calibration.h"
+
+#define XRT_CALIB "xrt_calib"
+
+#define XRT_CALIB_STATUS_REG 0
+#define XRT_CALIB_READ_RETRIES 20
+#define XRT_CALIB_READ_INTERVAL500 /* ms */
+
+static const struct regmap_config calib_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x1000,
ok
+};
+
+struct calib_cache {
+ struct list_headlink;
+ const char *ep_name;
+ char*data;
+ u32 data_size;
+};
+
+struct calib {
+ struct platform_device *pdev;
+ struct regmap *regmap;
+ struct mutexlock; /* calibration dev lock */
+ struct list_headcache_list;
+ u32 cache_num;
+ enum xrt_calib_results result;
+};
+
+static void __calib_cache_clean_nolock(struct calib *calib)
ok
+{
+ struct calib_cache *cache, *temp;
+
+ list_for_each_entry_safe(cache, temp, >cache_list, link) {
+ vfree(cache->data);
+ list_del(>link);
+ vfree(cache);
+ }
+ calib->cache_num = 0;
+}
+
+static void calib_cache_clean(struct calib *calib)
+{
+ mutex_lock(>lock);
+ __calib_cache_clean_nolock(calib);
+ mutex_unlock(>lock);
+}
+
+static int calib_calibration(struct calib *calib)
+{
+ u32 times = XRT_CALIB_READ_RETRIES;
ok
+ u32 status;
+ int ret;
+
+ while (times != 0) {
+ ret = regmap_read(calib->regmap, XRT_CALIB_STATUS_REG, );
+ if (ret) {
+ xrt_err(calib->pdev, "failed to read status reg %d",
ret);
+ return ret;
+ }
+
+ if (status & BIT(0))
+ break;
+ msleep(XRT_CALIB_READ_INTERVAL);
ok
Reviewed-by: Tom Rix
+ times--;
+ }
+
+ if (!times) {
+ xrt_err(calib->pdev,
+ "MIG calibration timeout after bitstream download");
+ return -ETIMEDOUT;
+ }
+
+ xrt_info(calib->pdev, "took %dms", (XRT_CALIB_READ_RETRIES - times) *
+XRT_CALIB_READ_INTERVAL);
+ return 0;
+}
+
+static void xrt_calib_event_cb(struct platform_device *pdev, void *arg)
+{
+ struct calib *calib = platform_get_drvdata(pdev);
+ struct xrt_event *evt = (struct xrt_event *)arg;
+ enum xrt_events e = evt->xe_evt;
+ enum xrt_subdev_id id;
+ int ret;
+
+ id = evt->xe_subdev.xevt_subdev_id;
+
+ switch (e) {
+ case XRT_EVENT_POST_CREATION:
+ if (id == XRT_SUBDEV_UCS) {
+ ret = calib_calibration(calib);
+ if (ret)
+ calib->result = XRT_CALIB_FAILED;
+
Re: [PATCH V4 XRT Alveo 17/20] fpga: xrt: clock frequency counter platform driver
return -EINVAL;
ok
+
+ count = snprintf(buf, 64, "%u\n", freq);
ok
+
+ return count;
+}
+static DEVICE_ATTR_RO(freq);
+
+static struct attribute *clkfreq_attrs[] = {
+ _attr_freq.attr,
+ NULL,
+};
+
+static struct attribute_group clkfreq_attr_group = {
+ .attrs = clkfreq_attrs,
+};
+
+static int
+xrt_clkfreq_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+ struct clkfreq *clkfreq;
+ int ret = 0;
+
+ clkfreq = platform_get_drvdata(pdev);
+
+ switch (cmd) {
+ case XRT_XLEAF_EVENT:
+ /* Does not handle any event. */
+ break;
+ case XRT_CLKFREQ_READ:
ok
+ ret = clkfreq_read(clkfreq, arg);
ok
+ break;
+ default:
+ xrt_err(pdev, "unsupported cmd %d", cmd);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int clkfreq_remove(struct platform_device *pdev)
+{
+ sysfs_remove_group(>dev.kobj, _attr_group);
+
+ return 0;
+}
+
+static int clkfreq_probe(struct platform_device *pdev)
+{
+ struct clkfreq *clkfreq = NULL;
+ void __iomem *base = NULL;
+ struct resource *res;
+ int ret;
+
+ clkfreq = devm_kzalloc(>dev, sizeof(*clkfreq), GFP_KERNEL);
+ if (!clkfreq)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, clkfreq);
+ clkfreq->pdev = pdev;
+ mutex_init(>clkfreq_lock);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ ret = -EINVAL;
+ goto failed;
+ }
+ base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(base)) {
+ ret = PTR_ERR(base);
+ goto failed;
+ }
+
+ clkfreq->regmap = devm_regmap_init_mmio(>dev, base,
_regmap_config);
+ if (IS_ERR(clkfreq->regmap)) {
+ CLKFREQ_ERR(clkfreq, "regmap %pR failed", res);
+ ret = PTR_ERR(clkfreq->regmap);
+ goto failed;
+ }
+ clkfreq->clkfreq_ep_name = res->name;
+
+ ret = sysfs_create_group(>dev.kobj, _attr_group);
+ if (ret) {
+ CLKFREQ_ERR(clkfreq, "create clkfreq attrs failed: %d", ret);
+ 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[]) {
+ { .regmap_name = XRT_MD_REGMAP_CLKFREQ },
ok
Looks good to me
Reviewed-by: Tom Rix
+ { NULL },
+ },
+ .xse_min_ep = 1,
+ },
+ { 0 },
+};
+
+static struct xrt_subdev_drvdata xrt_clkfreq_data = {
+ .xsd_dev_ops = {
+ .xsd_leaf_call = xrt_clkfreq_leaf_call,
+ },
+};
+
+static const struct platform_device_id xrt_clkfreq_table[] = {
+ { XRT_CLKFREQ, (kernel_ulong_t)_clkfreq_data },
+ { },
+};
+
+static struct platform_driver xrt_clkfreq_driver = {
+ .driver = {
+ .name = XRT_CLKFREQ,
+ },
+ .probe = clkfreq_probe,
+ .remove = clkfreq_remove,
+ .id_table = xrt_clkfreq_table,
+};
+
+XRT_LEAF_INIT_FINI_FUNC(XRT_SUBDEV_CLKFREQ, clkfreq);
Re: [PATCH V4 XRT Alveo 16/20] fpga: xrt: clock platform driver
L);
+ if (err) {
+ xrt_info(clock->pdev, "no default freq");
+ return 0;
+ }
+
+ err = set_freq(clock, be16_to_cpu(*freq));
+
+ return err;
+}
+
+static ssize_t freq_show(struct device *dev, struct device_attribute *attr,
char *buf)
+{
+ struct clock *clock = platform_get_drvdata(to_platform_device(dev));
+ ssize_t count;
+ u16 freq = 0;
+
+ count = clock_get_freq(clock, , NULL);
+ if (count < 0)
+ return count;
+
+ count = snprintf(buf, 64, "%u\n", freq);
ok
Thanks for the changes
Reviewed-by: Tom Rix
+
+ return count;
+}
+static DEVICE_ATTR_RO(freq);
+
+static struct attribute *clock_attrs[] = {
+ _attr_freq.attr,
+ NULL,
+};
+
+static struct attribute_group clock_attr_group = {
+ .attrs = clock_attrs,
+};
+
+static int
+xrt_clock_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+ struct clock *clock;
+ int ret = 0;
+
+ clock = platform_get_drvdata(pdev);
+
+ switch (cmd) {
+ case XRT_XLEAF_EVENT:
+ /* Does not handle any event. */
+ break;
+ case XRT_CLOCK_SET: {
+ u16 freq = (u16)(uintptr_t)arg;
+
+ ret = set_freq(clock, freq);
+ break;
+ }
+ case XRT_CLOCK_VERIFY:
+ ret = clock_verify_freq(clock);
+ break;
+ case XRT_CLOCK_GET: {
+ struct xrt_clock_get *get =
+ (struct xrt_clock_get *)arg;
+
+ ret = clock_get_freq(clock, >freq, >freq_cnter);
+ break;
+ }
+ default:
+ xrt_err(pdev, "unsupported cmd %d", cmd);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int clock_remove(struct platform_device *pdev)
+{
+ sysfs_remove_group(>dev.kobj, _attr_group);
+
+ return 0;
+}
+
+static int clock_probe(struct platform_device *pdev)
+{
+ struct clock *clock = NULL;
+ void __iomem *base = NULL;
+ struct resource *res;
+ int ret;
+
+ clock = devm_kzalloc(>dev, sizeof(*clock), GFP_KERNEL);
+ if (!clock)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, clock);
+ clock->pdev = pdev;
+ mutex_init(>clock_lock);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ ret = -EINVAL;
+ goto failed;
+ }
+
+ base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(base)) {
+ ret = PTR_ERR(base);
+ goto failed;
+ }
+
+ clock->regmap = devm_regmap_init_mmio(>dev, base,
_regmap_config);
+ if (IS_ERR(clock->regmap)) {
+ CLOCK_ERR(clock, "regmap %pR failed", res);
+ ret = PTR_ERR(clock->regmap);
+ goto failed;
+ }
+ clock->clock_ep_name = res->name;
+
+ ret = clock_init(clock);
+ if (ret)
+ goto failed;
+
+ ret = sysfs_create_group(>dev.kobj, _attr_group);
+ if (ret) {
+ CLOCK_ERR(clock, "create clock attrs failed: %d", ret);
+ goto failed;
+ }
+
+ CLOCK_INFO(clock, "successfully initialized Clock subdev");
+
+ return 0;
+
+failed:
+ return ret;
+}
+
+static struct xrt_subdev_endpoints xrt_clock_endpoints[] = {
+ {
+ .xse_names = (struct xrt_subdev_ep_names[]) {
+ { .regmap_name = "clkwiz" },
+ { NULL },
+ },
+ .xse_min_ep = 1,
+ },
+ { 0 },
+};
+
+static struct xrt_subdev_drvdata xrt_clock_data = {
+ .xsd_dev_ops = {
+ .xsd_leaf_call = xrt_clock_leaf_call,
+ },
+};
+
+static const struct platform_device_id xrt_clock_table[] = {
+ { XRT_CLOCK, (kernel_ulong_t)_clock_data },
+ { },
+};
+
+static struct platform_driver xrt_clock_driver = {
+ .driver = {
+ .name = XRT_CLOCK,
+ },
+ .probe = clock_probe,
+ .remove = clock_remove,
+ .id_table = xrt_clock_table,
+};
+
+XRT_LEAF_INIT_FINI_FUNC(XRT_SUBDEV_CLOCK, clock);
Re: [RFC Part1 PATCH 06/13] x86/compressed: rescinds and validate the memory used for the GHCB
On 4/6/21 10:47 AM, Brijesh Singh wrote: > > On 4/6/21 5:33 AM, Borislav Petkov wrote: >> On Wed, Mar 24, 2021 at 11:44:17AM -0500, Brijesh Singh wrote: >> ... >> *Any* and *all* page state changes which fail immediately terminate a >> guest? Why? > > > The hypervisor uses the RMPUPDATE instruction to add the pages in the > RMP table. If RMPUPDATE fails, then it will be communicated to the > guest. Now its up to guest on what it wants to do. I choose to terminate > because guest can't resolve this step on its own. It needs help from the > hypervisor and hypervisor has bailed on it. Depending on request type, > the next step will either fail or we go into infinite loop. Lets > consider an example: > > 1. Guest asked to add a page as a private in RMP table. > > 2. Hypervisor fail to add the page in the RMP table and return an error. > > 3. Guest ignored the error code and moved to the step to validate the page. > > 4. The page validation instruction expects that page must be added in > the RMP table. In our case the page was not added in the RMP table. So > it will cause #NPF (rmp violation). > > 5. On #NPF, hypervisor will try adding the page as private but it will > fail (same as #2). This will keep repeating and guest will not make any > progress. > > I choose to return "void" from page_state_change() because caller can't > do anything with error code. Some of the failure may have security > implication, terminate the guest as soon as we detect an error condition. > > >> Then, how do we communicate this to the guest user what has happened? >> >> Can GHCB_SEV_ES_REASON_GENERAL_REQUEST be something special 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. > > Tom, > > Any other suggestion ? The GHCB spec only defines the "0" reason code set. We could provide Linux it's own reason code set with some more specific reason codes for failures, if that is needed. Thanks, Tom > > >>
Re: [RFCv1 7/7] KVM: unmap guest memory using poisoned pages
On 4/6/21 9:33 AM, Dave Hansen wrote: > On 4/6/21 12:44 AM, David Hildenbrand wrote: >> On 02.04.21 17:26, Kirill A. Shutemov wrote: >>> TDX architecture aims to provide resiliency against confidentiality and >>> integrity attacks. Towards this goal, the TDX architecture helps enforce >>> the enabling of memory integrity for all TD-private memory. >>> >>> The CPU memory controller computes the integrity check value (MAC) for >>> the data (cache line) during writes, and it stores the MAC with the >>> memory as meta-data. A 28-bit MAC is stored in the ECC bits. >>> >>> Checking of memory integrity is performed during memory reads. If >>> integrity check fails, CPU poisones cache line. >>> >>> On a subsequent consumption (read) of the poisoned data by software, >>> there are two possible scenarios: >>> >>> - Core determines that the execution can continue and it treats >>> poison with exception semantics signaled as a #MCE >>> >>> - Core determines execution cannot continue,and it does an unbreakable >>> shutdown >>> >>> For more details, see Chapter 14 of Intel TDX Module EAS[1] >>> >>> As some of integrity check failures may lead to system shutdown host >>> kernel must not allow any writes to TD-private memory. This requirment >>> clashes with KVM design: KVM expects the guest memory to be mapped into >>> host userspace (e.g. QEMU). >> >> So what you are saying is that if QEMU would write to such memory, it >> could crash the kernel? What a broken design. > > IMNHO, the broken design is mapping the memory to userspace in the first > place. Why the heck would you actually expose something with the MMU to > a context that can't possibly meaningfully access or safely write to it? > > This started with SEV. QEMU creates normal memory mappings with the SEV > C-bit (encryption) disabled. The kernel plumbs those into NPT, but when > those are instantiated, they have the C-bit set. So, we have mismatched > mappings. Where does that lead? The two mappings not only differ in > the encryption bit, causing one side to read gibberish if the other > writes: they're not even cache coherent. QEMU is running on the hypervisor side, so even if the C-bit is set for its memory mappings, it would use the hypervisor key to access the memory, not the guest key. So it doesn't matter from a QEMU perspective whether it creates mappings with or without the C-bit. The C-bit in the NPT is only used if the guest is accessing the memory as shared/un-encrypted, in which case the the hypervisor key is then used. The latest EPYC hardware provides cache coherency for encrypted / non-encrypted accesses (X86_FEATURE_SME_COHERENT). > > That's 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 >
Re: [PATCH V4 XRT Alveo 15/20] fpga: xrt: devctl platform driver
On 3/23/21 10:29 PM, Lizhi Hou wrote:
Add devctl driver. devctl is a type of hardware function which only has
few registers to read or write. They are discovered by walking firmware
metadata. A platform device node will be created for them.
Signed-off-by: Sonal Santan
Signed-off-by: Max Zhen
Signed-off-by: Lizhi Hou
---
drivers/fpga/xrt/include/xleaf/devctl.h | 40 ++
drivers/fpga/xrt/lib/xleaf/devctl.c | 183
2 files changed, 223 insertions(+)
create mode 100644 drivers/fpga/xrt/include/xleaf/devctl.h
create mode 100644 drivers/fpga/xrt/lib/xleaf/devctl.c
diff --git a/drivers/fpga/xrt/include/xleaf/devctl.h
b/drivers/fpga/xrt/include/xleaf/devctl.h
new file mode 100644
index ..b97f3b6d9326
--- /dev/null
+++ b/drivers/fpga/xrt/include/xleaf/devctl.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou
+ */
+
+#ifndef _XRT_DEVCTL_H_
+#define _XRT_DEVCTL_H_
+
+#include "xleaf.h"
+
+/*
+ * DEVCTL driver leaf calls.
+ */
+enum xrt_devctl_leaf_cmd {
+ XRT_DEVCTL_READ = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
+};
+
+enum xrt_devctl_id {
+ XRT_DEVCTL_ROM_UUID = 0,
ok
+ XRT_DEVCTL_DDR_CALIB,
+ XRT_DEVCTL_GOLDEN_VER,
+ XRT_DEVCTL_MAX
+};
+
+struct xrt_devctl_rw {
+ u32 xdr_id;
+ void*xdr_buf;
+ u32 xdr_len;
+ u32 xdr_offset;
+};
+
+struct xrt_devctl_intf_uuid {
+ u32 uuid_num;
+ uuid_t *uuids;
+};
+
+#endif /* _XRT_DEVCTL_H_ */
diff --git a/drivers/fpga/xrt/lib/xleaf/devctl.c
b/drivers/fpga/xrt/lib/xleaf/devctl.c
new file mode 100644
index ..ae086d7c431d
--- /dev/null
+++ b/drivers/fpga/xrt/lib/xleaf/devctl.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo FPGA devctl Driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "metadata.h"
+#include "xleaf.h"
+#include "xleaf/devctl.h"
+
+#define XRT_DEVCTL "xrt_devctl"
+
+struct xrt_name_id {
+ char *ep_name;
+ int id;
+};
+
+static struct xrt_name_id name_id[XRT_DEVCTL_MAX] = {
+ { XRT_MD_NODE_BLP_ROM, XRT_DEVCTL_ROM_UUID },
+ { XRT_MD_NODE_GOLDEN_VER, XRT_DEVCTL_GOLDEN_VER },
+};
+
+static const struct regmap_config devctl_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
ok
+};
+
+struct xrt_devctl {
+ struct platform_device *pdev;
+ struct regmap *regmap[XRT_DEVCTL_MAX];
+ ulong sizes[XRT_DEVCTL_MAX];
+};
+
+static int xrt_devctl_name2id(struct xrt_devctl *devctl, const char *name)
+{
+ int i;
+
+ for (i = 0; i < XRT_DEVCTL_MAX && name_id[i].ep_name; i++) {
+ if (!strncmp(name_id[i].ep_name, name,
strlen(name_id[i].ep_name) + 1))
+ return name_id[i].id;
+ }
+
+ return -EINVAL;
+}
+
+static int
+xrt_devctl_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+ struct xrt_devctl *devctl;
+ int ret = 0;
+
+ devctl = platform_get_drvdata(pdev);
+
+ switch (cmd) {
+ case XRT_XLEAF_EVENT:
+ /* Does not handle any event. */
+ break;
+ case XRT_DEVCTL_READ: {
+ struct xrt_devctl_rw *rw_arg = arg;
+
+ if (rw_arg->xdr_len & 0x3) {
+ xrt_err(pdev, "invalid len %d", rw_arg->xdr_len);
+ return -EINVAL;
+ }
+
+ if (rw_arg->xdr_id >= XRT_DEVCTL_MAX) {
ok
+ xrt_err(pdev, "invalid id %d", rw_arg->xdr_id);
+ return -EINVAL;
+ }
+
+ if (!devctl->regmap[rw_arg->xdr_id]) {
+ xrt_err(pdev, "io not found, id %d",
+ rw_arg->xdr_id);
+ return -EINVAL;
+ }
+
+ ret = regmap_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 the changes
Reviewed-by: Tom Rix
+ default:
+ xrt_err(pdev, "unsupported cmd %d", cmd);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int xrt_devctl_probe(struct platform_device *pdev)
+{
+ struct xrt_devctl *devctl = NULL;
+ void __iomem *base = NULL;
+ struct resource *res;
+ int i, id, ret = 0;
+
+ devctl = devm_kzalloc(>dev, sizeof(*devctl), GFP_KERNEL);
+ if (!devctl)
+ return
Re: [PATCH V4 XRT Alveo 14/20] fpga: xrt: ICAP platform driver
{
+ value = be32_to_cpu(word_buf[i]);
+ ret = regmap_write(icap->regmap, ICAP_REG_WF, value);
+ if (ret)
+ return ret;
+ }
+
+ ret = regmap_write(icap->regmap, ICAP_REG_CR, 0x1);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < 20; i++) {
+ ret = regmap_read(icap->regmap, ICAP_REG_CR, );
+ if (ret)
+ return ret;
+
+ if ((value & 0x1) == 0)
+ return 0;
+ ndelay(50);
+ }
+
+ ICAP_ERR(icap, "writing %d dwords timeout", size);
+ return -EIO;
+}
+
+static int bitstream_helper(struct icap *icap, const u32 *word_buffer,
+ u32 word_count)
+{
+ int wr_fifo_vacancy = 0;
+ u32 word_written = 0;
+ u32 remain_word;
+ int err = 0;
+
+ WARN_ON(!mutex_is_locked(>icap_lock));
+ for (remain_word = word_count; remain_word > 0;
+remain_word -= word_written, word_buffer += word_written) {
+ err = regmap_read(icap->regmap, ICAP_REG_WFV, _fifo_vacancy);
+ if (err) {
+ ICAP_ERR(icap, "read wr_fifo_vacancy failed %d", err);
+ break;
+ }
+ if (wr_fifo_vacancy <= 0) {
+ ICAP_ERR(icap, "no vacancy: %d", wr_fifo_vacancy);
+ err = -EIO;
+ break;
+ }
+ word_written = (wr_fifo_vacancy < remain_word) ?
+ wr_fifo_vacancy : remain_word;
+ if (icap_write(icap, word_buffer, word_written) != 0) {
+ ICAP_ERR(icap, "write failed remain %d, written %d",
+remain_word, word_written);
+ err = -EIO;
+ break;
+ }
+ }
+
+ return err;
+}
+
+static int icap_download(struct icap *icap, const char *buffer,
+unsigned long length)
+{
+ u32 num_chars_read = XCLBIN_HWICAP_BITFILE_BUF_SZ;
+ u32 byte_read;
+ int err = 0;
+
+ if (length % sizeof(u32)) {
ok
+ ICAP_ERR(icap, "invalid bitstream length %ld", length);
+ return -EINVAL;
+ }
+
+ mutex_lock(>icap_lock);
+ for (byte_read = 0; byte_read < length; byte_read += num_chars_read) {
+ num_chars_read = length - byte_read;
+ if (num_chars_read > XCLBIN_HWICAP_BITFILE_BUF_SZ)
+ num_chars_read = XCLBIN_HWICAP_BITFILE_BUF_SZ;
+
+ err = bitstream_helper(icap, (u32 *)buffer, num_chars_read /
sizeof(u32));
+ if (err)
+ goto failed;
+ buffer += num_chars_read;
+ }
+
+ /* there is not any cleanup needs to be done if writing ICAP timeout. */
+ err = wait_for_done(icap);
+
+failed:
+ mutex_unlock(>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.
Looks good overall, only a few minor things.
Reviewed-by: Tom Rix
+
+ regmap_read(icap->regmap, ICAP_REG_SR, );
+ if (val != ICAP_STATUS_DONE)
+ return -ENODEV;
+ /* Read ICAP FIFO vacancy */
+ regmap_read(icap->regmap, ICAP_REG_WFV, );
+ if (val < 8)
+ return -ENODEV;
+ err = icap_write(icap, idcode_stream, ARRAY_SIZE(idcode_stream));
+ if (err)
+ return err;
+ err = wait_for_done(icap);
+ if (err)
+ return err;
+
+ /* Tell config engine how many words to transfer to read FIFO */
+ regmap_write(icap->regmap, ICAP_REG_SZ, 0x1);
+ /* Switch the ICAP to read mode */
+ regmap_write(icap->regmap, ICAP_REG_CR, 0x2);
+ err = wait_for_done(icap);
+ if (err)
+ return err;
+
+ /* Read IDCODE from Read FIFO */
+ regmap_read(icap->regmap, ICAP_REG_RF, >idcode);
+ return 0;
+}
+
+static int
+xrt_icap_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
+{
+ struct xrt_icap_wr *wr_arg = arg;
+ struct icap *icap;
+ int ret = 0;
+
+ icap = platform_get_drvdata(pdev);
+
+ switch (cmd) {
+ case XRT_XLEAF_EVENT:
+ /* Does not handle any event. */
+ break;
+ case XRT_ICAP_WRITE:
+ ret = icap_download(icap, wr_arg->xiiw_bit_data,
+ wr_arg->xiiw_data_len);
+ break;
+ case XRT_ICAP_GET_IDCODE:
+ *(u32 *)arg = icap->idcode;
+ break;
+ default:
+ ICAP_ER
RE: [PATCH v4 5/7] PCI: cadence: Add support to configure virtual functions
> -Original Message- > From: Kishon Vijay Abraham I > Sent: 10 March 2021 16:10 > > Now that support for SR-IOV is added in PCIe endpoint core, add support > to configure virtual functions in the Cadence PCIe EP driver. > > Signed-off-by: Kishon Vijay Abraham 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
[ANNOUNCE] 5.4.109-rt55
Hello RT Folks! I'm pleased to announce the 5.4.109-rt55 stable release. This release is just an update to the new stable 5.4.109 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v5.4-rt Head SHA1: 209aee2366649eebf5b3881f73199cc78d4700f3 Or to build 5.4.109-rt55 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.4.tar.xz https://www.kernel.org/pub/linux/kernel/v5.x/patch-5.4.109.xz https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/patch-5.4.109-rt55.patch.xz Enjoy! Tom
Re: [PATCH rdma-next 02/10] RDMA/core: Enable Relaxed Ordering in __ib_alloc_pd()
On 4/5/2021 1:23 AM, Leon Romanovsky wrote:
From: Avihai Horon
Enable Relaxed Ordering in __ib_alloc_pd() allocation of the
local_dma_lkey.
This will take effect only for devices that don't pre-allocate the lkey
but allocate it per PD allocation.
Signed-off-by: Avihai Horon
Reviewed-by: Michael Guralnik
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/verbs.c | 3 ++-
drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index a1782f8a6ca0..9b719f7d6fd5 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -287,7 +287,8 @@ struct ib_pd *__ib_alloc_pd(struct ib_device *device,
unsigned int flags,
if (device->attrs.device_cap_flags & IB_DEVICE_LOCAL_DMA_LKEY)
pd->local_dma_lkey = device->local_dma_lkey;
else
- mr_access_flags |= IB_ACCESS_LOCAL_WRITE;
+ mr_access_flags |=
+ IB_ACCESS_LOCAL_WRITE | IB_ACCESS_RELAXED_ORDERING;
So, do local_dma_lkey's get relaxed ordering unconditionally?
if (flags & IB_PD_UNSAFE_GLOBAL_RKEY) {
pr_warn("%s: enabling unsafe global rkey\n", caller);
diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
index b3fa783698a0..d74827694f92 100644
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c
@@ -66,6 +66,7 @@ struct ib_mr *pvrdma_get_dma_mr(struct ib_pd *pd, int acc)
int ret;
/* Support only LOCAL_WRITE flag for DMA MRs */
+ acc &= ~IB_ACCESS_RELAXED_ORDERING;
if (acc & ~IB_ACCESS_LOCAL_WRITE) {
dev_warn(>pdev->dev,
"unsupported dma mr access flags %#x\n", acc);
Why does the pvrdma driver require relaxed ordering to be off?
Tom.
Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs
On 4/5/2021 10:08 AM, Leon Romanovsky wrote: On Mon, Apr 05, 2021 at 03:41:15PM +0200, Christoph Hellwig wrote: On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote: From: Leon Romanovsky >From Avihai, Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering imposed on PCI transactions, and thus, can improve performance. Until now, relaxed ordering could be set only by user space applications for user MRs. The following patch series enables relaxed ordering for the kernel ULPs as well. Relaxed ordering is an optional capability, and as such, it is ignored by vendors that don't support it. The following test results show the performance improvement achieved with relaxed ordering. The test was performed on a NVIDIA A100 in order to check performance of storage infrastructure over xprtrdma: Isn't the Nvidia A100 a GPU not actually supported by Linux at all? What does that have to do with storage protocols? This system is in use by our storage oriented customer who performed the test. He runs drivers/infiniband/* stack from the upstream, simply backported to specific kernel version. The performance boost is seen in other systems too. We need to see more information about this test, and platform. What correctness testing was done, and how was it verified? What PCI bus type(s) were tested, and with what adapters? What storage workload was generated, and were all possible RDMA exchanges by each ULP exercised? Also if you enable this for basically all kernel ULPs, why not have an opt-out into strict ordering for the cases that need it (if there are any). The RO property is optional, it can only improve. In addition, all in-kernel ULPs don't need strict ordering. I can be mistaken here and Jason will correct me, it is because of two things: ULP doesn't touch data before CQE and DMA API prohibits it. +1 on Christoph's comment. I woud hope most well-architected ULPs will support relaxed ordering, but storage workloads, in my experience, can find ways to cause failure in adapters. I would not suggest making this the default behavior without extensive testing. Tom.
Re: [PATCH 2/5] crypto: ccp: Reject SEV commands with mismatching command buffer
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 >>> --- a/drivers/crypto/ccp/sev-dev.c >>> +++ b/drivers/crypto/ccp/sev-dev.c >>> @@ -141,6 +141,7 @@ static int __sev_do_cmd_locked(int cmd, void *data, int >>> *psp_ret) >>> struct sev_device *sev; >>> unsigned int phys_lsb, phys_msb; >>> unsigned int reg, ret = 0; >>> + int buf_len; >>> >>> if (!psp || !psp->sev_data) >>> return -ENODEV; >>> @@ -150,7 +151,11 @@ static int __sev_do_cmd_locked(int cmd, void *data, >>> int *psp_ret) >>> >>> sev = psp->sev_data; >>> >>> - if (data && WARN_ON_ONCE(is_vmalloc_addr(data))) >>> + buf_len = sev_cmd_buffer_len(cmd); >>> + if (WARN_ON_ONCE(!!data != !!buf_len)) >> >> Seems a bit confusing to me. Can this just be: >> >> if (WARN_ON_ONCE(data && !buf_len)) > > Or as Christophe pointed out, "!data != !buf_len". > >> Or is this also trying to catch the case where buf_len is non-zero but >> data is NULL? > > Ya. It's not necessary to detect "buf_len && !data", but it doesn't incur > additional cost. Is there a reason _not_ to disallow that? Nope, no reason. I was just trying to process all the not signs :) Thanks, Tom >
Re: [PATCH 2/5] crypto: ccp: Reject SEV commands with mismatching command buffer
On 4/2/21 6:36 PM, Sean Christopherson wrote:
> WARN on and reject SEV commands that provide a valid data pointer, but do
> not have a known, non-zero length. And conversely, reject commands that
> take a command buffer but none is provided.
>
> Aside from sanity checking intput, disallowing a non-null pointer without
s/intput/input/
> a non-zero size will allow a future patch to cleanly handle vmalloc'd
> data by copying the data to an internal __pa() friendly buffer.
>
> Note, this also effectively prevents callers from using commands that
> have a non-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
> ---
> drivers/crypto/ccp/sev-dev.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index 6556d220713b..4c513318f16a 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -141,6 +141,7 @@ static int __sev_do_cmd_locked(int cmd, void *data, int
> *psp_ret)
> struct sev_device *sev;
> unsigned int phys_lsb, phys_msb;
> unsigned int reg, ret = 0;
> + int buf_len;
>
> if (!psp || !psp->sev_data)
> return -ENODEV;
> @@ -150,7 +151,11 @@ static int __sev_do_cmd_locked(int cmd, void *data, int
> *psp_ret)
>
> sev = psp->sev_data;
>
> - if (data && WARN_ON_ONCE(is_vmalloc_addr(data)))
> + buf_len = sev_cmd_buffer_len(cmd);
> + if (WARN_ON_ONCE(!!data != !!buf_len))
Seems a bit confusing to me. Can this just be:
if (WARN_ON_ONCE(data && !buf_len))
Or is this also trying to catch the case where buf_len is non-zero but
data is NULL?
Thanks,
Tom
> + return -EINVAL;
> +
> + if (WARN_ON_ONCE(data && is_vmalloc_addr(data)))
> return -EINVAL;
>
> /* Get the physical address of the command buffer */
> @@ -161,7 +166,7 @@ static int __sev_do_cmd_locked(int cmd, void *data, int
> *psp_ret)
> cmd, phys_msb, phys_lsb, psp_timeout);
>
> print_hex_dump_debug("(in): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> - sev_cmd_buffer_len(cmd), false);
> + buf_len, false);
>
> iowrite32(phys_lsb, sev->io_regs + sev->vdata->cmdbuff_addr_lo_reg);
> iowrite32(phys_msb, sev->io_regs + sev->vdata->cmdbuff_addr_hi_reg);
> @@ -197,7 +202,7 @@ static int __sev_do_cmd_locked(int cmd, void *data, int
> *psp_ret)
> }
>
> print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data,
> - sev_cmd_buffer_len(cmd), false);
> + buf_len, false);
>
> return ret;
> }
>
[PATCH v2 0/1] dmaengine: idxd: IDXD pmu support
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 Accelerator [1]), which I'm hoping can go into 5.13. I'm also hoping to supply a couple follow-on patches in the near future, but I'm not yet sure how much sense they make, so I thought I'd throw a couple ideas out there and maybe get some opinions before going forward with them: - The perf userspace interface for this isn't exactly user-friedly, in that you currently need to specify numeric values for field values: # perf stat -e dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7, filter_eng=0x1,event=0x8,event_category=0x3/ It would be nicer to be able to specify those values symbolically instead, and the way to do that seems to be via some JSON files in perf userspace. - Some of the DSA pmu support is patterned after existing uncore code, and there seems to be at least some opportunity to consolidate some of the things they both do into common code, such as the cpumask device attributes and related cpu hotplug support. At this point I'm not sure how much sense it makes to put any effort into that, 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 Tom Zanussi (1): dmaengine: idxd: Add IDXD performance monitor support drivers/dma/Kconfig | 13 + drivers/dma/idxd/Makefile| 2 + drivers/dma/idxd/idxd.h | 45 +++ drivers/dma/idxd/init.c | 9 + drivers/dma/idxd/irq.c | 5 +- drivers/dma/idxd/perfmon.c | 653 +++ drivers/dma/idxd/perfmon.h | 119 +++ drivers/dma/idxd/registers.h | 108 ++ include/linux/cpuhotplug.h | 1 + 9 files changed, 951 insertions(+), 4 deletions(-) create mode 100644 drivers/dma/idxd/perfmon.c create mode 100644 drivers/dma/idxd/perfmon.h -- 2.17.1
[PATCH v2 1/1] dmaengine: idxd: Add IDXD performance monitor support
dsa0/event=0x2,event_category=0x1/
19 dsa0/event=0x4,event_category=0x1/
19 dsa0/event=0x8,event_category=0x1/
0 dsa0/event=0x10,event_category=0x1/
19 dsa0/event=0x20,event_category=0x1/
21.977436186 seconds time elapsed
The command below illustrates filter usage with a simple example. It
specifies that MEM_MOVE operations should be counted for the DSA
device dsa0 (event 0x8 corresponds to the EV_MEM_MOVE event - Number
of Memory Move Descriptors, which is part of event category 0x3 -
Operations. The detailed category and event IDs are available in
Appendix D, Performance Monitoring Events, of [1]). In addition to
the event and event category, a number of filters are also specified
(the detailed filter values are available in Chapter 6.4 (Filter
Support) of [1]), which will restrict counting to only those events
that meet all of the filter criteria. In this case, the filters
specify that only MEM_MOVE operations that are serviced by work queue
wq0 and specifically engine number engine0 and traffic class tc0
having sizes between 0 and 4k and page size of between 0 and 1G result
in a counter hit; anything else will be filtered out and not appear in
the final count. Note that filters are optional - any filter not
specified is assumed to be all ones and will pass anything.
# perf stat -e dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7,
filter_eng=0x1,event=0x8,event_category=0x3/
modprobe dmatest channel=dma0chan0 timeout=2000
iterations=19 run=1 wait=1
Performance counter stats for 'system wide':
19 dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7,
filter_eng=0x1,event=0x8,event_category=0x3/
21.865914091 seconds time elapsed
The output above reflects that the unspecified workload resulted in
the counting of 19 MEM_MOVE operation events that met the filter
criteria.
[1]:
https://software.intel.com/content/www/us/en/develop/download/intel-data-streaming-accelerator-preliminary-architecture-specification.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/idxd/irq.c | 5 +-
drivers/dma/idxd/perfmon.c | 653 +++
drivers/dma/idxd/perfmon.h | 119 +++
drivers/dma/idxd/registers.h | 108 ++
include/linux/cpuhotplug.h | 1 +
9 files changed, 951 insertions(+), 4 deletions(-)
create mode 100644 drivers/dma/idxd/perfmon.c
create mode 100644 drivers/dma/idxd/perfmon.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 0c2827fd8c19..fa945420e346 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -300,6 +300,19 @@ config INTEL_IDXD_SVM
depends on PCI_PASID
depends on PCI_IOV
+config INTEL_IDXD_PERFMON
+ bool "Intel Data Accelerators performance monitor support"
+ depends on INTEL_IDXD
+ default y
+ help
+ Enable performance monitor (pmu) support for the Intel(R)
+ data accelerators present in Intel Xeon CPU. With this
+ enabled, perf can be used to monitor the DSA (Intel Data
+ Streaming Accelerator) events described in the Intel DSA
+ spec.
+
+ If unsure, say N.
+
config INTEL_IOATDMA
tristate "Intel I/OAT DMA support"
depends on PCI && X86_64
diff --git a/drivers/dma/idxd/Makefile b/drivers/dma/idxd/Makefile
index 8978b898d777..6d11558756f8 100644
--- a/drivers/dma/idxd/Makefile
+++ b/drivers/dma/idxd/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_INTEL_IDXD) += idxd.o
idxd-y := init.o irq.o device.o sysfs.o submit.o dma.o cdev.o
+
+idxd-$(CONFIG_INTEL_IDXD_PERFMON) += perfmon.o
diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index 81a0e65fd316..bde819f30916 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include "registers.h"
#define IDXD_DRIVER_VERSION"1.00"
@@ -25,6 +27,7 @@ enum idxd_type {
};
#define IDXD_NAME_SIZE 128
+#define IDXD_PMU_EVENT_MAX 64
struct idxd_device_driver {
struct device_driver drv;
@@ -56,6 +59,31 @@ struct idxd_group {
int tc_b;
};
+struct idxd_pmu {
+ struct idxd_device *idxd;
+
+ struct perf_event *event_list[IDXD_PMU_EVENT_MAX];
+ int n_events;
+
+ DECLARE_BITMAP(used_mask, IDXD_PMU_EVENT_MAX);
+
+ struct pmu pmu;
+ char name[IDXD_NAME_SIZE];
+ int cpu;
+
+ int n_counters;
+ int counter_width;
+ int n_event_categories;
+
+ bool per_counter_caps_supported;
+ unsigned long supported_event_categ
[PATCH 1/1] dmaengine: idxd: Add IDXD performance monitor support
dsa0/event=0x2,event_category=0x1/
19 dsa0/event=0x4,event_category=0x1/
19 dsa0/event=0x8,event_category=0x1/
0 dsa0/event=0x10,event_category=0x1/
19 dsa0/event=0x20,event_category=0x1/
21.977436186 seconds time elapsed
The command below illustrates filter usage with a simple example. It
specifies that MEM_MOVE operations should be counted for the DSA
device dsa0 (event 0x8 corresponds to the EV_MEM_MOVE event - Number
of Memory Move Descriptors, which is part of event category 0x3 -
Operations. The detailed category and event IDs are available in
Appendix D, Performance Monitoring Events, of [1]). In addition to
the event and event category, a number of filters are also specified
(the detailed filter values are available in Chapter 6.4 (Filter
Support) of [1]), which will restrict counting to only those events
that meet all of the filter criteria. In this case, the filters
specify that only MEM_MOVE operations that are serviced by work queue
wq0 and specifically engine number engine0 and traffic class tc0
having sizes between 0 and 4k and page size of between 0 and 1G result
in a counter hit; anything else will be filtered out and not appear in
the final count. Note that filters are optional - any filter not
specified is assumed to be all ones and will pass anything.
# perf stat -e dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7,
filter_eng=0x1,event=0x8,event_category=0x3/
modprobe dmatest channel=dma0chan0 timeout=2000
iterations=19 run=1 wait=1
Performance counter stats for 'system wide':
19 dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7,
filter_eng=0x1,event=0x8,event_category=0x3/
21.865914091 seconds time elapsed
The output above reflects that the unspecified workload resulted in
the counting of 19 MEM_MOVE operation events that met the filter
criteria.
[1]:
https://software.intel.com/content/www/us/en/develop/download/intel-data-streaming-accelerator-preliminary-architecture-specification.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/idxd/irq.c | 5 +-
drivers/dma/idxd/perfmon.c | 661 +++
drivers/dma/idxd/perfmon.h | 119 +++
drivers/dma/idxd/registers.h | 108 ++
include/linux/cpuhotplug.h | 1 +
9 files changed, 959 insertions(+), 4 deletions(-)
create mode 100644 drivers/dma/idxd/perfmon.c
create mode 100644 drivers/dma/idxd/perfmon.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 0c2827fd8c19..fa945420e346 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -300,6 +300,19 @@ config INTEL_IDXD_SVM
depends on PCI_PASID
depends on PCI_IOV
+config INTEL_IDXD_PERFMON
+ bool "Intel Data Accelerators performance monitor support"
+ depends on INTEL_IDXD
+ default y
+ help
+ Enable performance monitor (pmu) support for the Intel(R)
+ data accelerators present in Intel Xeon CPU. With this
+ enabled, perf can be used to monitor the DSA (Intel Data
+ Streaming Accelerator) events described in the Intel DSA
+ spec.
+
+ If unsure, say N.
+
config INTEL_IOATDMA
tristate "Intel I/OAT DMA support"
depends on PCI && X86_64
diff --git a/drivers/dma/idxd/Makefile b/drivers/dma/idxd/Makefile
index 8978b898d777..6d11558756f8 100644
--- a/drivers/dma/idxd/Makefile
+++ b/drivers/dma/idxd/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_INTEL_IDXD) += idxd.o
idxd-y := init.o irq.o device.o sysfs.o submit.o dma.o cdev.o
+
+idxd-$(CONFIG_INTEL_IDXD_PERFMON) += perfmon.o
diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index 81a0e65fd316..bde819f30916 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include "registers.h"
#define IDXD_DRIVER_VERSION"1.00"
@@ -25,6 +27,7 @@ enum idxd_type {
};
#define IDXD_NAME_SIZE 128
+#define IDXD_PMU_EVENT_MAX 64
struct idxd_device_driver {
struct device_driver drv;
@@ -56,6 +59,31 @@ struct idxd_group {
int tc_b;
};
+struct idxd_pmu {
+ struct idxd_device *idxd;
+
+ struct perf_event *event_list[IDXD_PMU_EVENT_MAX];
+ int n_events;
+
+ DECLARE_BITMAP(used_mask, IDXD_PMU_EVENT_MAX);
+
+ struct pmu pmu;
+ char name[IDXD_NAME_SIZE];
+ int cpu;
+
+ int n_counters;
+ int counter_width;
+ int n_event_categories;
+
+ bool per_counter_caps_supported;
+ unsigned long supported_event_categ
[PATCH 0/1] dmaengine: idxd: IDXD pmu support
Hi, This patchset implements initial pmu support for the Intel DSA (Data Streaming Accelerator [1]), which I'm hoping can go into 5.13. I'm also hoping to supply a couple follow-on patches in the near future, but I'm not yet sure how much sense they make, so I thought I'd throw a couple ideas out there and maybe get some opinions before going forward with them: - The perf userspace interface for this isn't exactly user-friedly, in that you currently need to specify numeric values for field values: # perf stat -e dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7, filter_eng=0x1,event=0x8,event_category=0x3/ It would be nicer to be able to specify those values symbolically instead, and the way to do that seems to be via some JSON files in perf userspace. - Some of the DSA pmu support is patterned after existing uncore code, and there seems to be at least some opportunity to consolidate some of the things they both do into common code, such as the cpumask device attributes and related cpu hotplug support. At this point I'm not sure how much sense it makes to put any effort into that, 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-accelerator-preliminary-architecture-specification.html Tom Zanussi (1): dmaengine: idxd: Add IDXD performance monitor support drivers/dma/Kconfig | 13 + drivers/dma/idxd/Makefile| 2 + drivers/dma/idxd/idxd.h | 45 +++ drivers/dma/idxd/init.c | 9 + drivers/dma/idxd/irq.c | 5 +- drivers/dma/idxd/perfmon.c | 661 +++ drivers/dma/idxd/perfmon.h | 119 +++ drivers/dma/idxd/registers.h | 108 ++ include/linux/cpuhotplug.h | 1 + 9 files changed, 959 insertions(+), 4 deletions(-) create mode 100644 drivers/dma/idxd/perfmon.c create mode 100644 drivers/dma/idxd/perfmon.h -- 2.17.1
Re: [PATCH RFC 0/3] Adds support to allow the bitstream configuration from pre-allocated dma-buffer
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 from a pre-allocated buffer > fpga: zynqmp: Use the scatterlist interface > > .../devicetree/bindings/fpga/fpga-region.txt | 2 + > drivers/fpga/fpga-mgr.c | 126 +- > drivers/fpga/of-fpga-region.c | 3 + > drivers/fpga/zynqmp-fpga.c| 35 + > include/linux/fpga/fpga-mgr.h | 6 +- > 5 files changed, 169 insertions(+), 3 deletions(-) >
Re: [PATCH V4 XRT Alveo 13/20] fpga: xrt: User Clock Subsystem platform driver
On 3/23/21 10:29 PM, Lizhi Hou wrote:
> Add User Clock Subsystem (UCS) driver. UCS is a hardware function
ok
> discovered by walking xclbin metadata. A platform device node will be
> created for it. UCS enables/disables the dynamic region clocks.
>
> Signed-off-by: Sonal Santan
> Signed-off-by: Max Zhen
> Signed-off-by: Lizhi Hou
> ---
> drivers/fpga/xrt/lib/xleaf/ucs.c | 167 +++
ok on removing ucs.h
> 1 file changed, 167 insertions(+)
> create mode 100644 drivers/fpga/xrt/lib/xleaf/ucs.c
>
> diff --git a/drivers/fpga/xrt/lib/xleaf/ucs.c
> b/drivers/fpga/xrt/lib/xleaf/ucs.c
> new file mode 100644
> index ..d91ee229e7cb
> --- /dev/null
> +++ b/drivers/fpga/xrt/lib/xleaf/ucs.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx Alveo FPGA UCS Driver
> + *
> + * Copyright (C) 2020-2021 Xilinx, Inc.
> + *
> + * Authors:
> + * Lizhi Hou
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "metadata.h"
> +#include "xleaf.h"
> +#include "xleaf/clock.h"
> +
> +#define UCS_ERR(ucs, fmt, arg...) \
> + xrt_err((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_WARN(ucs, fmt, arg...) \
> + xrt_warn((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_INFO(ucs, fmt, arg...) \
> + xrt_info((ucs)->pdev, fmt "\n", ##arg)
> +#define UCS_DBG(ucs, fmt, arg...) \
> + xrt_dbg((ucs)->pdev, fmt "\n", ##arg)
> +
> +#define XRT_UCS "xrt_ucs"
> +
> +#define XRT_UCS_CHANNEL1_REG 0
> +#define XRT_UCS_CHANNEL2_REG 8
> +
> +#define CLK_MAX_VALUE6400
> +
> +static const struct regmap_config ucs_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x1000,
> +};
> +
> +struct xrt_ucs {
> + struct platform_device *pdev;
> + struct regmap *regmap;
ok
> + struct mutexucs_lock; /* ucs dev lock */
> +};
> +
> +static void xrt_ucs_event_cb(struct platform_device *pdev, void *arg)
> +{
> + struct xrt_event *evt = (struct xrt_event *)arg;
> + enum xrt_events e = evt->xe_evt;
> + struct platform_device *leaf;
> + enum xrt_subdev_id id;
> + int instance;
> +
> + id = evt->xe_subdev.xevt_subdev_id;
> + instance = evt->xe_subdev.xevt_subdev_instance;
> +
> + if (e != XRT_EVENT_POST_CREATION) {
> + xrt_dbg(pdev, "ignored event %d", e);
> + return;
> + }
> +
> + if (id != XRT_SUBDEV_CLOCK)
> + return;
ok
> +
> + leaf = xleaf_get_leaf_by_id(pdev, 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_check.
> +
> +static int ucs_enable(struct xrt_ucs *ucs)
> +{
> + int ret;
> +
> + mutex_lock(>ucs_lock);
ok
> + ret = regmap_write(ucs->regmap, XRT_UCS_CHANNEL2_REG, 1);
> + mutex_unlock(>ucs_lock);
> +
> + return ret;
> +}
> +
> +static int
> +xrt_ucs_leaf_call(struct platform_device *pdev, u32 cmd, void *arg)
ok
Looks fine.
Reviewed-by: Tom Rix
> +{
> + switch (cmd) {
> + case XRT_XLEAF_EVENT:
> + xrt_ucs_event_cb(pdev, arg);
> + break;
> + default:
> + xrt_err(pdev, "unsupported cmd %d", cmd);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int ucs_probe(struct platform_device *pdev)
> +{
> + struct xrt_ucs *ucs = NULL;
> + void __iomem *base = NULL;
> + struct resource *res;
> +
> + ucs = devm_kzalloc(>dev, sizeof(*ucs), GFP_KERNEL);
> + if (!ucs)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, ucs);
> + ucs->pdev = pdev;
> + mutex_init(>ucs_lock);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + ucs->regmap = devm_regmap_init_mmio(>dev, base,
> _regmap_config);
> + if (IS_ERR(ucs->regmap)) {
> + UCS_ERR(ucs, "map base %pR failed", res);
> + return PTR_ERR(ucs->regmap);
> + }
>
Re: [PATCH V4 XRT Alveo 12/20] fpga: xrt: VSEC platform driver
ec->pdev, "failed to get bar off, ret %d", ret);
> + return -EINVAL;
> + }
> +
> + xrt_info(vsec->pdev, "Map vsec at bar %d, offset 0x%llx",
> + be32_to_cpu(*bar), be64_to_cpu(*bar_off));
> +
> + xleaf_get_barres(vsec->pdev, , be32_to_cpu(*bar));
> + if (!res) {
> + xrt_err(vsec->pdev, "failed to get bar addr");
> + return -EINVAL;
> + }
> +
> + addr = res->start + be64_to_cpu(*bar_off);
> +
> + base = devm_ioremap(>pdev->dev, addr,
> vsec_regmap_config.max_register);
> + if (!base) {
> + xrt_err(vsec->pdev, "Map failed");
> + return -EIO;
> + }
> +
> + vsec->regmap = devm_regmap_init_mmio(>pdev->dev, base,
> _regmap_config);
> + if (IS_ERR(vsec->regmap)) {
> + xrt_err(vsec->pdev, "regmap %pR failed", res);
> + return PTR_ERR(vsec->regmap);
> + }
> +
> + ret = regmap_read(vsec->regmap, VSEC_REG_LENGTH, >length);
> + if (ret) {
> + xrt_err(vsec->pdev, "failed to read length %d", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int xrt_vsec_remove(struct platform_device *pdev)
> +{
> + struct xrt_vsec *vsec;
> +
> + vsec = platform_get_drvdata(pdev);
> +
> + if (vsec->group >= 0)
> + xleaf_destroy_group(pdev, vsec->group);
> + vfree(vsec->metadata);
> +
> + return 0;
> +}
> +
> +static int xrt_vsec_probe(struct platform_device *pdev)
> +{
> + struct xrt_vsec *vsec;
> + int ret = 0;
> +
> + vsec = devm_kzalloc(>dev, sizeof(*vsec), GFP_KERNEL);
> + if (!vsec)
> + return -ENOMEM;
> +
> + vsec->pdev = pdev;
> + vsec->group = -1;
> + platform_set_drvdata(pdev, vsec);
> +
> + ret = xrt_vsec_mapio(vsec);
> + if (ret)
> + goto failed;
> +
> + ret = xrt_vsec_create_metadata(vsec);
> + if (ret) {
> + xrt_err(pdev, "create metadata failed, ret %d", ret);
> + goto failed;
> + }
> + vsec->group = xleaf_create_group(pdev, vsec->metadata);
> + if (ret < 0) {
this is a bug, ret is not set by xleaf_create_group
Tom
> + xrt_err(pdev, "create group failed, ret %d", vsec->group);
> + ret = vsec->group;
> + goto failed;
> + }
> +
> + return 0;
> +
> +failed:
> + xrt_vsec_remove(pdev);
> +
> + return ret;
> +}
> +
> +static struct xrt_subdev_endpoints xrt_vsec_endpoints[] = {
> + {
> + .xse_names = (struct xrt_subdev_ep_names []){
> + { .ep_name = XRT_MD_NODE_VSEC },
> + { NULL },
> + },
> + .xse_min_ep = 1,
> + },
> + { 0 },
> +};
> +
> +static struct xrt_subdev_drvdata xrt_vsec_data = {
> + .xsd_dev_ops = {
> + .xsd_leaf_call = xrt_vsec_leaf_call,
> + },
> +};
> +
> +static const struct platform_device_id xrt_vsec_table[] = {
> + { XRT_VSEC, (kernel_ulong_t)_vsec_data },
> + { },
> +};
> +
> +static struct platform_driver xrt_vsec_driver = {
> + .driver = {
> + .name = XRT_VSEC,
> + },
> + .probe = xrt_vsec_probe,
> + .remove = xrt_vsec_remove,
> + .id_table = xrt_vsec_table,
> +};
> +
> +XRT_LEAF_INIT_FINI_FUNC(XRT_SUBDEV_VSEC, vsec);
Re: [Linux-cifsd-devel] [PATCH] cifsd: use kfree to free memory allocated by kzalloc
On 4/1/2021 9:36 AM, Namjae Jeon wrote:
2021-04-01 22:14 GMT+09:00, Ralph Boehme :
Am 4/1/21 um 2:59 PM schrieb Namjae Jeon:
2021-04-01 21:50 GMT+09:00, Ralph Boehme :
fwiw, while at it what about renaming everything that still references
"cifs" to "smb" ? This is not the 90's... :)
It is also used with the name "ksmbd". So function and variable prefix
are used with ksmbd.
well, I was thinking of this:
> +++ b/fs/cifsd/...
We should really stop using the name cifs for modern implementation of
SMB{23} and the code should not be added as fs/cifsd/ to the kernel.
As I know, currently "cifs" is being used for the subdirectory name
for historical reasons and to avoid confusions, even though the CIFS
(SMB1) dialect is no longer recommended.
I'm with Ralph. CIFS is history that we need to relegate to the past.
I also agree that wrappers around core memory allocators are to
be avoided.
Tom.
Re: [PATCH V4 XRT Alveo 10/20] fpga: xrt: main platform driver for management function device
; +
> >xmmigas_section_size);
> + }
> + break;
> + }
> + case XRT_MGMT_MAIN_GET_VBNV: {
> + char **vbnv_p = (char **)arg;
> +
> + *vbnv_p = xmgmt_get_vbnv(pdev);
> + if (!*vbnv_p)
> + ret = -EINVAL;
ok
> + break;
> + }
> + default:
> + xrt_err(pdev, "unknown cmd: %d", cmd);
> + ret = -EINVAL;
> + break;
> + }
> + return ret;
> +}
> +
> +static int xmgmt_main_open(struct inode *inode, struct file *file)
> +{
> + struct platform_device *pdev = xleaf_devnode_open(inode);
> +
> + /* Device may have gone already when we get here. */
> + if (!pdev)
> + return -ENODEV;
> +
> + xrt_info(pdev, "opened");
> + file->private_data = platform_get_drvdata(pdev);
> + return 0;
> +}
> +
> +static int xmgmt_main_close(struct inode *inode, struct file *file)
> +{
> + struct xmgmt_main *xmm = file->private_data;
> +
> + xleaf_devnode_close(inode);
> +
> + xrt_info(xmm->pdev, "closed");
> + return 0;
> +}
> +
> +/*
> + * Called for xclbin download xclbin load ioctl.
> + */
> +static int xmgmt_bitstream_axlf_fpga_mgr(struct xmgmt_main *xmm, void *axlf,
> size_t size)
> +{
> + int ret;
> +
> + WARN_ON(!mutex_is_locked(>lock));
> +
> + /*
> + * Should any error happens during download, we can't trust
> + * the cached xclbin any more.
> + */
> + vfree(xmm->firmware_ulp);
> + xmm->firmware_ulp = NULL;
> +
> + ret = xmgmt_process_xclbin(xmm->pdev, xmm->fmgr, axlf, XMGMT_ULP);
> + if (ret == 0)
> + xmm->firmware_ulp = axlf;
> +
> + return ret;
> +}
> +
> +static int bitstream_axlf_ioctl(struct xmgmt_main *xmm, const void __user
> *arg)
> +{
> + struct xmgmt_ioc_bitstream_axlf ioc_obj = { 0 };
> + struct axlf xclbin_obj = { {0} };
> + size_t copy_buffer_size = 0;
> + void *copy_buffer = NULL;
> + int ret = 0;
> +
> + if (copy_from_user((void *)_obj, arg, sizeof(ioc_obj)))
> + return -EFAULT;
> + if (copy_from_user((void *)_obj, ioc_obj.xclbin,
> sizeof(xclbin_obj)))
> + return -EFAULT;
> + if (memcmp(xclbin_obj.magic, XCLBIN_VERSION2, sizeof(XCLBIN_VERSION2)))
> + return -EINVAL;
> +
> + copy_buffer_size = xclbin_obj.header.length;
> + if (copy_buffer_size > XCLBIN_MAX_SIZE || copy_buffer_size <
> sizeof(xclbin_obj))
ok
Tom
> + return -EINVAL;
> + if (xclbin_obj.header.version_major != XMGMT_SUPP_XCLBIN_MAJOR)
> + return -EINVAL;
> +
> + copy_buffer = vmalloc(copy_buffer_size);
> + if (!copy_buffer)
> + return -ENOMEM;
> +
> + if (copy_from_user(copy_buffer, ioc_obj.xclbin, copy_buffer_size)) {
> + vfree(copy_buffer);
> + return -EFAULT;
> + }
> +
> + ret = xmgmt_bitstream_axlf_fpga_mgr(xmm, copy_buffer, copy_buffer_size);
> + if (ret)
> + vfree(copy_buffer);
> +
> + return ret;
> +}
> +
> +static long xmgmt_main_ioctl(struct file *filp, unsigned int cmd, unsigned
> long arg)
> +{
> + struct xmgmt_main *xmm = filp->private_data;
> + long result = 0;
> +
> + if (_IOC_TYPE(cmd) != XMGMT_IOC_MAGIC)
> + return -ENOTTY;
> +
> + mutex_lock(>lock);
> +
> + xrt_info(xmm->pdev, "ioctl cmd %d, arg %ld", cmd, arg);
> + switch (cmd) {
> + case XMGMT_IOCICAPDOWNLOAD_AXLF:
> + result = bitstream_axlf_ioctl(xmm, (const void __user *)arg);
> + break;
> + default:
> + result = -ENOTTY;
> + break;
> + }
> +
> + mutex_unlock(>lock);
> + return result;
> +}
> +
> +static struct xrt_subdev_endpoints xrt_mgmt_main_endpoints[] = {
> + {
> + .xse_names = (struct xrt_subdev_ep_names []){
> + { .ep_name = XRT_MD_NODE_MGMT_MAIN },
> + { NULL },
> + },
> + .xse_min_ep = 1,
> + },
> + { 0 },
> +};
> +
> +static struct xrt_subdev_drvdata xmgmt_main_data = {
> + .xsd_dev_ops = {
> + .xsd_leaf_call = xmgmt_mainleaf_call,
> + },
> + .xsd_file_ops = {
> + .xsf_ops = {
> + .owner = THIS_MODULE,
> + .open = xmgmt_main_ope
Re: [PATCH V4 XRT Alveo 11/20] fpga: xrt: fpga-mgr and region implementation for xclbin download
n -ENOMEM;
> +
> + info->buf = xclbin;
> + info->count = xclbin_obj->header.length;
> + info->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> + region->info = info;
> + rc = fpga_region_program_fpga(region);
> + if (rc) {
> + xrt_err(pdev, "programming xclbin failed, rc %d", rc);
> + return rc;
> + }
> +
> + /* free bridges to allow reprogram */
> + if (region->get_bridges)
> + fpga_bridges_put(>bridge_list);
> +
> + /*
> + * Next bringup the subdevs for this region which will be managed by
> + * its own group object.
> + */
> + r_data->group_instance = xleaf_create_group(pdev, dtb);
> + if (r_data->group_instance < 0) {
> + xrt_err(pdev, "failed to create group, rc %d",
> + r_data->group_instance);
> + rc = r_data->group_instance;
> + return rc;
> + }
> +
> + rc = xleaf_wait_for_group_bringup(pdev);
> + if (rc)
> + xrt_err(pdev, "group bringup failed, rc %d", rc);
> + return rc;
> +}
> +
> +static int xmgmt_get_bridges(struct fpga_region *region)
> +{
> + struct xmgmt_region *r_data = region->priv;
> + struct device *dev = _data->pdev->dev;
> +
> + return fpga_bridge_get_to_list(dev, region->info, >bridge_list);
> +}
> +
> +/*
> + * Program/create FPGA regions based on input xclbin file.
ok, dropped sentence
> + * 1. Identify a matching existing region for this xclbin
> + * 2. Tear down any previous objects for the found region
> + * 3. Program this region with input xclbin
> + * 4. Iterate over this region's interface uuids to determine if it defines
> any
> + *child region. Create fpga_region for the child region.
> + */
> +int xmgmt_process_xclbin(struct platform_device *pdev,
> + struct fpga_manager *fmgr,
> + const struct axlf *xclbin,
> + enum provider_kind kind)
> +{
> + struct fpga_region *region, *compat_region = NULL;
> + struct xmgmt_region_match_arg arg = { 0 };
ok
> + struct xmgmt_region *r_data;
> + uuid_t compat_uuid;
> + char *dtb = NULL;
> + int rc, i;
> +
> + rc = xrt_xclbin_get_metadata(DEV(pdev), xclbin, );
> + if (rc) {
> + xrt_err(pdev, "failed to get dtb: %d", rc);
> + goto failed;
> + }
> +
> + rc = xrt_md_get_interface_uuids(DEV(pdev), dtb, 0, NULL);
> + if (rc < 0) {
> + xrt_err(pdev, "failed to get intf uuid");
> + rc = -EINVAL;
ok
> + goto failed;
> + }
> + arg.uuid_num = rc;
> + arg.uuids = vzalloc(sizeof(uuid_t) * arg.uuid_num);
uuids small, convert to bzalloc
> + if (!arg.uuids) {
> + rc = -ENOMEM;
> + goto failed;
> + }
> + arg.pdev = pdev;
> +
> + rc = xrt_md_get_interface_uuids(DEV(pdev), dtb, arg.uuid_num,
> arg.uuids);
> + if (rc != arg.uuid_num) {
> + xrt_err(pdev, "only get %d uuids, expect %d", rc, arg.uuid_num);
> + rc = -EINVAL;
> + goto failed;
> + }
> +
> + /* if this is not base firmware, search for a compatible region */
> + if (kind != XMGMT_BLP) {
> + compat_region = fpga_region_class_find(NULL, ,
> xmgmt_region_match);
> + if (!compat_region) {
> + xrt_err(pdev, "failed to get compatible region");
> + rc = -ENOENT;
> + goto failed;
> + }
> +
> + xmgmt_region_cleanup(compat_region);
> +
> + rc = xmgmt_region_program(compat_region, xclbin, dtb);
> + if (rc) {
> + xrt_err(pdev, "failed to program region");
> + goto failed;
> + }
> + }
> +
> + if (compat_region)
> + import_uuid(_uuid, (const char
> *)compat_region->compat_id);
> +
> + /* create all the new regions contained in this xclbin */
> + for (i = 0; i < arg.uuid_num; i++) {
> + if (compat_region && uuid_equal(_uuid, [i])) {
> + /* region for this interface already exists */
> + continue;
> + }
> +
> + region = fpga_region_create(DEV(pdev), fmgr, xmgmt_get_bridges);
> + if (!region) {
> + xrt_err(pdev, "failed to create fpga region");
> + rc = -EFAULT;
> + goto failed;
> + }
> + r_data = devm_kzalloc(DEV(pdev), sizeof(*r_data), GFP_KERNEL);
> + if (!r_data) {
> + rc = -ENOMEM;
> + fpga_region_free(region);
> + goto failed;
> + }
> + r_data->pdev = pdev;
> + r_data->region = region;
> + r_data->group_instance = -1;
> + uuid_copy(_data->intf_uuid, [i]);
> + if (compat_region)
> + import_uuid(_data->dep_uuid, (const char
> *)compat_region->compat_id);
> + r_data->bridge = xmgmt_create_bridge(pdev, dtb);
> + if (!r_data->bridge) {
> + xrt_err(pdev, "failed to create fpga bridge");
> + rc = -EFAULT;
> + devm_kfree(DEV(pdev), r_data);
> + fpga_region_free(region);
> + goto failed;
> + }
> +
> + region->compat_id = _data->compat_id;
> + export_uuid((char *)region->compat_id, _data->intf_uuid);
> + region->priv = r_data;
> +
> + rc = fpga_region_register(region);
> + if (rc) {
> + xrt_err(pdev, "failed to register fpga region");
> + xmgmt_destroy_bridge(r_data->bridge);
> + fpga_region_free(region);
> + devm_kfree(DEV(pdev), r_data);
> + goto failed;
> + }
> +
> + xrt_info(pdev, "created fpga region %llx%llx",
> + region->compat_id->id_l, region->compat_id->id_h);
see above comment on id_h
destroy's info used %llx.%llx, for consistency need to add or remove a '.'
Tom
> + }
> +
> + if (compat_region)
> + put_device(_region->dev);
> + vfree(dtb);
> + return 0;
> +
> +failed:
> + if (compat_region) {
> + put_device(_region->dev);
> + xmgmt_region_cleanup(compat_region);
> + } else {
> + xmgmt_region_cleanup_all(pdev);
> + }
> +
> + vfree(dtb);
> + return rc;
> +}
Re: [PATCH V4 XRT Alveo 09/20] fpga: xrt: management physical function driver (root)
h_slot_and_restore);
> +}
> +
> +static void xmgmt_root_hot_reset(struct pci_dev *pdev)
> +{
> + struct xmgmt *xm = pci_get_drvdata(pdev);
> + struct pci_bus *bus;
> + u8 pci_bctl;
> + u16 pci_cmd, devctl;
> + int i, ret;
> +
> + xmgmt_info(xm, "hot reset start");
> +
> + xmgmt_pci_save_config_all(xm);
> +
> + pci_disable_device(pdev);
> +
> + bus = pdev->bus;
whitespace, all these nl's are not needed
> +
> + /*
> + * When flipping the SBR bit, device can fall off the bus. This is
> + * usually no problem at all so long as drivers are working properly
> + * after SBR. However, some systems complain bitterly when the device
> + * falls off the bus.
> + * The quick solution is to temporarily disable the SERR reporting of
> + * switch port during SBR.
> + */
> +
> + pci_read_config_word(bus->self, PCI_COMMAND, _cmd);
> + pci_write_config_word(bus->self, PCI_COMMAND, (pci_cmd &
> ~PCI_COMMAND_SERR));
> + pcie_capability_read_word(bus->self, PCI_EXP_DEVCTL, );
> + pcie_capability_write_word(bus->self, PCI_EXP_DEVCTL, (devctl &
> ~PCI_EXP_DEVCTL_FERE));
> + pci_read_config_byte(bus->self, PCI_BRIDGE_CONTROL, _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->self, PCI_BRIDGE_CONTROL, pci_bctl);
> + ssleep(1);
> +
> + pcie_capability_write_word(bus->self, PCI_EXP_DEVCTL, devctl);
> + pci_write_config_word(bus->self, PCI_COMMAND, pci_cmd);
> +
> + ret = pci_enable_device(pdev);
> + if (ret)
> + xmgmt_err(xm, "failed to enable device, ret %d", ret);
> +
> + for (i = 0; i < 300; i++) {
> + pci_read_config_word(pdev, PCI_COMMAND, _cmd);
> + if (pci_cmd != 0x)
> + break;
> + msleep(20);
> + }
> + if (i == 300)
> + xmgmt_err(xm, "time'd out waiting for device to be online after
> reset");
time'd -> timed
Tom
> +
> + xmgmt_info(xm, "waiting for %d ms", i * 20);
> + xmgmt_pci_restore_config_all(xm);
> + xmgmt_config_pci(xm);
> +}
> +
> +static int xmgmt_create_root_metadata(struct xmgmt *xm, char **root_dtb)
> +{
> + char *dtb = NULL;
> + int ret;
> +
> + ret = xrt_md_create(XMGMT_DEV(xm), );
> + if (ret) {
> + xmgmt_err(xm, "create metadata failed, ret %d", ret);
> + goto failed;
> + }
> +
> + ret = xroot_add_vsec_node(xm->root, dtb);
> + if (ret == -ENOENT) {
> + /*
> + * We may be dealing with a MFG board.
> + * Try vsec-golden which will bring up all hard-coded leaves
> + * at hard-coded offsets.
> + */
> + ret = xroot_add_simple_node(xm->root, dtb,
> XRT_MD_NODE_VSEC_GOLDEN);
> + } else if (ret == 0) {
> + ret = xroot_add_simple_node(xm->root, dtb,
> XRT_MD_NODE_MGMT_MAIN);
> + }
> + if (ret)
> + goto failed;
> +
> + *root_dtb = dtb;
> + return 0;
> +
> +failed:
> + vfree(dtb);
> + return ret;
> +}
> +
> +static ssize_t ready_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct xmgmt *xm = pci_get_drvdata(pdev);
> +
> + return sprintf(buf, "%d\n", xm->ready);
> +}
> +static DEVICE_ATTR_RO(ready);
> +
> +static struct attribute *xmgmt_root_attrs[] = {
> + _attr_ready.attr,
> + NULL
> +};
> +
> +static struct attribute_group xmgmt_root_attr_group = {
> + .attrs = xmgmt_root_attrs,
> +};
> +
> +static struct xroot_physical_function_callback xmgmt_xroot_pf_cb = {
> + .xpc_hot_reset = xmgmt_root_hot_reset,
> +};
> +
> +static int xmgmt_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> +{
> + int ret;
> + struct device *dev = >dev;
> + struct xmgmt *xm = devm_kzalloc(dev, sizeof(*xm), GFP_KERNEL);
> + char *dtb = NULL;
> +
> + if (!xm)
> + return -ENOMEM;
> + xm->pdev = pdev;
> + pci_set_drvdata(pdev, xm);
> +
> + ret = xmgmt_config_pci(xm);
> + if (ret)
> + goto failed;
> +
> + ret = xroot_probe(pdev, _xroot_pf_cb, >root);
> + if (ret)
> + goto failed;
> +
> + ret = xmgmt_create_root_metadata(xm, );
> + if
Re: [PATCH V4 XRT Alveo 08/20] fpga: xrt: platform driver infrastructure
+ 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;
> +
> + while (!xrt_subdev_pool_get_impl(spool, XRT_SUBDEV_MATCH_NEXT,
> + tgt, spool->xsp_owner, )) {
> + tgt = sdev->xs_pdev;
> + evt.xe_evt = e;
> + evt.xe_subdev.xevt_subdev_id = sdev->xs_id;
> + evt.xe_subdev.xevt_subdev_instance = tgt->id;
> + xrt_subdev_root_request(tgt, XRT_ROOT_EVENT_SYNC, );
> + xrt_subdev_pool_put_impl(spool, tgt, spool->xsp_owner);
> + }
> +}
> +
> +void xrt_subdev_pool_handle_event(struct xrt_subdev_pool *spool, struct
> xrt_event *evt)
> +{
> + struct platform_device *tgt = NULL;
> + struct xrt_subdev *sdev = NULL;
> +
> + while (!xrt_subdev_pool_get_impl(spool, XRT_SUBDEV_MATCH_NEXT,
> + tgt, spool->xsp_owner, )) {
> + tgt = sdev->xs_pdev;
> + xleaf_call(tgt, XRT_XLEAF_EVENT, evt);
> + xrt_subdev_pool_put_impl(spool, tgt, spool->xsp_owner);
> + }
> +}
> +
> +ssize_t xrt_subdev_pool_get_holders(struct xrt_subdev_pool *spool,
> + struct platform_device *pdev, char *buf,
> size_t len)
> +{
> + const struct list_head *ptr;
> + struct mutex *lk = >xsp_lock;
> + struct list_head *dl = >xsp_dev_list;
> + struct xrt_subdev *sdev;
> + ssize_t ret = 0;
> +
> + mutex_lock(lk);
> + list_for_each(ptr, dl) {
> + sdev = list_entry(ptr, struct xrt_subdev, xs_dev_list);
> + if (sdev->xs_pdev != pdev)
> + continue;
> + ret = xrt_subdev_get_holders(sdev, buf, len);
> + break;
> + }
> + mutex_unlock(lk);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(xrt_subdev_pool_get_holders);
> +
> +int xleaf_broadcast_event(struct platform_device *pdev, enum xrt_events evt,
> bool async)
> +{
> + struct xrt_event e = { evt, };
> + enum xrt_root_cmd cmd = async ? XRT_ROOT_EVENT_ASYNC :
> XRT_ROOT_EVENT_SYNC;
> +
> + WARN_ON(evt == XRT_EVENT_POST_CREATION || evt == XRT_EVENT_PRE_REMOVAL);
> + return xrt_subdev_root_request(pdev, cmd, );
> +}
> +EXPORT_SYMBOL_GPL(xleaf_broadcast_event);
> +
> +void xleaf_hot_reset(struct platform_device *pdev)
> +{
> + xrt_subdev_root_request(pdev, XRT_ROOT_HOT_RESET, NULL);
> +}
> +EXPORT_SYMBOL_GPL(xleaf_hot_reset);
> +
> +void xleaf_get_barres(struct platform_device *pdev, struct resource **res,
> uint bar_idx)
> +{
> + struct xrt_root_get_res arg = { 0 };
> +
> + if (bar_idx > PCI_STD_RESOURCE_END) {
> + xrt_err(pdev, "Invalid bar idx %d", bar_idx);
> + *res = NULL;
> + return;
> + }
> +
> + xrt_subdev_root_request(pdev, XRT_ROOT_GET_RESOURCE, );
> +
> + *res = _res[bar_idx];
> +}
> +
> +void xleaf_get_root_id(struct platform_device *pdev, unsigned short *vendor,
> unsigned short *device,
> +unsigned short *subvendor, unsigned short *subdevice)
> +{
> + struct xrt_root_get_id id = { 0 };
> +
> + WARN_ON(!vendor && !device && !subvendor && !subdevice);
ok
Tom
> +
> + xrt_subdev_root_request(pdev, XRT_ROOT_GET_ID, (void *));
> + if (vendor)
> + *vendor = id.xpigi_vendor_id;
> + if (device)
> + *device = id.xpigi_device_id;
> + if (subvendor)
> + *subvendor = id.xpigi_sub_vendor_id;
> + if (subdevice)
> + *subdevice = id.xpigi_sub_device_id;
> +}
> +
> +struct device *xleaf_register_hwmon(struct platform_device *pdev, const char
> *name, void *drvdata,
> + const struct attribute_group **grps)
> +{
> + struct xrt_root_hwmon hm = { true, name, drvdata, grps, };
> +
> + xrt_subdev_root_request(pdev, XRT_ROOT_HWMON, (void *));
> + return hm.xpih_hwmon_dev;
> +}
> +
> +void xleaf_unregister_hwmon(struct platform_device *pdev, struct device
> *hwmon)
> +{
> + struct xrt_root_hwmon hm = { false, };
> +
> + hm.xpih_hwmon_dev = hwmon;
> + xrt_subdev_root_request(pdev, XRT_ROOT_HWMON, (void *));
> +}
Re: [PATCH V4 XRT Alveo 07/20] fpga: xrt: root driver infrastructure
if (r)
> + atomic_inc(>groups.bringup_failed);
> +
> + xroot_group_trigger_event(xr, i, XRT_EVENT_POST_CREATION);
> +
> + if (atomic_dec_and_test(>groups.bringup_pending))
> + complete(>groups.bringup_comp);
> + }
> +}
> +
> +static void xroot_groups_init(struct xroot *xr)
ok
> +{
> + xrt_subdev_pool_init(DEV(xr->pdev), >groups.pool);
> + INIT_WORK(>groups.bringup_work, xroot_bringup_group_work);
> + atomic_set(>groups.bringup_pending, 0);
> + atomic_set(>groups.bringup_failed, 0);
> + init_completion(>groups.bringup_comp);
> +}
> +
> +static void xroot_groups_fini(struct xroot *xr)
> +{
> + flush_scheduled_work();
> + xrt_subdev_pool_fini(>groups.pool);
> +}
> +
> +int xroot_add_vsec_node(void *root, char *dtb)
> +{
> + struct xroot *xr = (struct xroot *)root;
> + struct device *dev = DEV(xr->pdev);
> + struct xrt_md_endpoint ep = { 0 };
> + int cap = 0, ret = 0;
> + u32 off_low, off_high, vsec_bar, header;
> + u64 vsec_off;
> +
> + while ((cap = pci_find_next_ext_capability(xr->pdev, cap,
> PCI_EXT_CAP_ID_VNDR))) {
> + pci_read_config_dword(xr->pdev, cap + PCI_VNDR_HEADER, );
> + if (PCI_VNDR_HEADER_ID(header) == XRT_VSEC_ID)
> + break;
> + }
> + if (!cap) {
> + xroot_info(xr, "No Vendor Specific Capability.");
> + return -ENOENT;
> + }
> +
> + if (pci_read_config_dword(xr->pdev, cap + 8, _low) ||
> + pci_read_config_dword(xr->pdev, cap + 12, _high)) {
> + xroot_err(xr, "pci_read vendor specific failed.");
> + return -EINVAL;
> + }
> +
> + ep.ep_name = XRT_MD_NODE_VSEC;
> + ret = xrt_md_add_endpoint(dev, dtb, );
> + if (ret) {
> + xroot_err(xr, "add vsec metadata failed, ret %d", ret);
> + goto failed;
> + }
> +
> + vsec_bar = cpu_to_be32(off_low & 0xf);
> + ret = xrt_md_set_prop(dev, dtb, XRT_MD_NODE_VSEC, NULL,
> + XRT_MD_PROP_BAR_IDX, _bar, sizeof(vsec_bar));
> + if (ret) {
> + xroot_err(xr, "add vsec bar idx failed, ret %d", ret);
> + goto failed;
> + }
> +
> + vsec_off = cpu_to_be64(((u64)off_high << 32) | (off_low & ~0xfU));
> + ret = xrt_md_set_prop(dev, dtb, XRT_MD_NODE_VSEC, NULL,
> + XRT_MD_PROP_OFFSET, _off, sizeof(vsec_off));
> + if (ret) {
> + xroot_err(xr, "add vsec offset failed, ret %d", ret);
> + goto failed;
> + }
> +
> +failed:
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(xroot_add_vsec_node);
> +
> +int xroot_add_simple_node(void *root, char *dtb, const char *endpoint)
> +{
> + struct xroot *xr = (struct xroot *)root;
> + struct device *dev = DEV(xr->pdev);
> + struct xrt_md_endpoint ep = { 0 };
> + int ret = 0;
> +
> + ep.ep_name = endpoint;
> + ret = xrt_md_add_endpoint(dev, dtb, );
> + if (ret)
> + xroot_err(xr, "add %s failed, ret %d", endpoint, ret);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(xroot_add_simple_node);
> +
> +bool xroot_wait_for_bringup(void *root)
> +{
> + struct xroot *xr = (struct xroot *)root;
> +
> + wait_for_completion(>groups.bringup_comp);
> + return atomic_read(>groups.bringup_failed) == 0;
ok
Tom
> +}
> +EXPORT_SYMBOL_GPL(xroot_wait_for_bringup);
> +
> +int xroot_probe(struct pci_dev *pdev, struct
> xroot_physical_function_callback *cb, void **root)
> +{
> + struct device *dev = DEV(pdev);
> + struct xroot *xr = NULL;
> +
> + dev_info(dev, "%s: probing...", __func__);
> +
> + xr = devm_kzalloc(dev, sizeof(*xr), GFP_KERNEL);
> + if (!xr)
> + return -ENOMEM;
> +
> + xr->pdev = pdev;
> + xr->pf_cb = *cb;
> + xroot_groups_init(xr);
> + xroot_event_init(xr);
> +
> + *root = xr;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(xroot_probe);
> +
> +void xroot_remove(void *root)
> +{
> + struct xroot *xr = (struct xroot *)root;
> + struct platform_device *grp = NULL;
> +
> + xroot_info(xr, "leaving...");
> +
> + if (xroot_get_group(xr, XROOT_GROUP_FIRST, ) == 0) {
> + int instance = grp->id;
> +
> + xroot_put_group(xr, grp);
> + xroot_destroy_group(xr, instance);
> + }
> +
> + xroot_event_fini(xr);
> + xroot_groups_fini(xr);
> +}
> +EXPORT_SYMBOL_GPL(xroot_remove);
> +
> +void xroot_broadcast(void *root, enum xrt_events evt)
> +{
> + struct xroot *xr = (struct xroot *)root;
> + struct xrt_event e = { 0 };
> +
> + /* Root pf driver only broadcasts below two events. */
> + if (evt != XRT_EVENT_POST_CREATION && evt != XRT_EVENT_PRE_REMOVAL) {
> + xroot_info(xr, "invalid event %d", evt);
> + return;
> + }
> +
> + e.xe_evt = evt;
> + e.xe_subdev.xevt_subdev_id = XRT_ROOT;
> + e.xe_subdev.xevt_subdev_instance = 0;
> + xroot_trigger_event(xr, , false);
> +}
> +EXPORT_SYMBOL_GPL(xroot_broadcast);
Re: [PATCH V4 XRT Alveo 06/20] fpga: xrt: char dev node helper functions
nused, remove.
> +
> +struct platform_device *
> +xleaf_devnode_open(struct inode *inode)
> +{
> + return __xleaf_devnode_open(inode, false);
> +}
> +EXPORT_SYMBOL_GPL(xleaf_devnode_open);
does this really need to be exported ?
> +
> +void xleaf_devnode_close(struct inode *inode)
> +{
> + struct xrt_subdev_platdata *pdata = INODE2PDATA(inode);
> + struct platform_device *pdev = INODE2PDEV(inode);
> + bool notify = false;
> +
> + mutex_lock(>xsp_devnode_lock);
> +
> + WARN_ON(pdata->xsp_devnode_ref == 0);
> + pdata->xsp_devnode_ref--;
> + if (pdata->xsp_devnode_ref == 0) {
> + pdata->xsp_devnode_excl = false;
> + notify = true;
> + }
> + if (notify) {
> + xrt_info(pdev, "closed %s, ref=%d",
> + CDEV_NAME(pdata->xsp_sysdev), pdata->xsp_devnode_ref);
xsp_devnode_ref will always be 0, so no need to report it.
> + } else {
> + xrt_info(pdev, "closed %s, notifying waiter",
> + CDEV_NAME(pdata->xsp_sysdev));
> + }
> +
> + mutex_unlock(>xsp_devnode_lock);
> +
> + if (notify)
> + complete(>xsp_devnode_comp);
> +}
> +EXPORT_SYMBOL_GPL(xleaf_devnode_close);
> +
> +static inline enum xrt_subdev_file_mode
> +devnode_mode(struct xrt_subdev_drvdata *drvdata)
> +{
> + return drvdata->xsd_file_ops.xsf_mode;
> +}
> +
> +int xleaf_devnode_create(struct platform_device *pdev, const char *file_name,
> + const char *inst_name)
> +{
> + struct xrt_subdev_drvdata *drvdata = DEV_DRVDATA(pdev);
> + struct xrt_subdev_file_ops *fops = >xsd_file_ops;
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(pdev);
> + struct cdev *cdevp;
> + struct device *sysdev;
> + int ret = 0;
> + char fname[256];
> +
> + mutex_init(>xsp_devnode_lock);
> + init_completion(>xsp_devnode_comp);
> +
> + cdevp = _PDATA(pdev)->xsp_cdev;
> + cdev_init(cdevp, >xsf_ops);
> + cdevp->owner = fops->xsf_ops.owner;
> + cdevp->dev = MKDEV(MAJOR(fops->xsf_dev_t), pdev->id);
> +
> + /*
> + * Set pdev as parent of cdev so that when pdev (and its platform
> + * data) will not be freed when cdev is not freed.
> + */
> + cdev_set_parent(cdevp, (pdev)->kobj);
> +
> + ret = cdev_add(cdevp, cdevp->dev, 1);
> + if (ret) {
> + xrt_err(pdev, "failed to add cdev: %d", ret);
> + goto failed;
> + }
> + if (!file_name)
> + file_name = pdev->name;
> + if (!inst_name) {
> + if (devnode_mode(drvdata) == XRT_SUBDEV_FILE_MULTI_INST) {
> + snprintf(fname, sizeof(fname), "%s/%s/%s.%u",
> + XRT_CDEV_DIR, DEV_PDATA(pdev)->xsp_root_name,
> + file_name, pdev->id);
> + } else {
> + snprintf(fname, sizeof(fname), "%s/%s/%s",
> + XRT_CDEV_DIR, DEV_PDATA(pdev)->xsp_root_name,
> + file_name);
> + }
> + } else {
> + snprintf(fname, 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)) {
> + ret = PTR_ERR(sysdev);
> + xrt_err(pdev, "failed to create device node: %d", ret);
> + goto failed_cdev_add;
> + }
> + pdata->xsp_sysdev = sysdev;
> +
> + xleaf_devnode_allowed(pdev);
> +
> + xrt_info(pdev, "created (%d, %d): /dev/%s",
> + MAJOR(cdevp->dev), pdev->id, fname);
> + return 0;
> +
> +failed_cdev_add:
> + cdev_del(cdevp);
> +failed:
> + cdevp->owner = NULL;
> + return ret;
> +}
> +
> +int xleaf_devnode_destroy(struct platform_device *pdev)
> +{
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(pdev);
> + struct cdev *cdevp = >xsp_cdev;
> + dev_t dev = cdevp->dev;
> + int rc;
> +
> + rc = xleaf_devnode_disallowed(pdev);
> + if (rc)
> + return rc;
Failure of one leaf to be destroyed is not handled well.
could a able to destroy check be done over the whole group ?
Tom
> +
> + xrt_info(pdev, "removed (%d, %d): /dev/%s/%s", MAJOR(dev), MINOR(dev),
> + XRT_CDEV_DIR, CDEV_NAME(pdata->xsp_sysdev));
> + device_destroy(xrt_class, cdevp->dev);
> + pdata->xsp_sysdev = NULL;
> + cdev_del(cdevp);
> + return 0;
> +}
Re: [PATCH V4 XRT Alveo 05/20] fpga: xrt: group platform driver
+ }
> +
> + /* Cleanup - Restore all endpoints that has been deleted, if any. */
> + if (ep_count > 0) {
> + xrt_md_copy_endpoint(DEV(xg->pdev), grp_dtb, dtb,
> + XRT_MD_NODE_ENDPOINTS, NULL, NULL);
> + }
> + vfree(dtb);
> + *dtbp = NULL;
> + return 0;
> +}
> +
> +static int xrt_grp_create_leaves(struct xrt_group *xg)
> +{
> + struct xrt_subdev_platdata *pdata = DEV_PDATA(xg->pdev);
> + struct xrt_subdev_endpoints *eps = NULL;
> + int ret = 0, failed = 0;
> + enum xrt_subdev_id did;
> + char *grp_dtb = NULL;
> + unsigned long mlen;
> +
> + if (!pdata)
> + return -EINVAL;
ok
> +
> + mlen = xrt_md_size(DEV(xg->pdev), pdata->xsp_dtb);
> + if (mlen == XRT_MD_INVALID_LENGTH) {
> + xrt_err(xg->pdev, "invalid dtb, len %ld", mlen);
> + return -EINVAL;
> + }
> +
> + mutex_lock(>lock);
> +
> + if (xg->leaves_created) {
> + mutex_unlock(>lock);
add a comment that this is not an error and/or error is handled elsewhere
> + return -EEXIST;
> + }
> +
> + grp_dtb = vmalloc(mlen);
> + if (!grp_dtb) {
> + mutex_unlock(>lock);
> + return -ENOMEM;
ok
> + }
> +
> + /* Create all leaves based on dtb. */
> + xrt_info(xg->pdev, "bringing up leaves...");
> + memcpy(grp_dtb, pdata->xsp_dtb, mlen);
> + for (did = 0; did < XRT_SUBDEV_NUM; did++) {
ok
> + eps = xrt_drv_get_endpoints(did);
> + while (eps && eps->xse_names) {
> + char *dtb = NULL;
> +
> + ret = xrt_grp_cut_subdev_dtb(xg, eps, grp_dtb, );
> + if (ret) {
> + failed++;
> + xrt_err(xg->pdev, "failed to cut subdev dtb for
> drv %s: %d",
> + xrt_drv_name(did), ret);
> + }
> + if (!dtb) {
> + /*
> + * No more dtb to cut or bad things happened
> for this instance,
> + * switch to the next one.
> + */
> + eps++;
> + continue;
> + }
> +
> + /* Found a dtb for this instance, let's add it. */
> + ret = xrt_subdev_pool_add(>leaves, did,
> xrt_grp_root_cb, xg, dtb);
> + if (ret < 0) {
> + failed++;
> + xrt_err(xg->pdev, "failed to add %s: %d",
> xrt_drv_name(did), ret);
add a comment that this is not a fatal error and cleanup happens elsewhere
Tom
> + }
> + vfree(dtb);
> + /* Continue searching for the same instance from
> grp_dtb. */
> + }
> + }
> +
> + xg->leaves_created = true;
> + vfree(grp_dtb);
> + mutex_unlock(>lock);
> + return failed == 0 ? 0 : -ECHILD;
> +}
> +
> +static void xrt_grp_remove_leaves(struct xrt_group *xg)
> +{
> + mutex_lock(>lock);
> +
> + if (!xg->leaves_created) {
> + mutex_unlock(>lock);
> + return;
> + }
> +
> + xrt_info(xg->pdev, "tearing down leaves...");
> + xrt_subdev_pool_fini(>leaves);
> + xg->leaves_created = false;
> +
> + mutex_unlock(>lock);
> +}
> +
> +static int xrt_grp_probe(struct platform_device *pdev)
> +{
> + struct xrt_group *xg;
> +
> + xrt_info(pdev, "probing...");
> +
> + xg = devm_kzalloc(>dev, sizeof(*xg), GFP_KERNEL);
> + if (!xg)
> + return -ENOMEM;
> +
> + xg->pdev = pdev;
> + mutex_init(>lock);
> + xrt_subdev_pool_init(DEV(pdev), >leaves);
> + platform_set_drvdata(pdev, xg);
> +
> + return 0;
> +}
> +
> +static int xrt_grp_remove(struct platform_device *pdev)
> +{
> + struct xrt_group *xg = platform_get_drvdata(pdev);
> +
> + xrt_info(pdev, "leaving...");
> + xrt_grp_remove_leaves(xg);
> + return 0;
> +}
> +
> +static int xrt_grp_leaf_call(struct platform_device *pdev, u32 cmd, void
> *arg)
> +{
> + int rc = 0;
> + struct xrt_group *xg = platform_get_drvdata(pdev);
> +
> + switch (cmd) {
> + case XRT_XLEAF_EVENT:
> + /* Simply forward to every child. */
>
Re: [PATCH V4 XRT Alveo 04/20] fpga: xrt: xrt-lib platform driver manager
ister_driver(enum xrt_subdev_id id)
> +{
> + struct xrt_drv_map *map;
> +
> + mutex_lock(_lib_lock);
> +
> + map = __xrt_drv_find_map_by_id(id);
> + if (!map) {
> + mutex_unlock(_lib_lock);
> + pr_err("Id %d has no registered driver\n", id);
> + return;
> + }
> +
> + list_del(>list);
> +
> + mutex_unlock(_lib_lock);
> +
> + xrt_drv_unregister_driver(map);
> + kfree(map);
> +}
> +EXPORT_SYMBOL_GPL(xleaf_unregister_driver);
> +
> +const char *xrt_drv_name(enum xrt_subdev_id id)
> +{
> + struct xrt_drv_map *map = xrt_drv_find_map_by_id(id);
> +
> + if (map)
> + return XRT_DRVNAME(map->drv);
> + return NULL;
> +}
> +
> +int xrt_drv_get_instance(enum xrt_subdev_id id)
> +{
> + struct xrt_drv_map *map = xrt_drv_find_map_by_id(id);
> +
> + return ida_alloc_range(>ida, 0, XRT_MAX_DEVICE_NODES, GFP_KERNEL);
> +}
> +
> +void xrt_drv_put_instance(enum xrt_subdev_id id, int instance)
> +{
> + struct xrt_drv_map *map = xrt_drv_find_map_by_id(id);
> +
> + ida_free(>ida, instance);
> +}
> +
> +struct xrt_subdev_endpoints *xrt_drv_get_endpoints(enum xrt_subdev_id id)
> +{
> + struct xrt_drv_map *map = xrt_drv_find_map_by_id(id);
> + struct xrt_subdev_endpoints *eps;
> +
> + eps = map ? map->eps : NULL;
> + return eps;
> +}
> +
> +/* Leaf driver's module init/fini callbacks. */
add comment to effect that dynamically adding drivers/ID'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(_lib_lock);
> +
> + while (!list_empty(_drv_maps)) {
> + map = list_first_entry_or_null(_drv_maps, struct
> xrt_drv_map, list);
> + pr_err("Unloading module with %s still registered\n",
> XRT_DRVNAME(map->drv));
> + list_del(>list);
> + mutex_unlock(_lib_lock);
> + xrt_drv_unregister_driver(map);
> + kfree(map);
> + mutex_lock(_lib_lock);
> + }
> +
> + mutex_unlock(_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_ */
Re: [PATCH 1/1] block: fix trivial typos in comments
On Fri, Mar 26, 2021 at 09:46:36AM -0600, Jens Axboe wrote:
> On 3/26/21 9:45 AM, Tom Saeger wrote:
> > On Fri, Mar 26, 2021 at 09:41:49AM -0600, Jens Axboe wrote:
> >> On 3/25/21 9:04 PM, Tom Saeger wrote:
> >>>
> >>> s/Additonal/Additional/
> >>> s/assocaited/associated/
> >>> s/assocaited/associated/
> >>> s/assocating/associating/
> >>> s/becasue/because/
> >>> s/configred/configured/
> >>> s/deactive/deactivate/
> >>> s/followings/following/
> >>> s/funtion/function/
> >>> s/heirarchy/hierarchy/
> >>> s/intiailized/initialized/
> >>> s/prefered/preferred/
> >>> s/readded/read/
> >>> s/Secion/Section/
> >>> s/soley/solely/
> >>
> >> While I'm generally happy to accept any patch that makes sense, the
> >> recent influx of speling fixes have me less than excited. They just
> >> add complications to backports and stable patches, for example, and
> >> I'd prefer not to take them for that reason alone.
> >
> > Nod.
> >
> > In that case - perhaps adding these entries to scripts/spelling.txt
> > would at least catch some going forward?
> >
> > I can send that.
>
> That seems like a good idea.
>
> --
> Jens Axboe
>
What would be the process - which avoids the backport complications?
Perhaps a few of these could be fixed when other changes are made to these
files?
Granted these are trivial fixes, just trying to understand the process.
Example work-flow based on recent block merge upstream:
$ git log -n1 abed516ecd02ceb30fbd091e9b26205ea3192c65 --oneline
abed516ecd02 Merge tag 'block-5.12-2021-03-27' of
git://git.kernel.dk/linux-block
# get files changed by recent merge (or use commit range of interest)
$ HID=abed516ecd02 ; git diff --name-only "$(git merge-base "${HID}^2"
"${HID}^1")".."${HID}^2"
block/bio.c
block/blk-merge.c
block/partitions/core.c
fs/block_dev.c
# foreach file in recent merge, run checkpatch in typo fix mode
$ HID=abed516ecd02 ; git diff --name-only "$(git merge-base "${HID}^2"
"${HID}^1")".."${HID}^2" \
| xargs ./scripts/checkpatch.pl --strict --fix --fix-inplace --types
TYPO_SPELLING -f | grep -A4 -F "CHECK:"
CHECK: 'splitted' may be misspelled - perhaps 'split'?
#344: FILE: block/blk-merge.c:344:
+ /* there isn't chance to merge the splitted bio */
^^^^
--
CHECK: 'beeing' may be misspelled - perhaps 'being'?
#934: FILE: fs/block_dev.c:934:
+ * or NULL if the inode is already beeing freed.
^^
# what changed?
$ git status -su
M block/blk-merge.c
M fs/block_dev.c
Something similar could be done for other checkpatch modes or other linters.
Just an idea - thoughts?
Regards,
--Tom
Re: [PATCH V4 XRT Alveo 03/20] fpga: xrt: xclbin file helper functions
> + MEM_ARE,
> + MEM_HBM,
> + MEM_BRAM,
> + MEM_URAM,
> + MEM_STREAMING_CONNECTION
> +};
> +
> +enum IP_TYPE {
> + IP_MB = 0,
> + IP_KERNEL,
> + IP_DNASC,
> + IP_DDR4_CONTROLLER,
> + IP_MEM_DDR4,
> + IP_MEM_HBM
> +};
> +
> +struct axlf_section_header {
> + uint32_t section_kind; /* Section type */
> + char section_name[16]; /* Examples: "stage2", "clear1", */
> + /* "clear2", "ocl1", "ocl2, */
> + /* "ublaze", "sched" */
> + char rsvd[4];
> + uint64_t section_offset;/* File offset of section data */
> + uint64_t section_size; /* Size of section data */
> +} __packed;
> +
> +struct axlf_header {
> + uint64_t length;/* Total size of the xclbin file */
> + uint64_t time_stamp;/* Number of seconds since epoch */
> + /* when xclbin was created */
> + uint64_t feature_rom_timestamp; /* TimeSinceEpoch of the featureRom
> */
> + uint16_t version_patch; /* Patch Version */
> + uint8_t version_major; /* Major Version - Version: 2.1.0*/
ok, version checked
whitepace, needs '2.1.0 */'
I see this is a general problem, look other places.
maybe it is a 'tab' and the diff is messing it up, convert tab to space.
> + uint8_t version_minor; /* Minor Version */
> + uint32_t mode; /* XCLBIN_MODE */
> + union {
> + struct {
> + uint64_t platform_id; /* 64 bit platform ID: */
> + /* vendor-device-subvendor-subdev */
> + uint64_t feature_id;/* 64 bit feature id */
> + } rom;
> + unsigned char rom_uuid[16]; /* feature ROM UUID for which */
> + /* this xclbin was generated */
> + };
> + unsigned char platform_vbnv[64];/* e.g. */
> + /* xilinx:xil-accel-rd-ku115:4ddr-xpr:3.4: null terminated */
> + union {
> + char next_axlf[16]; /* Name of next xclbin file */
> + /* in the daisy chain */
> + unsigned char uuid[16]; /* uuid of this xclbin*/
ok
whitespace comment need a ' ' before */
> + };
> + char debug_bin[16]; /* Name of binary with debug */
> + /* information */
> + uint32_t num_sections; /* Number of section headers */
> + char rsvd[4];
> +} __packed;
> +
> +struct axlf {
> + char magic[8]; /* Should be "xclbin2\0" */
> + int32_t signature_length; /* Length of the signature. */
> + /* -1 indicates no signature */
> + unsigned char reserved[28]; /* Note: Initialized to 0xFFs */
> +
> + unsigned char key_block[256]; /* Signature for validation */
> + /* of binary */
> + uint64_t unique_id; /* axlf's uniqueId, use it to */
> + /* skip redownload etc */
> + struct axlf_header header; /* Inline header */
> + struct axlf_section_header sections[1]; /* One or more section */
> + /* headers follow */
> +} __packed;
ok, thanks!
> +
> +/* bitstream information */
> +struct xlnx_bitstream {
> + uint8_t freq[8];
> + char bits[1];
> +} __packed;
> +
> +/MEMORY TOPOLOGY SECTION /
> +struct mem_data {
> + uint8_t type; /* enum corresponding to mem_type. */
> + uint8_t used; /* if 0 this bank is not present */
> + uint8_t rsvd[6];
> + union {
> + uint64_t size; /* if mem_type DDR, then size in KB; */
> + uint64_t route_id; /* if streaming then "route_id" */
> + };
> + union {
> + uint64_t base_address;/* if DDR then the base address; */
> + uint64_t flow_id; /* if streaming then "flow id" */
> + };
> + unsigned char tag[16]; /* DDR: BANK0,1,2,3, has to be null */
> + /* terminated; if streaming then stream0, 1 etc */
> +} __packed;
> +
> +struct mem_topology {
> + int32_t count; /* Number of mem_data */
> + struct mem_data mem_data[1]; /* Should be sorted on mem_type */
> +} __packed;
> +
> +/CONNECTIVITY SECTION /
> +/* Connectivity of each argument of CU(Compute Unit). It will be in terms
ok
>
Re: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
On 3/27/21 11:09 AM, Moritz Fischer wrote: > Hi Richard, Russ, > > On Thu, Feb 25, 2021 at 01:07:14PM +, Gong, Richard wrote: >> Hi Moritz, >> >> Sorry for asking. >> >> When you have chance, can you help review the version 5 patchset submitted >> on 02/09/21? >> >> Regards, >> Richard >> >> -Original Message- >> From: richard.g...@linux.intel.com >> Sent: Tuesday, February 9, 2021 4:20 PM >> To: m...@kernel.org; t...@redhat.com; gre...@linuxfoundation.org; >> linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org >> Cc: Gong, Richard >> Subject: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region >> >> From: Richard Gong >> >> This is 5th submission of Intel service layer and FPGA patches, which >> includes the missing standalone patch in the 4th submission. >> >> This submission includes additional changes for Intel service layer driver >> to get the firmware version running at FPGA SoC device. Then FPGA manager >> driver, one of Intel service layer driver's client, can decide whether to >> handle the newly added bitstream authentication function based on the >> retrieved firmware version. So that we can maintain FPGA manager driver the >> back compatible. >> >> Bitstream authentication makes sure a signed bitstream has valid signatures. >> >> The customer sends the bitstream via FPGA framework and overlay, the >> firmware will authenticate the bitstream but not program the bitstream to >> device. If the authentication passes, the bitstream will be programmed into >> QSPI flash and will be expected to boot without issues. >> >> Extend Intel service layer, FPGA manager and region drivers to support the >> bitstream authentication feature. >> >> Richard Gong (7): >> firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0 >> firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag >> firmware: stratix10-svc: extend SVC driver to get the firmware version >> fpga: fpga-mgr: add FPGA_MGR_BITSTREAM_AUTHENTICATE flag >> fpga: of-fpga-region: add authenticate-fpga-config property >> dt-bindings: fpga: add authenticate-fpga-config property >> fpga: stratix10-soc: extend driver for bitstream authentication >> >> .../devicetree/bindings/fpga/fpga-region.txt | 10 >> drivers/firmware/stratix10-svc.c | 12 - >> drivers/fpga/of-fpga-region.c | 24 ++--- >> drivers/fpga/stratix10-soc.c | 62 >> +++--- >> include/linux/firmware/intel/stratix10-smc.h | 21 +++- >> .../linux/firmware/intel/stratix10-svc-client.h| 11 +++- >> include/linux/fpga/fpga-mgr.h | 3 ++ >> 7 files changed, 125 insertions(+), 18 deletions(-) >> >> -- >> 2.7.4 >> > Apologies for the epic delay in getting back to this, I took another > look at this patchset and Russ' patchset. > > TL;DR I'm not really a fan of using device-tree overlays for this (and > again, apologies, I should've voiced this earlier ...). > > Anyways, let's find a common API for this and Russ' work, they're trying > to achieve the same / similar thing, they should use the same API. > > I'd like to re-invetigate the possiblity to extend FPGA Manager with > 'secure update' ops that work for both these use-cases (and I susspect > hte XRT patchset will follow with a similar requirement, right after). The xrt patchset makes heavy use of device trees. What is the general guidance for device tree usage ? Tom > > - Moritz >
Re: [PATCH V4 XRT Alveo 02/20] fpga: xrt: driver metadata helper functions
goto failed;
> + }
> +
> + count += snprintf(comp + count, sizeof(comp) - count - 1,
> + "%s", ep->regmap);
what happens when only part of regmap is added to comp ?
> + count++;
> + if (count > sizeof(comp)) {
> + ret = -EINVAL;
> + goto failed;
> + }
> +
> + ret = xrt_md_setprop(dev, blob, ep_offset,
> XRT_MD_PROP_COMPATIBLE,
> + comp, count);
> + if (ret) {
> + dev_err(dev, "set %s failed, ret %d",
> + XRT_MD_PROP_COMPATIBLE, ret);
> + goto failed;
> + }
> + }
> +
> +failed:
> + if (ret)
> + xrt_md_del_endpoint(dev, blob, ep->ep_name, NULL);
> +
> + return ret;
> +}
> +
> +int xrt_md_add_endpoint(struct device *dev, char *blob,
> + struct xrt_md_endpoint *ep)
> +{
> + return __xrt_md_add_endpoint(dev, blob, ep, NULL,
> XRT_MD_NODE_ENDPOINTS);
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_add_endpoint);
> +
> +int xrt_md_find_endpoint(struct device *dev, const char *blob,
> + const char *ep_name, const char *regmap_name,
> + const char **epname)
> +{
> + int offset;
> + int ret;
> +
> + ret = xrt_md_get_endpoint(dev, blob, ep_name, regmap_name,
> + );
> + if (!ret && epname)
split this condition, if the call failed, check and return early.
> + *epname = fdt_get_name(blob, offset, NULL);
what happens if fdt_get_name fails ?
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_find_endpoint);
> +
> +int xrt_md_get_prop(struct device *dev, const char *blob, const char
> *ep_name,
> + const char *regmap_name, const char *prop,
> + const void **val, int *size)
> +{
> + int offset;
> + int ret;
> +
> + if (!val) {
> + dev_err(dev, "val is null");
> + return -EINVAL;
ok
> + }
> +
> + *val = NULL;
> + ret = xrt_md_get_node(dev, blob, ep_name, regmap_name, );
> + if (ret)
> + return ret;
> +
> + *val = fdt_getprop(blob, offset, prop, size);
> + if (!*val) {
> + dev_dbg(dev, "get ep %s, prop %s failed", ep_name, prop);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_get_prop);
> +
> +int xrt_md_set_prop(struct device *dev, char *blob,
> + const char *ep_name, const char *regmap_name,
> + const char *prop, const void *val, int size)
> +{
> + int offset;
> + int ret;
> +
> + ret = xrt_md_get_node(dev, blob, ep_name, regmap_name, );
> + if (ret)
> + return ret;
> +
> + ret = xrt_md_setprop(dev, blob, offset, prop, val, size);
ok
> + if (ret)
> + dev_err(dev, "set prop %s failed, ret = %d", prop, ret);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_set_prop);
> +
> +int xrt_md_copy_endpoint(struct device *dev, char *blob, const char
> *src_blob,
> + const char *ep_name, const char *regmap_name,
> + const char *new_ep_name)
> +{
> + const char *newepnm = new_ep_name ? new_ep_name : ep_name;
> + struct xrt_md_endpoint ep = {0};
> + int offset, target;
> + const char *parent;
> + int ret;
> +
> + ret = xrt_md_get_endpoint(dev, src_blob, ep_name, regmap_name,
> + );
> + if (ret)
> + return -EINVAL;
> +
> + ret = xrt_md_get_endpoint(dev, blob, newepnm, regmap_name, );
> + if (ret) {
> + ep.ep_name = newepnm;
> + parent = fdt_parent_offset(src_blob, offset) == 0 ? NULL :
> XRT_MD_NODE_ENDPOINTS;
> + ret = __xrt_md_add_endpoint(dev, blob, , , parent);
> + if (ret)
> + return -EINVAL;
> + }
> +
> + ret = xrt_md_overlay(dev, blob, target, src_blob, offset, 0);
> + if (ret)
> + dev_err(dev, "overlay failed, ret = %d", ret);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_copy_endpoint);
> +
> +int xrt_md_get_next_endpoint(struct device *dev, const char *blob,
> + const char *ep_name, const char *regmap_name,
> + char **next_ep, char **next_regmap)
> +{
> + int offset, ret;
> +
> + *next_ep = NULL;
> + *next_regmap = NULL;
> + if (!ep_name) {
> + ret = xrt_md_get_endpoint(dev, blob, XRT_MD_NODE_ENDPOINTS,
> NULL,
> + );
> + } else {
> + ret = xrt_md_get_endpoint(dev, blob, ep_name, regmap_name,
> + );
> + }
> +
> + if (ret)
> + return -EINVAL;
> +
> + offset = ep_name ? fdt_next_subnode(blob, offset) :
> + fdt_first_subnode(blob, offset);
tristate with function calls is harder to follow, convert this to if-else logic
> + if (offset < 0)
> + return -EINVAL;
> +
> + *next_ep = (char *)fdt_get_name(blob, offset, NULL);
> + *next_regmap = (char *)fdt_stringlist_get(blob, offset,
> XRT_MD_PROP_COMPATIBLE,
> + 0, NULL);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_get_next_endpoint);
> +
> +int xrt_md_get_compatible_endpoint(struct device *dev, const char *blob,
> +const char *regmap_name, const char
> **ep_name)
> +{
> + int ep_offset;
> +
> + ep_offset = fdt_node_offset_by_compatible(blob, -1, regmap_name);
> + if (ep_offset < 0) {
> + *ep_name = NULL;
> + return -ENOENT;
> + }
> +
> + *ep_name = fdt_get_name(blob, ep_offset, NULL);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_get_compatible_endpoint);
> +
> +int xrt_md_pack(struct device *dev, char *blob)
> +{
> + int ret;
> +
> + ret = fdt_pack(blob);
> + if (ret)
> + dev_err(dev, "pack failed %d", ret);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_pack);
> +
> +int xrt_md_get_interface_uuids(struct device *dev, const char *blob,
ok
> +u32 num_uuids, uuid_t *interface_uuids)
> +{
> + int offset, count = 0;
> + const char *uuid_str;
> + int ret;
> +
> + ret = xrt_md_get_endpoint(dev, blob, XRT_MD_NODE_INTERFACES, NULL,
> );
> + if (ret)
> + return -ENOENT;
> +
> + for (offset = fdt_first_subnode(blob, offset);
> + offset >= 0;
> + offset = fdt_next_subnode(blob, offset), count++) {
> + uuid_str = fdt_getprop(blob, offset, XRT_MD_PROP_INTERFACE_UUID,
> +NULL);
> + if (!uuid_str) {
> + dev_err(dev, "empty interface uuid node");
> + return -EINVAL;
> + }
> +
> + if (!num_uuids)
> + continue;
> +
> + if (count == num_uuids) {
ok
> + dev_err(dev, "too many interface uuid in blob");
> + return -EINVAL;
> + }
> +
> + if (interface_uuids && count < num_uuids) {
> + ret = xrt_md_trans_str2uuid(dev, uuid_str,
> + _uuids[count]);
> + if (ret)
> + return -EINVAL;
> + }
> + }
> + if (!count)
> + count = -ENOENT;
> +
> + return count;
> +}
> +EXPORT_SYMBOL_GPL(xrt_md_get_interface_uuids);
Thanks for the changes,
Tom
[PATCH v2] scripts/spelling.txt: add entries for recent discoveries
Add a few entries for recent spelling fixes found. Opportunistically de-dupe: exeeds||exceeds Link: https://lore.kernel.org/lkml/31acb3239b7ab8989db0c9951e8740050aef0205.1616727528.git.tom.sae...@oracle.com/ Link: https://lore.kernel.org/lkml/fa193b3c9e346ff3fc157b54802c29b25f79c402.1615597995.git.tom.sae...@oracle.com/ Signed-off-by: Tom Saeger --- Changes in v2: * drop entry `readded||read`, "readded" is in fact "readded" * Link to v1: https://lore.kernel.org/lkml/14c54ee47bf0e9aebfe71e97cefd11b2b8f0332f.1616784384.git.tom.sae...@oracle.com/ --- scripts/spelling.txt | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 2e3ba91a5072..7beb4262f719 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -84,6 +84,7 @@ againt||against agaist||against aggreataon||aggregation aggreation||aggregation +ajust||adjust albumns||albums alegorical||allegorical algined||aligned @@ -161,10 +162,13 @@ asign||assign asser||assert assertation||assertion assertting||asserting +assgined||assigned assiged||assigned assigment||assignment assigments||assignments assistent||assistant +assocaited||associated +assocating||associating assocation||association associcated||associated assotiated||associated @@ -177,9 +181,11 @@ asynchnous||asynchronous asynchromous||asynchronous asymetric||asymmetric asymmeric||asymmetric +atleast||at least atomatically||automatically atomicly||atomically atempt||attempt +atrributes||attributes attachement||attachment attatch||attach attched||attached @@ -315,6 +321,7 @@ comminucation||communication commited||committed commiting||committing committ||commit +commnunication||communication commoditiy||commodity comsume||consume comsumer||consumer @@ -349,6 +356,7 @@ condtion||condition conected||connected conector||connector configration||configuration +configred||configured configuartion||configuration configuation||configuration configued||configured @@ -402,6 +410,7 @@ cunter||counter curently||currently cylic||cyclic dafault||default +deactive||deactivate deafult||default deamon||daemon debouce||debounce @@ -417,6 +426,7 @@ deffered||deferred defferred||deferred definate||definite definately||definitely +definiation||definition defintion||definition defintions||definitions defualt||default @@ -571,8 +581,9 @@ errror||error estbalishment||establishment etsablishment||establishment etsbalishment||establishment +evalute||evaluate +evalutes||evaluates evalution||evaluation -exeeds||exceeds excecutable||executable exceded||exceeded exceds||exceeds @@ -696,6 +707,7 @@ hardare||hardware harware||hardware havind||having heirarchically||hierarchically +heirarchy||hierarchy helpfull||helpful heterogenous||heterogeneous hexdecimal||hexadecimal @@ -796,6 +808,7 @@ interanl||internal interchangable||interchangeable interferring||interfering interger||integer +intergrated||integrated intermittant||intermittent internel||internal interoprability||interoperability @@ -808,6 +821,7 @@ interrup||interrupt interrups||interrupts interruptted||interrupted interupted||interrupted +intiailized||initialized intial||initial intialisation||initialisation intialised||initialised @@ -1091,11 +1105,14 @@ preemptable||preemptible prefered||preferred prefferably||preferably prefitler||prefilter +preform||perform premption||preemption prepaired||prepared preperation||preparation preprare||prepare pressre||pressure +presuambly||presumably +previosuly||previously primative||primitive princliple||principle priorty||priority @@ -1265,6 +1282,7 @@ scarch||search schdule||schedule seach||search searchs||searches +secion||section secquence||sequence secund||second segement||segment @@ -1312,6 +1330,8 @@ singed||signed sleeped||slept sliped||slipped softwares||software +soley||solely +souce||source speach||speech specfic||specific specfield||specified @@ -1320,7 +1340,9 @@ specifc||specific specifed||specified specificatin||specification specificaton||specification +specificed||specified specifing||specifying +specifiy||specify specifiying||specifying speficied||specified speicify||specify @@ -1436,6 +1458,7 @@ timout||timeout tmis||this toogle||toggle torerable||tolerable +traget||target traking||tracking tramsmitted||transmitted tramsmit||transmit @@ -1558,6 +1581,7 @@ wiil||will wirte||write withing||within wnat||want +wont||won't workarould||workaround writeing||writing writting||writing base-commit: db24726bfefa68c606947a86132591568a06bfb4 -- 2.31.0
Re: [PATCH 1/1] scripts/spelling.txt: add entries for recent discoveries
On Fri, Mar 26, 2021 at 04:36:01PM -0600, Jens Axboe wrote: > On 3/26/21 1:22 PM, Tom Saeger wrote: > > @@ -1153,6 +1170,7 @@ quering||querying > > queus||queues > > randomally||randomly > > raoming||roaming > > +readded||read > > reasearcher||researcher > > reasearchers||researchers > > reasearch||research > > davej brought up a good point that this one was actually re-added, which > does make sense. So don't think that one should be added to the list. Ah! Good catch. I'll drop that entry and send V2. Thanks > > -- > Jens Axboe >
Re: [PATCH V4 XRT Alveo 01/20] Documentation: fpga: Add a document describing XRT Alveo drivers
e =
> "xilinx.com,reg_abs-axi_bram_ctrl-1.0\0axi_bram_ctrl";
> +
> +firmware {
> +firmware_product_name = "ert";
> +firmware_branch_name = "v20";
> +firmware_version_major = <0x01>;
> +};
> +};
> +
> +ep_ert_intc_00 {
> +reg = <0x00 0x23000 0x00 0x1000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_intc-1.0\0axi_intc";
> +interrupts = <0x05 0x05>;
> +};
> +
> +ep_ert_reset_00 {
> +reg = <0x00 0x22000 0x00 0x1000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_gpio-1.0\0axi_gpio";
> +};
> +
> +ep_ert_sched_00 {
> +reg = <0x00 0x5 0x00 0x1000>;
> +pcie_physical_function = <0x01>;
> +compatible =
> "xilinx.com,reg_abs-ert_sched-1.0\0ert_sched";
> +interrupts = <0x09 0x0c>;
> +};
> +
> +ep_fpga_configuration_00 {
> +reg = <0x00 0x1e88000 0x00 0x8000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_hwicap-1.0\0axi_hwicap";
> +interrupts = <0x02 0x02>;
> +};
> +
> +ep_icap_reset_00 {
> +reg = <0x00 0x1f07000 0x00 0x1000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_gpio-1.0\0axi_gpio";
> +};
> +
> +ep_msix_00 {
> +reg = <0x00 0x00 0x00 0x2>;
> +pcie_physical_function = <0x00>;
> +compatible = "xilinx.com,reg_abs-msix-1.0\0msix";
> +pcie_bar_mapping = <0x02>;
> +};
> +
> +ep_pcie_link_mon_00 {
> +reg = <0x00 0x1f05000 0x00 0x1000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_gpio-1.0\0axi_gpio";
> +};
> +
> +ep_pr_isolate_plp_00 {
> +reg = <0x00 0x1f01000 0x00 0x1000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_gpio-1.0\0axi_gpio";
> +};
> +
> +ep_pr_isolate_ulp_00 {
> +reg = <0x00 0x1000 0x00 0x1000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_gpio-1.0\0axi_gpio";
> +};
> +
> +ep_uuid_rom_00 {
> +reg = <0x00 0x64000 0x00 0x1000>;
> +pcie_physical_function = <0x00>;
> +compatible =
> "xilinx.com,reg_abs-axi_bram_ctrl-1.0\0axi_bram_ctrl";
> +};
> +
> +ep_xdma_00 {
> +reg = <0x00 0x00 0x00 0x1>;
> +pcie_physical_function = <0x01>;
> +compatible = "xilinx.com,reg_abs-xdma-1.0\0xdma";
> +pcie_bar_mapping = <0x02>;
> +};
> +};
> +
> + }
> +
> +
> +
> +Deployment Models
> +=
> +
> +Baremetal
> +-
> +
> +In bare-metal deployments, both MPF and UPF are visible and accessible. xmgmt
ok
xmgnt -> xrt-mgmt
> +driver binds to MPF. xmgmt driver operations are privileged and available to
> +system administrator. The full stack is illustrated below::
> +
> +HOST
> +
> + [XMGMT][XUSER]
> +| |
> +| |
> + +-++-+
> + | MPF || UPF |
> + | || |
> + | PF0 || PF1 |
> + +--+--++--+--+
> + . ^. ^..
> +| |
> +| PCIe DEVICE|
> +| |
> + +--+--+--+
> + | SHELL |
> + ||
> + ++
> + | USER |
> + ||
> + ||
> + ||
> + ||
> + ++
> +
> +
> +
> +Virtualized
> +---
> +
> +In virtualized deployments, privileged MPF is assigned to host but
> unprivileged
an article is needed to precede 'MPF' and 'UPF' pick either 'a' or 'the'
Thanks for all the changes.
Tom
> +UPF is assigned to guest VM via PCIe pass-through. xmgmt driver in host binds
> +to MPF. xmgmt driver operations are privileged and only accessible to the
> MPF.
> +The full stack is illustrated below::
> +
> +
> + .
> + HOST .VM .
> + . .
> + [XMGMT] . [XUSER] .
> +|. | .
> +|. | .
> + +-+ . +-+ .
> + | MPF | . | UPF | .
> + | | . | | .
> + | PF0 | . | PF1 | .
> + +--+--+ . +--+--+ .
> + . ^. ^..
> +| |
> +| PCIe DEVICE|
> +| |
> + +--+--+--+
> + | SHELL |
> + ||
> + ++
> + | USER |
> + ||
> + ||
> + ||
> + ||
> + ++
> +
> +
> +
> +
> +
> +Platform Security Considerations
> +
> +
> +`Security of Alveo Platform
> <https://xilinx.github.io/XRT/master/html/security.html>`_
> +discusses the deployment options and security implications in great detail.
Re: [PATCH] scripts: stable: add script to validate backports
On Wed, Mar 24, 2021 at 10:55:27AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 23, 2021 at 01:28:38PM -0700, Nick Desaulniers wrote:
> > On Tue, Mar 23, 2021 at 12:05 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > The only time git gets involved is when we do a -rc release or when we
> > > do a "real" release, and then we use 'git quiltimport' on the whole
> > > stack.
> > >
> > > Here's a script that I use (much too slow, I know), for checking this
> > > type of thing and I try to remember to run it before every cycle of -rc
> > > releases:
> > >
> > > https://github.com/gregkh/commit_tree/blob/master/find_fixes_in_queue
> > >
> > > It's a hack, and picks up more things than is really needed, but I would
> > > rather it error on that side than the other.
> >
> > Yes, my script is similar. Looks like yours also runs on a git tree.
> >
> > I noticed that id_fixed_in runs `git grep -l --threads=3 ` to
> > find fixes; that's neat, I didn't know about `--threads=`. I tried it
> > with ae46578b963f manually:
> >
> > $ git grep -l --threads=3 ae46578b963f
> > $
> >
> > Should it have found a7889c6320b9 and 773e0c402534? Perhaps `git log
> > --grep=` should be used instead? I thought `git grep` only greps
> > files in the archive, not commit history?
>
> Yes, it does only grep the files in the archive.
>
> But look closer at the archive that this script lives in :)
>
> This archive is a "blown up" copy of the Linux kernel tree, with one
> file per commit. The name of the file is the commit id, and the content
> of the file is the changelog of the commit itself.
>
> So it's a hack that I use to be able to simply search the changelogs of
> all commits to find out if they have a "Fixes:" tag with a specific
> commit id in it.
>
> So in your example above, in the repo I run it and get:
>
> ~/linux/stable/commit_tree $ git grep -l --threads=3 ae46578b963f
> changes/5.2/773e0c40253443e0ce5491cb0e414b62f7cc45ed
> ids/5.2
>
> Which shows me that in commit 773e0c402534 ("afs: Fix
> afs_xattr_get_yfs() to not try freeing an error value") in the kernel
> tree, it has a "Fixes:" tag that references "ae46578b963f".
>
> It also shows me that commit ae46578b963f was contained in the 5.2
> kernel release, as I use the "ids/" subdirectory here for other fast
> lookups (it's a tiny bit faster than 'git describe --contains').
>
> I don't know how your script is walking through all possible commits to
> see if they are fixing a specific one, maybe I should look and see if
> it's doing it better than my "git tree/directory as a database hack"
> does :)
FWIW,
I had a need for something similar and found `git rev-list --grep` provided
fastest
results. Does not provide for the "ids/" hack though...
??? N="ae46578b963f"; git rev-list --grep="${N}" "${N}..upstream/master" |
while read -r hid ; do git log -n1 "${hid}" | grep -F "${N}" | sed "s#^#${hid}
#"; done
a7889c6320b9200e3fe415238f546db677310fa9 Fixes: ae46578b963f ("afs: Get YFS
ACLs and information through xattrs")
773e0c40253443e0ce5491cb0e414b62f7cc45ed Fixes: ae46578b963f ("afs: Get YFS
ACLs and information through xattrs")
??? N="a7889c6320b9"; git rev-list --grep="${N}" "${N}..stable/linux-5.4.y" |
while read -r hid ; do git log -n1 "${hid}" | grep -F "${N}" | sed "s#^#${hid}
#"; done
6712b7fcef9d1092e99733645cf52cfb3d482555 commit
a7889c6320b9200e3fe415238f546db677310fa9 upstream.
??? N="ae46578b963f"; git rev-list --grep="${N}" "${N}..stable/linux-5.4.y" |
while read -r hid ; do git log -n1 "${hid}" | grep -F "${N}" | sed "s#^#${hid}
#"; done
6712b7fcef9d1092e99733645cf52cfb3d482555 Fixes: ae46578b963f ("afs: Get YFS
ACLs and information through xattrs")
773e0c40253443e0ce5491cb0e414b62f7cc45ed Fixes: ae46578b963f ("afs: Get YFS
ACLs and information through xattrs")
>
> thanks,
>
> greg k-h
[PATCH 1/1] scripts/spelling.txt: add entries for recent discoveries
Add a few entries for recent spelling fixes found. Opportunistically de-dupe: exeeds||exceeds Link: https://lore.kernel.org/lkml/31acb3239b7ab8989db0c9951e8740050aef0205.1616727528.git.tom.sae...@oracle.com/ Link: https://lore.kernel.org/lkml/fa193b3c9e346ff3fc157b54802c29b25f79c402.1615597995.git.tom.sae...@oracle.com/ Signed-off-by: Tom Saeger --- scripts/spelling.txt | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 2e3ba91a5072..f7a3bfd75787 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -84,6 +84,7 @@ againt||against agaist||against aggreataon||aggregation aggreation||aggregation +ajust||adjust albumns||albums alegorical||allegorical algined||aligned @@ -161,10 +162,13 @@ asign||assign asser||assert assertation||assertion assertting||asserting +assgined||assigned assiged||assigned assigment||assignment assigments||assignments assistent||assistant +assocaited||associated +assocating||associating assocation||association associcated||associated assotiated||associated @@ -177,9 +181,11 @@ asynchnous||asynchronous asynchromous||asynchronous asymetric||asymmetric asymmeric||asymmetric +atleast||at least atomatically||automatically atomicly||atomically atempt||attempt +atrributes||attributes attachement||attachment attatch||attach attched||attached @@ -315,6 +321,7 @@ comminucation||communication commited||committed commiting||committing committ||commit +commnunication||communication commoditiy||commodity comsume||consume comsumer||consumer @@ -349,6 +356,7 @@ condtion||condition conected||connected conector||connector configration||configuration +configred||configured configuartion||configuration configuation||configuration configued||configured @@ -402,6 +410,7 @@ cunter||counter curently||currently cylic||cyclic dafault||default +deactive||deactivate deafult||default deamon||daemon debouce||debounce @@ -417,6 +426,7 @@ deffered||deferred defferred||deferred definate||definite definately||definitely +definiation||definition defintion||definition defintions||definitions defualt||default @@ -571,8 +581,9 @@ errror||error estbalishment||establishment etsablishment||establishment etsbalishment||establishment +evalute||evaluate +evalutes||evaluates evalution||evaluation -exeeds||exceeds excecutable||executable exceded||exceeded exceds||exceeds @@ -696,6 +707,7 @@ hardare||hardware harware||hardware havind||having heirarchically||hierarchically +heirarchy||hierarchy helpfull||helpful heterogenous||heterogeneous hexdecimal||hexadecimal @@ -796,6 +808,7 @@ interanl||internal interchangable||interchangeable interferring||interfering interger||integer +intergrated||integrated intermittant||intermittent internel||internal interoprability||interoperability @@ -808,6 +821,7 @@ interrup||interrupt interrups||interrupts interruptted||interrupted interupted||interrupted +intiailized||initialized intial||initial intialisation||initialisation intialised||initialised @@ -1091,11 +1105,14 @@ preemptable||preemptible prefered||preferred prefferably||preferably prefitler||prefilter +preform||perform premption||preemption prepaired||prepared preperation||preparation preprare||prepare pressre||pressure +presuambly||presumably +previosuly||previously primative||primitive princliple||principle priorty||priority @@ -1153,6 +1170,7 @@ quering||querying queus||queues randomally||randomly raoming||roaming +readded||read reasearcher||researcher reasearchers||researchers reasearch||research @@ -1265,6 +1283,7 @@ scarch||search schdule||schedule seach||search searchs||searches +secion||section secquence||sequence secund||second segement||segment @@ -1312,6 +1331,8 @@ singed||signed sleeped||slept sliped||slipped softwares||software +soley||solely +souce||source speach||speech specfic||specific specfield||specified @@ -1320,7 +1341,9 @@ specifc||specific specifed||specified specificatin||specification specificaton||specification +specificed||specified specifing||specifying +specifiy||specify specifiying||specifying speficied||specified speicify||specify @@ -1436,6 +1459,7 @@ timout||timeout tmis||this toogle||toggle torerable||tolerable +traget||target traking||tracking tramsmitted||transmitted tramsmit||transmit @@ -1558,6 +1582,7 @@ wiil||will wirte||write withing||within wnat||want +wont||won't workarould||workaround writeing||writing writting||writing base-commit: db24726bfefa68c606947a86132591568a06bfb4 -- 2.31.0
Re: [PATCH 1/1] block: fix trivial typos in comments
On Fri, Mar 26, 2021 at 09:41:49AM -0600, Jens Axboe wrote: > On 3/25/21 9:04 PM, Tom Saeger wrote: > > > > s/Additonal/Additional/ > > s/assocaited/associated/ > > s/assocaited/associated/ > > s/assocating/associating/ > > s/becasue/because/ > > s/configred/configured/ > > s/deactive/deactivate/ > > s/followings/following/ > > s/funtion/function/ > > s/heirarchy/hierarchy/ > > s/intiailized/initialized/ > > s/prefered/preferred/ > > s/readded/read/ > > s/Secion/Section/ > > s/soley/solely/ > > While I'm generally happy to accept any patch that makes sense, the > recent influx of speling fixes have me less than excited. They just > add complications to backports and stable patches, for example, and > I'd prefer not to take them for that reason alone. Nod. In that case - perhaps adding these entries to scripts/spelling.txt would at least catch some going forward? I can send that. > > -- > Jens Axboe >
[PATCH 1/1] block: fix trivial typos in comments
s/Additonal/Additional/
s/assocaited/associated/
s/assocaited/associated/
s/assocating/associating/
s/becasue/because/
s/configred/configured/
s/deactive/deactivate/
s/followings/following/
s/funtion/function/
s/heirarchy/hierarchy/
s/intiailized/initialized/
s/prefered/preferred/
s/readded/read/
s/Secion/Section/
s/soley/solely/
Cc: triv...@kernel.org
Signed-off-by: Tom Saeger
---
block/bfq-iosched.c | 4 ++--
block/blk-cgroup-rwstat.c | 2 +-
block/blk-cgroup.c| 6 +++---
block/blk-core.c | 2 +-
block/blk-iocost.c| 12 ++--
block/blk-iolatency.c | 4 ++--
block/blk-merge.c | 6 +++---
block/blk-mq.c| 4 ++--
block/blk-settings.c | 2 +-
block/blk-stat.h | 2 +-
block/blk.h | 2 +-
block/kyber-iosched.c | 2 +-
block/opal_proto.h| 4 ++--
block/partitions/ibm.c| 2 +-
block/partitions/sun.c| 2 +-
block/scsi_ioctl.c| 2 +-
16 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 9b7678ad5830..936e48bdecaf 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -1798,7 +1798,7 @@ static void bfq_bfqq_handle_idle_busy_switch(struct
bfq_data *bfqd,
* As for throughput, we ask bfq_better_to_idle() whether we
* still need to plug I/O dispatching. If bfq_better_to_idle()
* says no, then plugging is not needed any longer, either to
-* boost throughput or to perserve service guarantees. Then
+* boost throughput or to preserve service guarantees. Then
* the best option is to stop plugging I/O, as not doing so
* would certainly lower throughput. We may end up in this
* case if: (1) upon a dispatch attempt, we detected that it
@@ -5050,7 +5050,7 @@ void bfq_put_queue(struct bfq_queue *bfqq)
* by the fact that bfqq has just been merged.
* 2) burst_size is greater than 0, to handle
* unbalanced decrements. Unbalanced decrements may
-* happen in te following case: bfqq is inserted into
+* happen in the following case: bfqq is inserted into
* the current burst list--without incrementing
* bust_size--because of a split, but the current
* burst list is not the burst list bfqq belonged to
diff --git a/block/blk-cgroup-rwstat.c b/block/blk-cgroup-rwstat.c
index 3304e841df7c..0039e4756fc3 100644
--- a/block/blk-cgroup-rwstat.c
+++ b/block/blk-cgroup-rwstat.c
@@ -37,7 +37,7 @@ EXPORT_SYMBOL_GPL(blkg_rwstat_exit);
* @pd: policy private data of interest
* @rwstat: rwstat to print
*
- * Print @rwstat to @sf for the device assocaited with @pd.
+ * Print @rwstat to @sf for the device associated with @pd.
*/
u64 __blkg_prfill_rwstat(struct seq_file *sf, struct blkg_policy_data *pd,
const struct blkg_rwstat_sample *rwstat)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index a317c03d40f6..e5dc2e13487f 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -143,7 +143,7 @@ static void blkg_async_bio_workfn(struct work_struct *work)
* @q: request_queue the new blkg is associated with
* @gfp_mask: allocation mask to use
*
- * Allocate a new blkg assocating @blkcg and @q.
+ * Allocate a new blkg associating @blkcg and @q.
*/
static struct blkcg_gq *blkg_alloc(struct blkcg *blkcg, struct request_queue
*q,
gfp_t gfp_mask)
@@ -526,7 +526,7 @@ EXPORT_SYMBOL_GPL(blkcg_print_blkgs);
* @pd: policy private data of interest
* @v: value to print
*
- * Print @v to @sf for the device assocaited with @pd.
+ * Print @v to @sf for the device associated with @pd.
*/
u64 __blkg_prfill_u64(struct seq_file *sf, struct blkg_policy_data *pd, u64 v)
{
@@ -715,7 +715,7 @@ EXPORT_SYMBOL_GPL(blkg_conf_prep);
/**
* blkg_conf_finish - finish up per-blkg config update
- * @ctx: blkg_conf_ctx intiailized by blkg_conf_prep()
+ * @ctx: blkg_conf_ctx initialized by blkg_conf_prep()
*
* Finish up after per-blkg config update. This function must be paired
* with blkg_conf_prep().
diff --git a/block/blk-core.c b/block/blk-core.c
index fc60ff208497..e866e58214e2 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1035,7 +1035,7 @@ blk_qc_t submit_bio_noacct(struct bio *bio)
/*
* We only want one ->submit_bio to be active at a time, else stack
* usage with stacked devices could be a problem. Use current->bio_list
-* to collect a list of requests submited by a ->submit_bio method while
+* to collect a list of requests submitted by a ->submit_bio method
while
* it is active, and then process them after it returned.
*/
if (current->bio_list) {
diff --git a/block/blk-iocost.c b/block/blk-iocost.c
index 98d656bdb42b..282903250530 100644
--- a/block/blk-iocost.c
+++ b/blo
[ANNOUNCE] 4.19.182-rt74
Hello RT Folks! I'm pleased to announce the 4.19.182-rt74 stable release. This release is just an update to the new stable 4.19.182 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.19-rt Head SHA1: 973d50c65e7a04ce11a946a0725e22432353a82c Or to build 4.19.182-rt74 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.19.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.19.182.xz https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.182-rt74.patch.xz Enjoy! Tom
Re: [PATCH net-next] airo: work around stack usage warning
mp
> - if (status == SUCCESS) {
> - if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL))
> != NULL)
> - memcpy(ai->rssi, (u8*)_rid + 2, 512); /*
> Skip RID length member */
Here is the temp being copied to heap memory.
This is the only use of rssi_rid
Why not do the alloc in PC4500_read ?
The call would be something like
status = PC4500_readrid(ai, RID_RSSI, >rssi, sizeof(), lock)
or since ai, is common reduce the signature of the function and make the call
PC4500_readid(ai, RID_RSSI, lock)
Tom
> - }
> - else {
> - kfree(ai->rssi);
> - ai->rssi = NULL;
> - if (cap_rid.softCap & cpu_to_le16(8))
> - ai->config.rmode |= RXMODE_NORMALIZED_RSSI;
> - else
> - airo_print_warn(ai->dev->name, "unknown
> received signal "
> - "level scale");
> - }
> - ai->config.opmode = adhoc ? MODE_STA_IBSS : MODE_STA_ESS;
> - set_auth_type(ai, AUTH_OPEN);
> - ai->config.modulation = MOD_CCK;
> -
> - if (le16_to_cpu(cap_rid.len) >= sizeof(cap_rid) &&
> - (cap_rid.extSoftCap & cpu_to_le16(1)) &&
> - micsetup(ai) == SUCCESS) {
> - ai->config.opmode |= MODE_MIC;
> - set_bit(FLAG_MIC_CAPABLE, >flags);
> - }
> -
> - /* Save off the MAC */
> - for (i = 0; i < ETH_ALEN; i++) {
> - mac[i] = ai->config.macAddr[i];
> - }
> -
> - /* Check to see if there are any insmod configured
> -rates to add */
> - if (rates[0]) {
> - memset(ai->config.rates, 0, sizeof(ai->config.rates));
> - for (i = 0; i < 8 && rates[i]; i++) {
> - ai->config.rates[i] = rates[i];
> - }
> - }
> - set_bit (FLAG_COMMIT, >flags);
> + status = airo_readconfig(ai, mac, lock);
> + if (status != SUCCESS)
> + return ERROR;
> }
>
> /* Setup the SSIDs if present */
Re: [PATCH] X86: __set_clr_pte_enc() miscalculates physical address
On 3/18/21 3:26 PM, Isaku Yamahata wrote:
> __set_clr_pte_enc() miscalculates physical address to operate.
> pfn is in unit of PG_LEVEL_4K, not PGL_LEVEL_{2M, 1G}.
> Shift size to get physical address should be PAGE_SHIFT,
> not page_level_shift().
>
> Fixes: dfaaec9033b8 ("x86: Add support for changing memory encryption
> attribute in early boot")
> Reviewed-by: Kirill A. Shutemov
> Signed-off-by: Isaku Yamahata
Reviewed-by: Tom Lendacky
> ---
> arch/x86/mm/mem_encrypt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 4b01f7dbaf30..ae78cef79980 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -262,7 +262,7 @@ static void __init __set_clr_pte_enc(pte_t *kpte, int
> level, bool enc)
> if (pgprot_val(old_prot) == pgprot_val(new_prot))
> return;
>
> - pa = pfn << page_level_shift(level);
> + pa = pfn << PAGE_SHIFT;
> size = page_level_size(level);
>
> /*
>
Re: [PATCH] amdgpu: avoid incorrect %hu format string
On 3/22/21 4:54 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang points out that the %hu format string does not match the type
> of the variables here:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:263:7: warning: format specifies type
> 'unsigned short' but the argument has type 'unsigned int' [-Wformat]
> version_major, version_minor);
> ^
> include/drm/drm_print.h:498:19: note: expanded from macro 'DRM_ERROR'
> __drm_err(fmt, ##__VA_ARGS__)
> ~~~^~~
>
> Change it to a regular %u, the same way a previous patch did for
> another instance of the same warning.
It would be good to explicitly call out the change.
ex/ do you mean mine ?
0b437e64e0af ("drm/amdgpu: remove h from printk format specifier")
This was for a different reason.
imo, you do not need to include what another patch did.
so you could also just remove this bit from the commit log.
The change itself looks good.
Reviewed-by: Tom Rix
>
> Fixes: 0b437e64e0af ("drm/amdgpu: remove h from printk format specifier")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index e2ed4689118a..c6dbc0801604 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -259,7 +259,7 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
> if ((adev->asic_type == CHIP_POLARIS10 ||
>adev->asic_type == CHIP_POLARIS11) &&
> (adev->uvd.fw_version < FW_1_66_16))
> - DRM_ERROR("POLARIS10/11 UVD firmware version %hu.%hu is
> too old.\n",
> + DRM_ERROR("POLARIS10/11 UVD firmware version %u.%u is
> too old.\n",
> version_major, version_minor);
> } else {
> unsigned int enc_major, enc_minor, dec_minor;
Re: FW: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
On 3/21/21 2:05 PM, Richard Gong wrote:
>
> Hi Tom,
>
>>
>>
>> On 3/19/21 4:22 PM, Richard Gong wrote:
>>>
>>> Hi Moritz,
>>>
>>> Thanks for approving the 1st patch of my version 5 patchest, which
>>> submitted on 02/09/21.
>>
>> This change
>>
>> e23bd83368af ("firmware: stratix10-svc: fix kernel-doc markups")
>
> This patch e23bd83368af is not from my version 5 patch set.
Correct.
But since it is already in char-misc-next, your version 5 patchset will
conflict with it.
I could not apply this patchset to my unoffical fpga-testing.
I am suggesting you do a test application of your patchset against
char-misc-next.
And if you find there are issues, rebase your patchset.
>>
>> Makes a lot of formatting changes in the same files as this patchset,
>> including the first patch.
>>
>> It would be good to try applying this patchset to char-misc-next and
>> resubmit if there are conflicts.
>>
>>>
>>> Can you help review the remaining 6 patches from the same version 5
>>> patchset? I need your ACKs to move forward, or please let me know if
>>> additional work is need.
>>
>> These changes look good to me.
>>
>> I was looking at the patchset again seeing if the firmware/ parts could be
>> split out.
>
> No, we can't split out the firmware parts.
ok
Tom
>>
>> Even though stratix10 is a fpga, from the MAINTAINERS file it is not clear
>> to me if linux-fpga owns them and they come in on Moritz's branch. I think
>> this change is needed to the MAINTAINERS file to make that clearer.
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index aa84121c5611..1f68e9ff76de 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9193,7 +9193,8 @@ F: tools/power/x86/intel-speed-select/
>> INTEL STRATIX10 FIRMWARE DRIVERS
>> M: Richard Gong
>> -L: linux-kernel@vger.kernel.org
>> +R: Tom Rix
>> +L: linux-f...@vger.kernel.org
>> S: Maintained
>> F: Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu
>> F: Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt
>>
>> I also added myself as a reviewer because I want to help out.
>>
>> Tom
>>
>
> Regards,
> Richard
>
>>
>>>
>>> Many thanks for your time again!
>>>
>>> Regards,
>>> Richard
>>>
>>>
>>> On 2/25/21 7:07 AM, Gong, Richard wrote:
>>>> Hi Moritz,
>>>>
>>>> Sorry for asking.
>>>>
>>>> When you have chance, can you help review the version 5 patchset submitted
>>>> on 02/09/21?
>>>>
>>>> Regards,
>>>> Richard
>>>>
>>>> -Original Message-
>>>> From: richard.g...@linux.intel.com
>>>> Sent: Tuesday, February 9, 2021 4:20 PM
>>>> To: m...@kernel.org; t...@redhat.com; gre...@linuxfoundation.org;
>>>> linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org
>>>> Cc: Gong, Richard
>>>> Subject: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
>>>>
>>>> From: Richard Gong
>>>>
>>>> This is 5th submission of Intel service layer and FPGA patches, which
>>>> includes the missing standalone patch in the 4th submission.
>>>>
>>>> This submission includes additional changes for Intel service layer driver
>>>> to get the firmware version running at FPGA SoC device. Then FPGA manager
>>>> driver, one of Intel service layer driver's client, can decide whether to
>>>> handle the newly added bitstream authentication function based on the
>>>> retrieved firmware version. So that we can maintain FPGA manager driver
>>>> the back compatible.
>>>>
>>>> Bitstream authentication makes sure a signed bitstream has valid
>>>> signatures.
>>>>
>>>> The customer sends the bitstream via FPGA framework and overlay, the
>>>> firmware will authenticate the bitstream but not program the bitstream to
>>>> device. If the authentication passes, the bitstream will be programmed
>>>> into QSPI flash and will be expected to boot without issues.
>>>>
>>>> Extend Intel service layer, FPGA manager and region drivers to support the
>>>> bitstream authentication feature.
>>>>
>>>> Richard Gong (7):
>>>> firmware: stratix10-svc: reset COMMAND_R
Re: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
On 3/19/21 4:22 PM, Richard Gong wrote:
>
> Hi Moritz,
>
> Thanks for approving the 1st patch of my version 5 patchest, which submitted
> on 02/09/21.
This change
e23bd83368af ("firmware: stratix10-svc: fix kernel-doc markups")
Makes a lot of formatting changes in the same files as this patchset, including
the first patch.
It would be good to try applying this patchset to char-misc-next and resubmit
if there are conflicts.
>
> Can you help review the remaining 6 patches from the same version 5 patchset?
> I need your ACKs to move forward, or please let me know if additional work is
> need.
These changes look good to me.
I was looking at the patchset again seeing if the firmware/ parts could be
split out.
Even though stratix10 is a fpga, from the MAINTAINERS file it is not clear to
me if linux-fpga owns them and they come in on Moritz's branch. I think this
change is needed to the MAINTAINERS file to make that clearer.
diff --git a/MAINTAINERS b/MAINTAINERS
index aa84121c5611..1f68e9ff76de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9193,7 +9193,8 @@ F: tools/power/x86/intel-speed-select/
INTEL STRATIX10 FIRMWARE DRIVERS
M: Richard Gong
-L: linux-kernel@vger.kernel.org
+R: Tom Rix
+L: linux-f...@vger.kernel.org
S: Maintained
F: Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu
F: Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt
I also added myself as a reviewer because I want to help out.
Tom
>
> Many thanks for your time again!
>
> Regards,
> Richard
>
>
> On 2/25/21 7:07 AM, Gong, Richard wrote:
>> Hi Moritz,
>>
>> Sorry for asking.
>>
>> When you have chance, can you help review the version 5 patchset submitted
>> on 02/09/21?
>>
>> Regards,
>> Richard
>>
>> -Original Message-
>> From: richard.g...@linux.intel.com
>> Sent: Tuesday, February 9, 2021 4:20 PM
>> To: m...@kernel.org; t...@redhat.com; gre...@linuxfoundation.org;
>> linux-f...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Cc: Gong, Richard
>> Subject: [PATCHv5 0/7] Extend Intel service layer, FPGA manager and region
>>
>> From: Richard Gong
>>
>> This is 5th submission of Intel service layer and FPGA patches, which
>> includes the missing standalone patch in the 4th submission.
>>
>> This submission includes additional changes for Intel service layer driver
>> to get the firmware version running at FPGA SoC device. Then FPGA manager
>> driver, one of Intel service layer driver's client, can decide whether to
>> handle the newly added bitstream authentication function based on the
>> retrieved firmware version. So that we can maintain FPGA manager driver the
>> back compatible.
>>
>> Bitstream authentication makes sure a signed bitstream has valid signatures.
>>
>> The customer sends the bitstream via FPGA framework and overlay, the
>> firmware will authenticate the bitstream but not program the bitstream to
>> device. If the authentication passes, the bitstream will be programmed into
>> QSPI flash and will be expected to boot without issues.
>>
>> Extend Intel service layer, FPGA manager and region drivers to support the
>> bitstream authentication feature.
>>
>> Richard Gong (7):
>> firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0
>> firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag
>> firmware: stratix10-svc: extend SVC driver to get the firmware version
>> fpga: fpga-mgr: add FPGA_MGR_BITSTREAM_AUTHENTICATE flag
>> fpga: of-fpga-region: add authenticate-fpga-config property
>> dt-bindings: fpga: add authenticate-fpga-config property
>> fpga: stratix10-soc: extend driver for bitstream authentication
>>
>> .../devicetree/bindings/fpga/fpga-region.txt | 10
>> drivers/firmware/stratix10-svc.c | 12 -
>> drivers/fpga/of-fpga-region.c | 24 ++---
>> drivers/fpga/stratix10-soc.c | 62
>> +++---
>> include/linux/firmware/intel/stratix10-smc.h | 21 +++-
>> .../linux/firmware/intel/stratix10-svc-client.h | 11 +++-
>> include/linux/fpga/fpga-mgr.h | 3 ++
>> 7 files changed, 125 insertions(+), 18 deletions(-)
>>
>> --
>> 2.7.4
>>
>
Re: [PATCH V2] Trivial typo fix and sentence construction for better readability
On Fri, Mar 19, 2021 at 01:03:02PM -0700, Randy Dunlap wrote: > > Hm, needs some spacing fixes IMO. See below. > > > On Sat, 20 Mar 2021, Bhaskar Chowdhury wrote: > > > > > s/funtion/functions/ > > > > Plus the sentence reconstructed for better readability. > > > > Signed-off-by: Bhaskar Chowdhury > > --- > > Changes from V1: > > Randy's suggestions incorporated. > > > > block/blk-mq-tag.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c > > index 9c92053e704d..c2bef283db63 100644 > > --- a/block/blk-mq-tag.c > > +++ b/block/blk-mq-tag.c > > @@ -373,8 +373,8 @@ static bool blk_mq_tagset_count_completed_rqs(struct > > request *rq, > > } > > > > /** > > - * blk_mq_tagset_wait_completed_request - wait until all completed req's > > - * complete funtion is run completion function That's my read of it. --Tom > > + * blk_mq_tagset_wait_completed_request - wait until all the req's > > the req's > > > + * functions completed their run > > and more indentation + wording on that line above: > *functions have completed their run > > > * @tagset: Tag set to drain completed request > > * > > * Note: This function has to be run after all IO queues are shutdown > > -- > > Thanks.
Re: [PATCH v3] cifs: Silently ignore unknown oplock break handle
LGTM feel free to add Reviewed-By: Tom Talpey On 3/19/2021 9:57 AM, Vincent Whitchurch wrote: Make SMB2 not print out an error when an oplock break is received for an unknown handle, similar to SMB1. The debug message which is printed for these unknown handles may also be misleading, so fix that too. The SMB2 lease break path is not affected by this patch. Without this, a program which writes to a file from one thread, and opens, reads, and writes the same file from another thread triggers the below errors several times a minute when run against a Samba server configured with "smb2 leases = no". CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2 : 424d53fe 0040 0012 .SMB@... 0010: 0001 0020: 0030: Signed-off-by: Vincent Whitchurch --- Notes: v3: - Change debug print to Tom Talpey's suggestion v2: - Drop change to lease break - Rewrite commit message fs/cifs/smb2misc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c index 60d4bd1eae2b..76cd05b8d53b 100644 --- a/fs/cifs/smb2misc.c +++ b/fs/cifs/smb2misc.c @@ -754,8 +754,8 @@ smb2_is_valid_oplock_break(char *buffer, struct TCP_Server_Info *server) } } spin_unlock(_tcp_ses_lock); - cifs_dbg(FYI, "Can not process oplock break for non-existent connection\n"); - return false; + cifs_dbg(FYI, "No file id matched, oplock break ignored\n"); + return true; } void
Re: [PATCH V3 XRT Alveo 13/18] fpga: xrt: devctl platform driver
On 3/16/21 4:54 PM, Lizhi Hou wrote:
>
>
> On 03/04/2021 05:39 AM, Tom Rix wrote:
>> CAUTION: This message has originated from an External Source. Please use
>> proper judgment and caution when opening attachments, clicking links, or
>> responding to this email.
>>
>>
>> On 2/17/21 10:40 PM, Lizhi Hou wrote:
>>> Add devctl driver. devctl is a type of hardware function which only has
>>> few registers to read or write. They are discovered by walking firmware
>>> metadata. A platform device node will be created for them.
>>>
>>> Signed-off-by: Sonal Santan
>>> Signed-off-by: Max Zhen
>>> Signed-off-by: Lizhi Hou
>>> ---
>>> drivers/fpga/xrt/include/xleaf/devctl.h | 43 +
>>> drivers/fpga/xrt/lib/xleaf/devctl.c | 206
>>> 2 files changed, 249 insertions(+)
>>> create mode 100644 drivers/fpga/xrt/include/xleaf/devctl.h
>>> create mode 100644 drivers/fpga/xrt/lib/xleaf/devctl.c
>>>
>>> diff --git a/drivers/fpga/xrt/include/xleaf/devctl.h
>>> b/drivers/fpga/xrt/include/xleaf/devctl.h
>>> new file mode 100644
>>> index ..96a40e066f83
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/include/xleaf/devctl.h
>>> @@ -0,0 +1,43 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for XRT DEVCTL Leaf Driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + * Lizhi Hou
>>> + */
>>> +
>>> +#ifndef _XRT_DEVCTL_H_
>>> +#define _XRT_DEVCTL_H_
>>> +
>>> +#include "xleaf.h"
>>> +
>>> +/*
>>> + * DEVCTL driver IOCTL calls.
>>> + */
>>> +enum xrt_devctl_ioctl_cmd {
>>> + XRT_DEVCTL_READ = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
>>> + XRT_DEVCTL_WRITE,
>>> +};
>>> +
>>> +enum xrt_devctl_id {
>>> + XRT_DEVCTL_ROM_UUID,
>> Assumes 0, should make this explicit and initialize to 0
> Sure.
>>> + XRT_DEVCTL_DDR_CALIB,
>>> + XRT_DEVCTL_GOLDEN_VER,
>>> + XRT_DEVCTL_MAX
>>> +};
>>> +
>>> +struct xrt_devctl_ioctl_rw {
>>> + u32 xgir_id;
>>> + void *xgir_buf;
>>> + u32 xgir_len;
>>> + u32 xgir_offset;
>> similar to other patches, the xgir_ prefix is not needed
>>> +};
>>> +
>>> +struct xrt_devctl_ioctl_intf_uuid {
>>> + u32 xgir_uuid_num;
>>> + uuid_t *xgir_uuids;
>>> +};
>>> +
>>> +#endif /* _XRT_DEVCTL_H_ */
>>> diff --git a/drivers/fpga/xrt/lib/xleaf/devctl.c
>>> b/drivers/fpga/xrt/lib/xleaf/devctl.c
>>> new file mode 100644
>>> index ..caf8c6569f0f
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/lib/xleaf/devctl.c
>>> @@ -0,0 +1,206 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Xilinx Alveo FPGA devctl Driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + * Lizhi Hou
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include "metadata.h"
>>> +#include "xleaf.h"
>>> +#include "xleaf/devctl.h"
>>> +
>>> +#define XRT_DEVCTL "xrt_devctl"
>>> +
>>> +struct xrt_name_id {
>>> + char *ep_name;
>>> + int id;
>>> +};
>>> +
>>> +static struct xrt_name_id name_id[XRT_DEVCTL_MAX] = {
>>> + { XRT_MD_NODE_BLP_ROM, XRT_DEVCTL_ROM_UUID },
>>> + { XRT_MD_NODE_GOLDEN_VER, XRT_DEVCTL_GOLDEN_VER },
>> DDR_CALIB is unused ?
> Not sure if I understand the question correctly. ddr_calib will have more
> things need to handle other than just read/write.
I do not understand either, ignore this comment.
If it is important, I will bring it up in a later revision's review and do a
better job of explaining the issue.
Tom
>>> +};
>>> +
>>> +struct xrt_devctl {
>>> + struct platform_device *pdev;
>>> + void __iomem *base_addrs[XRT_DEVCTL_MAX];
>>> + ulong sizes[XRT_DEVCTL_MAX];
>>> +};
>> similar to other patches, why not use regmap ?
> Will change to regmap.
>>> +
Re: [PATCH V3 XRT Alveo 08/18] fpga: xrt: main platform driver for management function device
On 3/16/21 2:23 PM, Lizhi Hou wrote:
> Hi Tom,
>
>
> On 02/26/2021 09:22 AM, Tom Rix wrote:
>> On 2/17/21 10:40 PM, Lizhi Hou wrote:
>>> platform driver that handles IOCTLs, such as hot reset and xclbin download.
>>>
>>> Signed-off-by: Sonal Santan
>>> Signed-off-by: Max Zhen
>>> Signed-off-by: Lizhi Hou
>>> ---
>>> drivers/fpga/xrt/include/xmgmt-main.h | 37 ++
>>> drivers/fpga/xrt/mgmt/main-impl.h | 37 ++
>>> drivers/fpga/xrt/mgmt/main.c | 693 ++
>>> include/uapi/linux/xrt/xmgmt-ioctl.h | 46 ++
>>> 4 files changed, 813 insertions(+)
>>> create mode 100644 drivers/fpga/xrt/include/xmgmt-main.h
>>> create mode 100644 drivers/fpga/xrt/mgmt/main-impl.h
>>> create mode 100644 drivers/fpga/xrt/mgmt/main.c
>>> create mode 100644 include/uapi/linux/xrt/xmgmt-ioctl.h
>>>
>>> diff --git a/drivers/fpga/xrt/include/xmgmt-main.h
>>> b/drivers/fpga/xrt/include/xmgmt-main.h
>>> new file mode 100644
>>> index ..1216d1881f8e
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/include/xmgmt-main.h
>>> @@ -0,0 +1,37 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for Xilinx Runtime (XRT) driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + * Cheng Zhen
>>> + */
>>> +
>>> +#ifndef _XMGMT_MAIN_H_
>>> +#define _XMGMT_MAIN_H_
>>> +
>>> +#include
>>> +#include "xleaf.h"
>>> +
>>> +enum xrt_mgmt_main_ioctl_cmd {
>>> + /* section needs to be vfree'd by caller */
>>> + XRT_MGMT_MAIN_GET_AXLF_SECTION = XRT_XLEAF_CUSTOM_BASE, /* See
>>> comments in xleaf.h */
>> the must free instructions should go with the pointer needing freeing
> Sure. Will move the free instructions.
>>> + /* vbnv needs to be kfree'd by caller */
>>> + XRT_MGMT_MAIN_GET_VBNV,
>>> +};
>>> +
>>> +enum provider_kind {
>>> + XMGMT_BLP,
>>> + XMGMT_PLP,
>>> + XMGMT_ULP,
>> what do these three mean ?
> Will add comment
>
> /* There are three kind of partitions. Each of them is programmed
> independently. */
> enum provider_kind {
> XMGMT_BLP, /* Base Logic Partition */
> XMGMT_PLP, /* Provider Logic Partition */
> XMGMT_ULP, /* User Logic Partition */
> };
>
looks good
>>> +};
>>> +
>>> +struct xrt_mgmt_main_ioctl_get_axlf_section {
>>> + enum provider_kind xmmigas_axlf_kind;
>>> + enum axlf_section_kind xmmigas_section_kind;
>>> + void *xmmigas_section;
>>> + u64 xmmigas_section_size;
>>> +};
>>> +
>>> +#endif /* _XMGMT_MAIN_H_ */
>>> diff --git a/drivers/fpga/xrt/mgmt/main-impl.h
>>> b/drivers/fpga/xrt/mgmt/main-impl.h
>> From prefix used in the functions, a better name for this file would be
>> xmgnt.h
> Will change.
>>> new file mode 100644
>>> index ..dd1b3e3773cc
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/mgmt/main-impl.h
>>> @@ -0,0 +1,37 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for Xilinx Alveo Management Function Driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + * Lizhi Hou
>>> + * Cheng Zhen
>>> + */
>>> +
>>> +#ifndef _XMGMT_MAIN_IMPL_H_
>>> +#define _XMGMT_MAIN_IMPL_H_
>>> +
>>> +#include
>>> +#include "xmgmt-main.h"
>>> +
>>> +struct fpga_manager;
>>> +int xmgmt_process_xclbin(struct platform_device *pdev,
>>> + struct fpga_manager *fmgr,
>>> + const struct axlf *xclbin,
>>> + enum provider_kind kind);
>>> +void xmgmt_region_cleanup_all(struct platform_device *pdev);
>>> +
>>> +int bitstream_axlf_mailbox(struct platform_device *pdev, const void
>>> *xclbin);
>> the prefix should be consistent
> Will fix this.
>>> +int xmgmt_hot_reset(struct platform_device *pdev);
>>> +
>>> +/* Getting dtb for specified group. Caller should vfree returned dtb .*/
>>> +char *xmgmt_get_dtb(struct platform_device *pdev, enum provider_kind kind);
>>> +char *xmgmt_get_vbnv(struct platform_device *pdev);
>>> +int xm
Re: [PATCH V3 XRT Alveo 07/18] fpga: xrt: management physical function driver (root)
On 3/16/21 1:29 PM, Max Zhen wrote:
> Hi Tom,
>
>
> On 2/26/21 7:01 AM, Tom Rix wrote:
>> CAUTION: This message has originated from an External Source. Please use
>> proper judgment and caution when opening attachments, clicking links, or
>> responding to this email.
>>
>>
>> A question i do not know the answer to.
>>
>> Seems like 'golden' is linked to a manufacturing (diagnostics?) image.
>>
>> If the public will never see it, should handling it here be done ?
>>
>> Moritz, do you know ?
>
>
> Golden image is preloaded on the device when it is shipped to customer. Then,
> customer can load other shells (from Xilinx or some other vendor). If
> something goes wrong with the shell, customer can always go back to golden
> and start over again. So, golden image is going to be used in public, not
> just internally by Xilinx.
>
>
Thanks for the explanation.
>>
>>
>> On 2/17/21 10:40 PM, Lizhi Hou wrote:
>>> The PCIE device driver which attaches to management function on Alveo
>> to the management
>
>
> Sure.
>
>
>>> devices. It instantiates one or more partition drivers which in turn
>> more fpga partition / group ?
>
>
> Group driver.
>
>
>>> instantiate platform drivers. The instantiation of partition and platform
>>> drivers is completely data driven.
>> data driven ? everything is data driven. do you mean dtb driven ?
>
>
> Data driven means not hard-coded. Here data means meta data which is
> presented in device tree format, dtb.
>
>
>>> Signed-off-by: Sonal Santan
>>> Signed-off-by: Max Zhen
>>> Signed-off-by: Lizhi Hou
>>> ---
>>> drivers/fpga/xrt/include/xroot.h | 114 +++
>>> drivers/fpga/xrt/mgmt/root.c | 342 +++
>>> 2 files changed, 456 insertions(+)
>>> create mode 100644 drivers/fpga/xrt/include/xroot.h
>>> create mode 100644 drivers/fpga/xrt/mgmt/root.c
>>>
>>> diff --git a/drivers/fpga/xrt/include/xroot.h
>>> b/drivers/fpga/xrt/include/xroot.h
>>> new file mode 100644
>>> index ..752e10daa85e
>>> --- /dev/null
>>> +++ b/drivers/fpga/xrt/include/xroot.h
>>> @@ -0,0 +1,114 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Header file for Xilinx Runtime (XRT) driver
>>> + *
>>> + * Copyright (C) 2020-2021 Xilinx, Inc.
>>> + *
>>> + * Authors:
>>> + * Cheng Zhen
>>> + */
>>> +
>>> +#ifndef _XRT_ROOT_H_
>>> +#define _XRT_ROOT_H_
>>> +
>>> +#include
>>> +#include "subdev_id.h"
>>> +#include "events.h"
>>> +
>>> +typedef bool (*xrt_subdev_match_t)(enum xrt_subdev_id,
>>> + struct platform_device *, void *);
>>> +#define XRT_SUBDEV_MATCH_PREV ((xrt_subdev_match_t)-1)
>>> +#define XRT_SUBDEV_MATCH_NEXT ((xrt_subdev_match_t)-2)
>>> +
>>> +/*
>>> + * Root IOCTL calls.
>>> + */
>>> +enum xrt_root_ioctl_cmd {
>>> + /* Leaf actions. */
>>> + XRT_ROOT_GET_LEAF = 0,
>>> + XRT_ROOT_PUT_LEAF,
>>> + XRT_ROOT_GET_LEAF_HOLDERS,
>>> +
>>> + /* Group actions. */
>>> + XRT_ROOT_CREATE_GROUP,
>>> + XRT_ROOT_REMOVE_GROUP,
>>> + XRT_ROOT_LOOKUP_GROUP,
>>> + XRT_ROOT_WAIT_GROUP_BRINGUP,
>>> +
>>> + /* Event actions. */
>>> + XRT_ROOT_EVENT,
>> should this be XRT_ROOT_EVENT_SYNC ?
>
>
> Sure.
>
>
>>> + XRT_ROOT_EVENT_ASYNC,
>>> +
>>> + /* Device info. */
>>> + XRT_ROOT_GET_RESOURCE,
>>> + XRT_ROOT_GET_ID,
>>> +
>>> + /* Misc. */
>>> + XRT_ROOT_HOT_RESET,
>>> + XRT_ROOT_HWMON,
>>> +};
>>> +
>>> +struct xrt_root_ioctl_get_leaf {
>>> + struct platform_device *xpigl_pdev; /* caller's pdev */
>> xpigl_ ? unneeded suffix in element names
>
>
> It's needed since the it might be included and used in > 1 .c files. I'd like
> to keep it's name unique.
This is an element name, the variable name sound be unique enough to make it
clear.
This is not a critical issue, ok as-is.
>
>
>>> + xrt_subdev_match_t xpigl_match_cb;
>>> + void *xpigl_match_arg;
>>> + struct platform_device *xpigl_leaf; /* target leaf pdev */
>>> +};
>>> +
>>> +struct xrt_root_ioctl_put_leaf {
&
Re: [PATCH v3 2/8] x86/sev: Do not require Hypervisor CPUID bit for SEV guests
On 3/12/21 6:38 AM, Joerg Roedel wrote: > From: Joerg Roedel > > A malicious hypervisor could disable the CPUID intercept for an SEV or > SEV-ES guest and trick it into the no-SEV boot path, where it could > potentially reveal secrets. This is not an issue for SEV-SNP guests, > as the CPUID intercept can't be disabled for those. > > Remove the Hypervisor CPUID bit check from the SEV detection code to > protect against this kind of attack and add a Hypervisor bit equals > zero check to the SME detection path to prevent non-SEV guests from > trying to enable SME. > > This handles the following cases: > > 1) SEV(-ES) guest where CPUID intercept is disabled. The guest > will still see leaf 0x801f and the SEV bit. It can > retrieve the C-bit and boot normally. > > 2) Non-SEV guests with intercepted CPUID will check SEV_STATUS > MSR and find it 0 and will try to enable SME. This will > fail when the guest finds MSR_K8_SYSCFG to be zero, as it > is emulated by KVM. But we can't rely on that, as there > might be other hypervisors which return this MSR with bit > 23 set. The Hypervisor bit check will prevent that the > guest tries to enable SME in this case. > > 3) Non-SEV guests on SEV capable hosts with CPUID intercept > disabled (by a malicious hypervisor) will try to boot into > the SME path. This will fail, but it is also not considered > a problem because non-encrypted guests have no protection > against the hypervisor anyway. > > Signed-off-by: Joerg Roedel Acked-by: Tom Lendacky > --- > arch/x86/boot/compressed/mem_encrypt.S | 6 - > arch/x86/kernel/sev-es-shared.c| 6 + > arch/x86/mm/mem_encrypt_identity.c | 35 ++ > 3 files changed, 20 insertions(+), 27 deletions(-) > > diff --git a/arch/x86/boot/compressed/mem_encrypt.S > b/arch/x86/boot/compressed/mem_encrypt.S > index aa561795efd1..a6dea4e8a082 100644 > --- a/arch/x86/boot/compressed/mem_encrypt.S > +++ b/arch/x86/boot/compressed/mem_encrypt.S > @@ -23,12 +23,6 @@ SYM_FUNC_START(get_sev_encryption_bit) > push%ecx > push%edx > > - /* Check if running under a hypervisor */ > - movl$1, %eax > - cpuid > - bt $31, %ecx /* Check the hypervisor bit */ > - jnc .Lno_sev > - > movl$0x8000, %eax /* CPUID to check the highest leaf */ > cpuid > cmpl$0x801f, %eax /* See if 0x801f is available */ > diff --git a/arch/x86/kernel/sev-es-shared.c b/arch/x86/kernel/sev-es-shared.c > index cdc04d091242..387b71669818 100644 > --- a/arch/x86/kernel/sev-es-shared.c > +++ b/arch/x86/kernel/sev-es-shared.c > @@ -186,7 +186,6 @@ void __init do_vc_no_ghcb(struct pt_regs *regs, unsigned > long exit_code) >* make it accessible to the hypervisor. >* >* In particular, check for: > - * - Hypervisor CPUID bit >* - Availability of CPUID leaf 0x801f >* - SEV CPUID bit. >* > @@ -194,10 +193,7 @@ void __init do_vc_no_ghcb(struct pt_regs *regs, unsigned > long exit_code) >* can't be checked here. >*/ > > - if ((fn == 1 && !(regs->cx & BIT(31 > - /* Hypervisor bit */ > - goto fail; > - else if (fn == 0x8000 && (regs->ax < 0x801f)) > + if (fn == 0x8000 && (regs->ax < 0x801f)) > /* SEV leaf check */ > goto fail; > else if ((fn == 0x801f && !(regs->ax & BIT(1 > diff --git a/arch/x86/mm/mem_encrypt_identity.c > b/arch/x86/mm/mem_encrypt_identity.c > index 6c5eb6f3f14f..a19374d26101 100644 > --- a/arch/x86/mm/mem_encrypt_identity.c > +++ b/arch/x86/mm/mem_encrypt_identity.c > @@ -503,14 +503,10 @@ void __init sme_enable(struct boot_params *bp) > > #define AMD_SME_BIT BIT(0) > #define AMD_SEV_BIT BIT(1) > - /* > - * Set the feature mask (SME or SEV) based on whether we are > - * running under a hypervisor. > - */ > - eax = 1; > - ecx = 0; > - native_cpuid(, , , ); > - feature_mask = (ecx & BIT(31)) ? AMD_SEV_BIT : AMD_SME_BIT; > + > + /* Check the SEV MSR whether SEV or SME is enabled */ > + sev_status = __rdmsr(MSR_AMD64_SEV); > + feature_mask = (sev_status & MSR_AMD64_SEV_ENABLED) ? AMD_SEV_BIT : > AMD_SME_BIT; > > /* >* Check for the SME/SEV feature: > @@ -530,19 +526,26 @@ void __init sme_enable(struct boot_params *bp) > > /* Ch
Re: [PATCH 0/7 v2] tracing: Have ring_buffer_event_time_stamp() work for all events
Hi Steve, On Tue, 2021-03-16 at 12:41 -0400, Steven Rostedt wrote: > Yordan has been working on a patch set that will not repeat functions > in the function tracer but instead show a single event that states > that > the previous function repeated X amount of times. I recommended that > this should also show the time of the last function that repeated. > To save on space, Yordan suggested to use a 32 bit delta instead of > a full 64 bit timestamp of the last event. But to create this delta, > we need a way to extract the time of the repeat event and use that > to calculate the delta of the last function event. > > But currently the ring_buffer_event_time_stamp() only works if all > events > has an absolute time stamp attached to it. That would be counter > productive > to make all functions record the full time stamp because we wanted to > use a 32 bit counter instead of a 64 bit counter for the rare repeat > event! > > This patch series makes ring_buffer_event_time_stamp() work for all > non committed events (after reserve and before it is committed). > The trick is that the per CPU descriptor of the buffer holds the time > stamp used for the event being processed. It has a nesting of 5 > levels > to deal with interrupts that add events. Extracting the time for the > event > can only be done for the current event being processed and not yet > committed. > > To achieve this, the buffer that the event is on needs to be passed > to > the ring_buffer_event_time_stamp(). That caused a bit of churn for > the histogram code, because that buffer wasn't available at the time > the ring_buffer_event_time_stamp() was called. Although the > hist_field > contained a pointer to the trace_array that holds the ring buffer, > if tracing was disabled, then a temporary buffer was used instead, > and that temporary buffer would need to be passed to the > ring_buffer_event_time_stamp(). That buffer is exposed to the trace > event > logic, but was not passed down into the trigger code. That had to be > done to take advantage of the new code. > > The second to last patch adds verifier logic (although commented out) > that was used to debug the issue when a temporary buffer was in use. > It proved to be very valuable and is kept in, in case this needs to > be > debugged again. > > Finally the last patch is for use with Yordan's work, and is needed > because > when filtering is enabled, the event being processed may not even be > on the buffer, and the tracing_event_time_stamp() checks for that and > will just use the current time stamp if the event is not reserved > yet. > This could be used also for the histogram code, but wanted to hold > off > on that. > > Changes since v1: > > - Applied change of last patch to pass buffer not trace_array > - Fixed prototype of stack_track_data_snapshot() when snapshot not > configured > > Steven Rostedt (VMware) (7): > ring-buffer: Separate out internal use of > ring_buffer_event_time_stamp() > ring-buffer: Add a event_stamp to cpu_buffer for each level of > nesting > tracing: Pass buffer of event to trigger operations > ring-buffer: Allow ring_buffer_event_time_stamp() to return > time stamp of all events > tracing: Use a no_filter_buffering_ref to stop using the filter > buffer > ring-buffer: Add verifier for using > ring_buffer_event_time_stamp() > tracing: Add tracing_event_time_stamp() API > > > include/linux/ring_buffer.h | 3 +- > include/linux/trace_events.h| 5 +- > kernel/trace/ring_buffer.c | 138 > ++-- > kernel/trace/trace.c| 38 +- > kernel/trace/trace.h | 9 +-- > kernel/trace/trace_events_hist.c| 100 +- > kernel/trace/trace_events_trigger.c | 45 +++- > 7 files changed, 239 insertions(+), 99 deletions(-) This all looks fine to me. Reviewed-by: Tom Zanussi
Re: [PATCH v2] cifs: Silently ignore unknown oplock break handle
On 3/16/2021 1:36 PM, Rohith Surabattula wrote: This issue will not be seen once changes related to deferred close for files is committed. That may be, but it's irrelevant to this. Currently, changes are in review. I will address review comments by this week. What do you mean by "in review"? Both threads are active on the mailing list. If you or others have something to discuss, please post it and don't leave us out of the discussion. Tom. Regards, Rohith On Tue, Mar 16, 2021 at 9:33 PM Tom Talpey wrote: On 3/16/2021 8:48 AM, Vincent Whitchurch via samba-technical wrote: Make SMB2 not print out an error when an oplock break is received for an unknown handle, similar to SMB1. The SMB2 lease break path is not affected by this patch. Without this, a program which writes to a file from one thread, and opens, reads, and writes the same file from another thread triggers the below errors several times a minute when run against a Samba server configured with "smb2 leases = no". CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2 : 424d53fe 0040 0012 .SMB@... 0010: 0001 0020: 0030: Signed-off-by: Vincent Whitchurch --- Notes: v2: - Drop change to lease break - Rewrite commit message fs/cifs/smb2misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c index 60d4bd1eae2b..4d8576e202e3 100644 --- a/fs/cifs/smb2misc.c +++ b/fs/cifs/smb2misc.c @@ -755,7 +755,7 @@ smb2_is_valid_oplock_break(char *buffer, struct TCP_Server_Info *server) } spin_unlock(_tcp_ses_lock); cifs_dbg(FYI, "Can not process oplock break for non-existent connection\n"); - return false; + return true; } void As an oplock-only approach, it looks good. But the old cifs_dbg message "non-existent connection" is possibly misleading, since the connection may be perfectly fine. When breaking the loop successfully, the code emits cifs_dbg(FYI, "file id match, oplock break\n"); so perhaps cifs_dbg(FYI, "No file id matched, oplock break ignored\n"); ? Tom.
[PATCH] Documentation: arm64/acpi : clarify arm64 support of IBFT
In commit 94bccc340710 ("iscsi_ibft: make ISCSI_IBFT dependson ACPI instead
of ISCSI_IBFT_FIND") Kconfig was disentangled to make ISCSI_IBFT selection
not depend on x86.
Update arm64 acpi documentation, changing IBFT support status from
"Not Supported" to "Optional".
Opportunistically re-flow paragraph for changed lines.
Link:
https://lore.kernel.org/lkml/1563475054-10680-1-git-send-email-thomas....@oracle.com/
Signed-off-by: Tom Saeger
---
Documentation/arm64/acpi_object_usage.rst | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/arm64/acpi_object_usage.rst
b/Documentation/arm64/acpi_object_usage.rst
index 377e9d224db0..0609da73970b 100644
--- a/Documentation/arm64/acpi_object_usage.rst
+++ b/Documentation/arm64/acpi_object_usage.rst
@@ -17,12 +17,12 @@ For ACPI on arm64, tables also fall into the following
categories:
- Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
- - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IORT,
- MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO,
- TCPA, TPM2, UEFI, XENV
+ - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IBFT,
+ IORT, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT,
+ STAO, TCPA, TPM2, UEFI, XENV
- - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT,
- MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
+ - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, MSDM, OEMx,
+ PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
==
Table Usage for ARMv8 Linux
--
2.31.0
Re: [PATCH v2] cifs: Silently ignore unknown oplock break handle
On 3/16/2021 8:48 AM, Vincent Whitchurch via samba-technical wrote: Make SMB2 not print out an error when an oplock break is received for an unknown handle, similar to SMB1. The SMB2 lease break path is not affected by this patch. Without this, a program which writes to a file from one thread, and opens, reads, and writes the same file from another thread triggers the below errors several times a minute when run against a Samba server configured with "smb2 leases = no". CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2 : 424d53fe 0040 0012 .SMB@... 0010: 0001 0020: 0030: Signed-off-by: Vincent Whitchurch --- Notes: v2: - Drop change to lease break - Rewrite commit message fs/cifs/smb2misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c index 60d4bd1eae2b..4d8576e202e3 100644 --- a/fs/cifs/smb2misc.c +++ b/fs/cifs/smb2misc.c @@ -755,7 +755,7 @@ smb2_is_valid_oplock_break(char *buffer, struct TCP_Server_Info *server) } spin_unlock(_tcp_ses_lock); cifs_dbg(FYI, "Can not process oplock break for non-existent connection\n"); - return false; + return true; } void As an oplock-only approach, it looks good. But the old cifs_dbg message "non-existent connection" is possibly misleading, since the connection may be perfectly fine. When breaking the loop successfully, the code emits cifs_dbg(FYI, "file id match, oplock break\n"); so perhaps cifs_dbg(FYI, "No file id matched, oplock break ignored\n"); ? Tom.
Re: Re: [BUG] net/ppp: A use after free in ppp_unregister_channe
On Mon, Mar 15, 2021 at 13:18:24 +0100, Guillaume Nault wrote:
> On Fri, Mar 12, 2021 at 10:47:53PM +0800, lyl2...@mail.ustc.edu.cn wrote:
> >
> >
> >
> > > -原始邮件-
> > > 发件人: "Tom Parkin"
> > > 发送时间: 2021-03-12 18:12:58 (星期五)
> > > 收件人: lyl2...@mail.ustc.edu.cn
> > > 抄送: pau...@samba.org, da...@davemloft.net, linux-...@vger.kernel.org,
> > > net...@vger.kernel.org, linux-kernel@vger.kernel.org
> > > 主题: Re: [BUG] net/ppp: A use after free in ppp_unregister_channe
> > >
> > > Thanks for the report!
> > >
> > > On Thu, Mar 11, 2021 at 20:34:44 +0800, lyl2...@mail.ustc.edu.cn wrote:
> > > > File: drivers/net/ppp/ppp_generic.c
> > > >
> > > > In ppp_unregister_channel, pch could be freed in ppp_unbridge_channels()
> > > > but after that pch is still in use. Inside the function
> > > > ppp_unbridge_channels,
> > > > if "pchbb == pch" is true and then pch will be freed.
> > >
> > > Do you have a way to reproduce a use-after-free scenario?
> > >
> > > From static analysis I'm not sure how pch would be freed in
> > > ppp_unbridge_channels when called via. ppp_unregister_channel.
> > >
> > > In theory (at least!) the caller of ppp_register_net_channel holds
> > > a reference on struct channel which ppp_unregister_channel drops.
> > >
> > > Each channel in a bridged pair holds a reference on the other.
> > >
> > > Hence on return from ppp_unbridge_channels, the channel should not have
> > > been freed (in this code path) because the ppp_register_net_channel
> > > reference has not yet been dropped.
> > >
> > > Maybe there is an issue with the reference counting or a race of some
> > > sort?
> > >
> > > > I checked the commit history and found that this problem is introduced
> > > > from
> > > > 4cf476ced45d7 ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN
> > > > ioctls").
> > > >
> > > > I have no idea about how to generate a suitable patch, sorry.
> >
> > This issue was reported by a path-sensitive static analyzer developed by
> > our Lab,
> > thus i have not a crash or bug log.
> >
> > As the return type of ppp_unbridge_channels() is a int, can we return a
> > value to
> > inform caller that the channel is freed?
>
> I don't think this is going to improve anything, as
> ppp_unregister_channel() couldn't take any corrective action anyway.
I agree with you to be honest.
I think the best ppp_unregister_channel could to is to not access pch
again.
signature.asc
Description: PGP signature
Re: Re: [BUG] net/ppp: A use after free in ppp_unregister_channe
On Fri, Mar 12, 2021 at 22:47:53 +0800, lyl2...@mail.ustc.edu.cn wrote:
>
>
>
> > -原始邮件-----
> > 发件人: "Tom Parkin"
> > 发送时间: 2021-03-12 18:12:58 (星期五)
> > 收件人: lyl2...@mail.ustc.edu.cn
> > 抄送: pau...@samba.org, da...@davemloft.net, linux-...@vger.kernel.org,
> > net...@vger.kernel.org, linux-kernel@vger.kernel.org
> > 主题: Re: [BUG] net/ppp: A use after free in ppp_unregister_channe
> >
> > Thanks for the report!
> >
> > On Thu, Mar 11, 2021 at 20:34:44 +0800, lyl2...@mail.ustc.edu.cn wrote:
> > > File: drivers/net/ppp/ppp_generic.c
> > >
> > > In ppp_unregister_channel, pch could be freed in ppp_unbridge_channels()
> > > but after that pch is still in use. Inside the function
> > > ppp_unbridge_channels,
> > > if "pchbb == pch" is true and then pch will be freed.
> >
> > Do you have a way to reproduce a use-after-free scenario?
> >
> > From static analysis I'm not sure how pch would be freed in
> > ppp_unbridge_channels when called via. ppp_unregister_channel.
> >
> > In theory (at least!) the caller of ppp_register_net_channel holds
> > a reference on struct channel which ppp_unregister_channel drops.
> >
> > Each channel in a bridged pair holds a reference on the other.
> >
> > Hence on return from ppp_unbridge_channels, the channel should not have
> > been freed (in this code path) because the ppp_register_net_channel
> > reference has not yet been dropped.
> >
> > Maybe there is an issue with the reference counting or a race of some
> > sort?
> >
> > > I checked the commit history and found that this problem is introduced
> > > from
> > > 4cf476ced45d7 ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls").
> > >
> > > I have no idea about how to generate a suitable patch, sorry.
>
> This issue was reported by a path-sensitive static analyzer developed by our
> Lab,
> thus i have not a crash or bug log.
Does the analyzer report the sequence of events that lead to a
possible use-after-free? Is it starting from the assumption that
ppp_unbridge_channels is called with pch->file.refcnt == 1?
> As the return type of ppp_unbridge_channels() is a int, can we return a value
> to
> inform caller that the channel is freed?
If ppp_unbridge_channels frees the channel in the
ppp_unregister_channel call path, that implies that
ppp_unregister_channel is called when only the bridge is keeping the
channel alive. So the caller is attempting to drop a reference it
doesn't in fact have.
It might be preferable to defensively code against that possibility of
course.
signature.asc
Description: PGP signature
Re: [PATCH v10 3/5] fpga: m10bmc-sec: expose max10 canceled keys in sysfs
On 3/12/21 11:36 AM, Russ Weight wrote: > Extend the MAX10 BMC Secure Update driver to provide sysfs > files to expose the canceled code signing key (CSK) bit > vectors. These use the standard bitmap list format > (e.g. 1,2-6,9). > > Signed-off-by: Russ Weight > Reviewed-by: Tom Rix > --- > v10: > - Changed the path expressions in the sysfs documentation to > replace the n3000 reference with something more generic to > accomodate other devices that use the same driver. > v9: > - Rebased to 5.12-rc2 next > - Updated Date and KernelVersion in ABI documentation > v8: > - Previously patch 4/6, otherwise no change > v7: > - Updated Date and KernelVersion in ABI documentation > v6: > - Added WARN_ON() call for (size / stride) to ensure > that the proper count is passed to regmap_bulk_read(). > v5: > - No change > v4: > - Moved sysfs files for displaying the code-signing-key (CSK) > cancellation vectors from the FPGA Security Manger class driver > to here. The m10bmc_csk_vector() and m10bmc_csk_cancel_nbits() > functions are removed and the functionality from these functions > is moved into a show_canceled_csk() function for for displaying > the CSK vectors. > - Added ABI documentation for new sysfs entries > v3: > - Changed: iops -> sops, imgr -> smgr, IFPGA_ -> FPGA_, ifpga_ to fpga_ > - Changed "MAX10 BMC Secure Engine driver" to "MAX10 BMC Secure Update > driver" > - Removed wrapper functions (m10bmc_raw_*, m10bmc_sys_*). The > underlying functions are now called directly. > - Renamed get_csk_vector() to m10bmc_csk_vector() > v2: > - Replaced small function-creation macros for explicit function > declarations. > - Fixed get_csk_vector() function to properly apply the stride > variable in calls to m10bmc_raw_bulk_read() > - Added m10bmc_ prefix to functions in m10bmc_iops structure > --- > .../testing/sysfs-driver-intel-m10-bmc-secure | 24 ++ > drivers/fpga/intel-m10-bmc-secure.c | 48 +++ > 2 files changed, 72 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > index 598db1116d34..93ad4de9b941 100644 > --- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > @@ -28,6 +28,30 @@ Description: Read only. Returns the root entry hash > for the BMC image > underlying device supports it. > Format: "0x%x". > > +What: > /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/sr_canceled_csks This is fine. Reviewed-by: Tom Rix > +Date:April 2021 > +KernelVersion: 5.13 > +Contact: Russ Weight > +Description: Read only. Returns a list of indices for canceled code > + signing keys for the static region. The standard bitmap > + list format is used (e.g. "1,2-6,9"). > + > +What: > /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/pr_canceled_csks > +Date:April 2021 > +KernelVersion: 5.13 > +Contact: Russ Weight > +Description: Read only. Returns a list of indices for canceled code > + signing keys for the partial reconfiguration region. The > + standard bitmap list format is used (e.g. "1,2-6,9"). > + > +What: > /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/bmc_canceled_csks > +Date:April 2021 > +KernelVersion: 5.13 > +Contact: Russ Weight > +Description: Read only. Returns a list of indices for canceled code > + signing keys for the BMC. The standard bitmap list format > + is used (e.g. "1,2-6,9"). > + > What: > /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/flash_count > Date:April 2021 > KernelVersion: 5.13 > diff --git a/drivers/fpga/intel-m10-bmc-secure.c > b/drivers/fpga/intel-m10-bmc-secure.c > index ecd63c13cb2d..87e16c146569 100644 > --- a/drivers/fpga/intel-m10-bmc-secure.c > +++ b/drivers/fpga/intel-m10-bmc-secure.c > @@ -79,6 +79,51 @@ DEVICE_ATTR_SEC_REH_RO(bmc, BMC_PROG_MAGIC, BMC_PROG_ADDR, > BMC_REH_ADDR); > DEVICE_ATTR_SEC_REH_RO(sr, SR_PROG_MAGIC, SR_PROG_ADDR, SR_REH_ADDR); > DEVICE_ATTR_SEC_REH_RO(pr, PR_PROG_MAGIC, PR_PROG_ADDR, PR_REH_ADDR); > > +#define CSK_BIT_LEN 128U > +#define CSK_32ARRAY_SIZE DIV_ROUND_UP(CSK_BIT_LEN, 32) > + > +static ssize_t > +show_canceled_csk(struct device *dev, u32 addr, char *buf)
Re: [PATCH v10 1/5] fpga: m10bmc-sec: create max10 bmc secure update driver
On 3/12/21 11:36 AM, Russ Weight wrote: > Create a platform driver that can be invoked as a sub > driver for the Intel MAX10 BMC in order to support > secure updates. This sub-driver will invoke an > instance of the FPGA Security Manager class driver > in order to expose sysfs interfaces for managing and > monitoring secure updates to FPGA and BMC images. > > This patch creates the MAX10 BMC Secure Update driver and > provides sysfs files for displaying the current root entry hashes > for the FPGA static region, the FPGA PR region, and the MAX10 > BMC. > > Signed-off-by: Russ Weight > --- > v10: > - Changed the path expressions in the sysfs documentation to > replace the n3000 reference with something more generic to > accomodate other devices that use the same driver. > v9: > - Rebased to 5.12-rc2 next > - Updated Date and KernelVersion in ABI documentation > v8: > - Previously patch 2/6, otherwise no change > v7: > - Updated Date and KernelVersion in ABI documentation > v6: > - Added WARN_ON() call for (sha_num_bytes / stride) to assert > that the proper count is passed to regmap_bulk_read(). > v5: > - No change > v4: > - Moved sysfs files for displaying the root entry hashes (REH) > from the FPGA Security Manager class driver to here. The > m10bmc_reh() and m10bmc_reh_size() functions are removed and > the functionality from these functions is moved into a > show_root_entry_hash() function for displaying the REHs. > - Added ABI documentation for the new sysfs entries: > sysfs-driver-intel-m10-bmc-secure > - Updated the MAINTAINERS file to add the new ABI documentation > file: sysfs-driver-intel-m10-bmc-secure > - Removed unnecessary ret variable from m10bmc_secure_probe() > - Incorporated new devm_fpga_sec_mgr_register() function into > m10bmc_secure_probe() and removed the m10bmc_secure_remove() > function. > v3: > - Changed from "Intel FPGA Security Manager" to FPGA Security Manager" > - Changed: iops -> sops, imgr -> smgr, IFPGA_ -> FPGA_, ifpga_ to fpga_ > - Changed "MAX10 BMC Secure Engine driver" to "MAX10 BMC Secure > Update driver" > - Removed wrapper functions (m10bmc_raw_*, m10bmc_sys_*). The > underlying functions are now called directly. > - Changed "_root_entry_hash" to "_reh", with a comment explaining > what reh is. > v2: > - Added drivers/fpga/intel-m10-bmc-secure.c file to MAINTAINERS. > - Switched to GENMASK(31, 16) for a couple of mask definitions. > - Moved MAX10 BMC address and function definitions to a separate > patch. > - Replaced small function-creation macros with explicit function > declarations. > - Removed ifpga_sec_mgr_init() and ifpga_sec_mgr_uinit() functions. > - Adapted to changes in the Intel FPGA Security Manager by splitting > the single call to ifpga_sec_mgr_register() into two function > calls: devm_ifpga_sec_mgr_create() and ifpga_sec_mgr_register(). > --- > .../testing/sysfs-driver-intel-m10-bmc-secure | 29 > MAINTAINERS | 2 + > drivers/fpga/Kconfig | 11 ++ > drivers/fpga/Makefile | 3 + > drivers/fpga/intel-m10-bmc-secure.c | 135 ++ > 5 files changed, 180 insertions(+) > create mode 100644 > Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > create mode 100644 drivers/fpga/intel-m10-bmc-secure.c > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > new file mode 100644 > index ..bd3ee9bc1a92 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-secure > @@ -0,0 +1,29 @@ > +What: > /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/sr_root_entry_hash This is fine. Reviewed-by: Tom Rix > +Date:April 2021 > +KernelVersion: 5.13 > +Contact: Russ Weight > +Description: Read only. Returns the root entry hash for the static > + region if one is programmed, else it returns the > + string: "hash not programmed". This file is only > + visible if the underlying device supports it. > + Format: "0x%x". > + > +What: > /sys/bus/platform/drivers/intel-m10bmc-secure/.../security/pr_root_entry_hash > +Date:April 2021 > +KernelVersion: 5.13 > +Contact: Russ Weight > +Description: Read only. Returns the root entry hash for the partial > + reconfiguration region if one is prog
Re: [PATCH] include: linux: Fix a typo in the file fs.h
On Sat, Mar 13, 2021 at 10:49:55AM +0530, Bhaskar Chowdhury wrote: > s/varous/various/ > > Signed-off-by: Bhaskar Chowdhury > --- > include/linux/fs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index ec8f3ddf4a6a..c37a17c32d74 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1051,7 +1051,7 @@ bool opens_in_grace(struct net *); > * FIXME: should we create a separate "struct lock_request" to help > distinguish > * these two uses? > * > - * The varous i_flctx lists are ordered by: > + * The various i_flctx lists are ordered by: > * > * 1) lock owner > * 2) lock range start > -- > 2.26.2 > How about a few more? found by running: codespell -w -i 3 include/linux/fs.h 'specialy' could be 'special' or 'specialty' it can be dropped altogether IMO, so I did. --Tom diff --git a/include/linux/fs.h b/include/linux/fs.h index c37a17c32d74..9ffea695a059 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -126,7 +126,7 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, /* File is opened with O_EXCL (only set for block devices) */ #define FMODE_EXCL ((__force fmode_t)0x80) /* File is opened using open(.., 3, ..) and is writeable only for ioctls - (specialy hack for floppy.c) */ + (hack for floppy.c) */ #define FMODE_WRITE_IOCTL ((__force fmode_t)0x100) /* 32bit hashes as llseek() offset (for directories) */ #define FMODE_32BITHASH ((__force fmode_t)0x200) @@ -819,7 +819,7 @@ void lock_two_nondirectories(struct inode *, struct inode*); void unlock_two_nondirectories(struct inode *, struct inode*); /* - * NOTE: in a 32bit arch with a preemptable kernel and + * NOTE: in a 32bit arch with a preemptible kernel and * an UP compile the i_size_read/write must be atomic * with respect to the local cpu (unlike with preempt disabled), * but they don't need to be atomic with respect to other cpus like in
Re: [PATCH V3] cpufreq: Rudimentary typos fix in the file s5pv210-cpufreq.c
On Sat, Mar 13, 2021 at 09:19:51AM +0530, Bhaskar Chowdhury wrote:
>
> Trivial spelling fixes throughout the file.
>
LGTM
Reviewed-by: Tom Saeger
> Signed-off-by: Bhaskar Chowdhury
> ---
> Changes from V2:
> Incoporated the findings of Tom Saeger
>
> drivers/cpufreq/s5pv210-cpufreq.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
> b/drivers/cpufreq/s5pv210-cpufreq.c
> index 69786e5bbf05..73110b005716 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -91,7 +91,7 @@ static DEFINE_MUTEX(set_freq_lock);
> /* Use 800MHz when entering sleep mode */
> #define SLEEP_FREQ (800 * 1000)
>
> -/* Tracks if cpu freqency can be updated anymore */
> +/* Tracks if cpu frequency can be updated anymore */
> static bool no_cpufreq_access;
>
> /*
> @@ -190,7 +190,7 @@ static u32 clkdiv_val[5][11] = {
>
> /*
> * This function set DRAM refresh counter
> - * accoriding to operating frequency of DRAM
> + * according to operating frequency of DRAM
> * ch: DMC port number 0 or 1
> * freq: Operating frequency of DRAM(KHz)
> */
> @@ -320,7 +320,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
>
> /*
>* 3. DMC1 refresh count for 133Mhz if (index == L4) is
> - * true refresh counter is already programed in upper
> + * true refresh counter is already programmed in upper
>* code. 0x287@83Mhz
>*/
> if (!bus_speed_changing)
> @@ -378,7 +378,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
> /*
>* 6. Turn on APLL
>* 6-1. Set PMS values
> - * 6-2. Wait untile the PLL is locked
> + * 6-2. Wait until the PLL is locked
>*/
> if (index == L0)
> writel_relaxed(APLL_VAL_1000, S5P_APLL_CON);
> @@ -390,7 +390,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
> } while (!(reg & (0x1 << 29)));
>
> /*
> - * 7. Change souce clock from SCLKMPLL(667Mhz)
> + * 7. Change source clock from SCLKMPLL(667Mhz)
>* to SCLKA2M(200Mhz) in MFC_MUX and G3D MUX
>* (667/4=166)->(200/4=50)Mhz
>*/
> @@ -439,7 +439,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
> }
>
> /*
> - * L4 level need to change memory bus speed, hence onedram clock divier
> + * L4 level needs to change memory bus speed, hence onedram clock
> divider
>* and memory refresh parameter should be changed
>*/
> if (bus_speed_changing) {
> --
> 2.26.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
