ibm-capi / libcxl Goto Github PK

Hi,

/var/lib/jenkins/workspace/SNAP_Software/pslse/common/misc/cxl.h:150: error: declaration does not declare anything
snap.c: In function 'hw_wait_irq':
snap.c:311: error: 'struct cxl_event' has no member named 'irq'
snap.c:311: error: 'struct cxl_event' has no member named 'irq'
snap.c:314: error: 'struct cxl_event' has no member named 'irq'
snap.c:324: error: 'struct cxl_event' has no member named 'afu_error'
snap.c:324: error: 'struct cxl_event' has no member named 'afu_error'
make[1]: *** [snap.o] Error 1
make[1]: Leaving directory `/var/lib/jenkins/workspace/SNAP_Software/snap/software/lib'
make: *** [lib] Error 1

struct cxl_event {
struct cxl_event_header header;
union {
struct cxl_event_afu_interrupt irq;
struct cxl_event_data_storage fault;
struct cxl_event_afu_error afu_error;
struct cxl_event_afu_driver_reserved afu_driver_event;
};
};
 
line 150 is the end of the union which does not have a name. Please have a look what can be done.

Thanks

Frank

Hola! @vaibhav92 has created a ZenHub account for the ibm-capi organization. ZenHub is the only project management tool integrated natively in GitHub – created specifically for fast-moving, software-driven teams.

How do I use ZenHub?

To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.

What can ZenHub do?

ZenHub adds a series of enhancements directly inside the GitHub UI:

• Real-time, customizable task boards for GitHub issues;
• Multi-Repository burndown charts, estimates, and velocity tracking based on GitHub Milestones;
• Personal to-do lists and task prioritization;
• Time-saving shortcuts – like a quick repo switcher, a “Move issue” button, and much more.

Add ZenHub to GitHub

Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @vaibhav92.

Freeing the afu handle from a different thread is not leading to the desired results. Translation misses can occur and stop handle/hardware from working.

Background: We allocated the afu handle by the first thread which was required to use it. We added a reference counter associated with the handle. We started a number of threads which where sharing the handle to communicate with a hardware-workqueue. The idea was to have the last thread which uses the queue, check the reference counter, and once that drops to free the afu handle.

Result: We got memory translation misses and therefore failures when trying to operate our hardware.

Circumvention: We needed to keep the thread which allocated the handle alive throughout the whole queue lifetime. Our next experiment is to use a special thread to allocate/free the afu handle and taking care that this is alive across the whole time we need to talk to our hardware queue.

We are currently talking to the developers to understand why this restriction exists and if there is any possibility to remove it long term. It appears that the restriction is in the CAPI Linux infrastructure, rather than in libcxl. Until there is a more intuitive solution, we obviously need to implement the afu access as mentioned before.

The last patch
@@ -916,7 +927,10 @@ int cxl_read_event(struct cxl_afu_h *afu, struct cxl_event *event)
afu->event_buf_end = (struct cxl_event *)
((char *)afu->event_buf + size);

• return fetch_cached_event(afu, event);
• rc = fetch_cached_event(afu, event);
• if (p)

•   free(p);
  

• return rc;

does somehow corrupt our memory in a way that the next free after the free above results in a core dump. I was not able to find any leak in our memory but removing this "free(p)" did fix the problem.
So the free must be moved to cxl_afu_free()

cxl_mmio_read32() and cxl_mmio_read64() consider it an error if a mmio read returns 0xfffffff... (all 1's).
By default when reading 0xffffff, it raises SIGBUS, which terminates the process.

Instead, libcxl should consider 0xffffff... as a hint that an error might have occurred and run extra checks to know for sure. It is similar to what the kernel is doing. The issue is how to do it from userland.

Hello,
my problem : #include "capi.h"(go-qml/qml#180)

guest@system:/tmp/libcxl$ ls
libcxl.c  libcxl.h  libcxl_internal.h  libcxl_sysfs.c  LICENSE  Makefile  Makefile.rules  Makefile.vars  man3  README.md  symver.map
guest@system:/tmp/libcxl$ make && make install
	[CC]	 libcxl.o
libcxl.c: In function ‘cxl_mmio_write64’:
libcxl.c:1074:2: error: invalid 'asm': invalid operand code 'U'
  __asm__ __volatile__("sync ; stw%U0%X0 %1,%0"
  ^
libcxl.c:1078:2: error: invalid 'asm': invalid operand code 'U'
  __asm__ __volatile__("sync ; stw%U0%X0 %1,%0"
  ^
Makefile.rules:22: recipe for target 'libcxl.o' failed
make: *** [libcxl.o] Error 1

How can Fix this?

sudo yum install libcxl-devel dapl-devel

A make gives the following error.

...
make -C hxeocapi
make[2]: Entering directory `/home/santosh/HTX/bin/hxeocapi'
cc -D__HTX_LINUX__ -DTRUE=1 -DFALSE=0 -D__64BIT__ -D__HTX_LE__ -O2 -g -D_GNU_SOURCE -D__HTX_LINUX__ -I/usr/local/include -I./ -I/usr/include/ -I/home/santosh/HTX//export/ppc64le//include/ -c get_rule.c -o get_rule.o
In file included from hxeocapi.h:23:0,
                 from get_rule.c:22:
memcpy.h:26:21: fatal error: libocxl.h: No such file or directory
 #include <libocxl.h>
                     ^
compilation terminated.
make[2]: *** [get_rule.o] Error 1
make[2]: Leaving directory `/home/santosh/HTX/bin/hxeocapi'
make[1]: *** [hxeocapi] Error 2
make[1]: Leaving directory `/home/santosh/HTX/bin'
make: *** [bin] Error 2

There is no file name libocxl in /usr/include, changing the include to libcxl.h leads to more errors.