|
Description
Luke Kenneth Casson Leighton
2022-10-01 17:36:49 BST
system calls in power-gem5: https://github.com/gem5/gem5/blob/stable/src/sim/syscall_emul.cc https://github.com/gem5/gem5/blob/stable/src/arch/power/linux/se_workload.cc#L109 there will be similar in both qemu and cavatools. qemu system calls: https://github.com/qemu/qemu/blob/master/linux-user/ppc/syscall.tbl here's how they are called: https://github.com/qemu/qemu/blob/master/linux-user/ppc/cpu_loop.c#L336 very interesting! cavatools simply passes the syscall directly to the host operating system, in assembler https://www.felixcloutier.com/x86/syscall.html https://github.com/phaa-eu/cavatools/blob/main/uspike/proxy_syscall.cc#L57 Well, good news is, I did this a lot, there's nothing new here. :-) (In reply to Dmitry Selyutin from comment #5) > Well, good news is, I did this a lot, there's nothing new here. :-) i think the python version should do full syscall emulation rather than attempt to proxy to real ones. the only reason proxy works in cavatools is because it is using *actual* userspace memory (!) for ISACaller any "memory" is entirely emulated. (In reply to Luke Kenneth Casson Leighton from comment #6) > the only reason proxy works in cavatools is because it is using > *actual* userspace memory (!) This sounds really creepy. > for ISACaller any "memory" is entirely emulated. This is the way to go. imho eur 6000 for the pseudocode to C compiler is fine, don't let our discussion about what exactly we should do for that task block submitting to nlnet. (In reply to Dmitry Selyutin from comment #7) > (In reply to Luke Kenneth Casson Leighton from comment #6) > > the only reason proxy works in cavatools is because it is using > > *actual* userspace memory (!) > > This sounds really creepy. it's how cavatools gets 250 million instructions per second per process per host core, where other emulators are a minimum of 20x slower and flat-out incapable of multi-core support! peter hsu did not design cavatools to be "pretty and nicey-nicey", he designed it to give developers of applications a good chance at *real-time* high-performance computationally-extreme emulation, so that you can test an application *in full*, iteratiely adding new instructions and new micro-architectures, getting the design right before dropping 16 to 32 ***MILLION*** dollars on Mask Charges, only to find that you utterly screwed up. this is not qemu. we are not in kansas no more. > > for ISACaller any "memory" is entirely emulated. > > This is the way to go. in ISACaller yes. and we can expect performance to degrade even further than it already is. however, we get readable code. I dropped all the links from the overall task description to keep it reduced to a task list. Any reader should carefully check the entire task discussion anyway, so here these links are: https://libre-soc.org/nlnet_2021_3mdeb_cavatools/ https://github.com/phaa-eu/cavatools https://www.bsc.es/research-and-development/software-and-apps/software-list/cavatools Updated the milestones for the subtasks. What should be the next step? Ping to all interested parties. (In reply to Dmitry Selyutin from comment #11) > Updated the milestones for the subtasks. What should be the next step? i thought it might be sensible to put a "management" budget on here, part for you writing the mou, part for me, and part for future updates to budget-sync and other odds. my feeling is that cavatools eabi is going to be near-trivial, it can come down to EUR 4000. management can be EUR 3000, that leaves EUR 1000 which can go into one or more other tasks which are abit low. #976 and #958? (In reply to Luke Kenneth Casson Leighton from comment #13) > (In reply to Dmitry Selyutin from comment #11) > > Updated the milestones for the subtasks. What should be the next step? > > i thought it might be sensible to put a "management" budget on here, > part for you writing the mou, part for me, and part for future > updates to budget-sync and other odds. Fair enough, I agree, but with a remark below. > my feeling is that cavatools eabi is going to be near-trivial, > it can come down to EUR 4000. management can be EUR 3000, that > leaves EUR 1000 which can go into one or more other tasks which > are abit low. #976 and #958? I also have a strange feeling that works around integration will need more resources, too. I'm not the one to judge, since I haven't checked this part yet, but I'd be really surprised if integrating cavatools to our testing API would be trivial. But I'm afraid this is to be discovered yet. I'm unlikely to do it due to time constraints, but others will almost certainly handle it. How about the scheme below? 1. Cut ABI tasks to 4500 EUR each (#981, #982). 2. Since we now have 5000 EUR, we can assign 3000 EUR to management, 500 EUR to #976, 500 EUR to #958, and 1000 EUR for wrapup which can migrate to #985 if possible? Or we can assign 1000 EUR #985 immediately if you can confirm this is a difficult one. I'm not sure of the level of gdb support we have now. If OK, I will raise the management task with 3000 EUR, will assign 500 EUR to each #976 and #958, and will move the 1000 EUR to either wrapup or #985, depending on our conclusions. TL;DR: I feel that #985 is underestimated too; please let me know your opinion. (In reply to Dmitry Selyutin from comment #14) > Fair enough, I agree, but with a remark below. ack > > my feeling is that cavatools eabi is going to be near-trivial, > > it can come down to EUR 4000. management can be EUR 3000, that > > leaves EUR 1000 which can go into one or more other tasks which > > are abit low. #976 and #958? > > I also have a strange feeling that works around integration will need more > resources, too. I'm not the one to judge, since I haven't checked this part > yet, but I'd be really surprised if integrating cavatools to our testing API > would be trivial. yes, very. cavatools already supports gdbmi - gdb remote machine interface. a new register-set-definition is needed, but that's needed anyway. > But I'm afraid this is to be discovered yet. I'm unlikely > to do it due to time constraints, but others will almost certainly handle > it. How about the scheme below? > > 1. Cut ABI tasks to 4500 EUR each (#981, #982). ahh ISACaller ABI is *not* trivial: unlike cavatools which thunks directly onto existing EABIs with a trivial shim (so as to get absolute max performance) ISACaller has to implement a **FULL** and **TOTAL** implementation... in python. there _may_ be an existing implementation out there but finding it will be a pig: try searching "linux abi implementation in python" > 2. Since we now have 5000 EUR, we can assign 3000 EUR to management, 500 EUR > to #976, 500 EUR to #958, and 1000 EUR for wrapup which can migrate to #985 > if possible? sure. > Or we can assign 1000 EUR #985 immediately if you can confirm this is a > difficult one. I'm not sure of the level of gdb support we have now. full remote gdb machine interface is in cavatools. but only RV. not ppc64le. > If OK, I will raise the management task with 3000 EUR, will assign 500 EUR > to each #976 and #958, and will move the 1000 EUR to either wrapup or #985, > depending on our conclusions. Updated: https://bugs.libre-soc.org/show_bug.cgi?id=981: 8000 => 4500 https://bugs.libre-soc.org/show_bug.cgi?id=982: 6000 => 4500 https://bugs.libre-soc.org/show_bug.cgi?id=958: 2500 => 3000 https://bugs.libre-soc.org/show_bug.cgi?id=976: 1000 => 1500 https://bugs.libre-soc.org/show_bug.cgi?id=987: 0 => 3000 (management task) https://bugs.libre-soc.org/show_bug.cgi?id=939: 0 => 1000 (this task) Upd: comment #17 Upd: assigned 1000 from wrapup to cavatools test API support (1000 EUR from #939 => #985) (In reply to Dmitry Selyutin from comment #17) > https://bugs.libre-soc.org/show_bug.cgi?id=939: 0 => 1000 (this task) really, that EUR 1000 should be in the management task. but you've not put a subtask budget for it. i'm re-running budget-sync to check things. ERROR:root:Total budget assigned to payees (cf_payees_list) doesn't match expected value: bug #987, calculated total 500, expected value 3000 ERROR:root:Bug's assigned milestone doesn't match the milestone assigned to the root bug: descendant bug #988, root bug #961 yep you've assigned EUR 500 to yourself but the remaining EUR 2500 is unassigned *within* that task. what instead must be done is to create a sub-task of #987. (In reply to Luke Kenneth Casson Leighton from comment #20) > what instead must be done is to create a sub-task of #987. done, sorted. i double-checked the comment #0 totals, they're EUR 50,000. i'll send comment #0 as the Schedule A to Michiel, along with a JSON file. andrey you added two extra tasks, remember to let people know by putting the commit diff link here https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=a3f5eea083 |