rus_vm_fault: always use a packet on the stack

There are valid use cases where a remote page fault has no available
thread data/packet available to use, e.g. when device driver threads
need to access the data (BXI).

Do the per thread data lookup to use the right channel/tid if available,
and use mcctrl_ikc_send_wait with a new message number directly.

The fault is no longer handled in mckernel syscall forwarding code but
in the ikc handler directly in irq, this should be ok because page
faults are interrupts anyway so the code should be irq-safe.

Change-Id: Ie60f413cdaee6c1a824b4a2c93637899cb9bf9c9
This commit is contained in:
Dominique Martinet
2018-12-25 10:58:58 +01:00
committed by Dominique Martinet
parent 8074445d59
commit a5d5baf8a8
7 changed files with 150 additions and 303 deletions

View File

@ -52,6 +52,9 @@
#define SCD_MSG_PROCFS_ANSWER 0x13
#define SCD_MSG_PROCFS_RELEASE 0x15
#define SCD_MSG_REMOTE_PAGE_FAULT 0x18
#define SCD_MSG_REMOTE_PAGE_FAULT_ANSWER 0x19
#define SCD_MSG_DEBUG_LOG 0x20
#define SCD_MSG_SYSFS_REQ_CREATE 0x30
@ -295,6 +298,14 @@ struct ikc_scd_packet {
void *resp;
int *spin_sleep; /* 1: waiting in linux_wait_event() 0: woken up by someone else */
} futex;
/* SCD_MSG_REMOTE_PAGE_FAULT */
struct {
int target_cpu;
int fault_tid;
unsigned long fault_address;
unsigned long fault_reason;
};
};
/* char padding[8]; */ /* We want the size to be 128 bytes */
};
@ -312,7 +323,6 @@ struct syscall_response {
unsigned long req_thread_status;
long ret;
unsigned long fault_address;
unsigned long fault_reason;
};
struct syscall_post {