- User Since
- Aug 11 2014, 8:37 PM (231 w, 5 d)
Sep 17 2018
Jun 8 2018
Apr 27 2018
Apr 25 2018
I've also fixed up the frame->tf_rip == (long)doreti_iret code in trap().
Thanks also for sharing your test program! I ended up reling on a tweaking to the ucontext_t too:
The current code works because the offset of pc_pti_stack in struct pcpu is such that:
Apr 24 2018
Apr 18 2018
Add top of PTI stack to PCPU to avoid it's calculation in cpu_switch().
Apr 17 2018
I've updated the diff to incorporate the feedback.
I've updated the diff to incorporate the feedback.
Apr 16 2018
As requested, I've updated the patch with full context.
Apr 13 2018
Mar 10 2018
Mar 9 2018
Mar 7 2018
The changes I proposed in the comments here, and reviewed in D14548, have been committed.
Mar 6 2018
Not to make this my magnus opus, but based on some offline discussion with jhb, I had still left some room for improvement. I believe I've addressed those concerns with this updated diff.
Mar 2 2018
Mar 1 2018
Include KASSERT suggested by jhb.
Feb 28 2018
Feb 15 2018
If you capture VMCS_GUEST_INTR_STATUS in the EXIT_REASON_HLT case of vmx_exit_process() then you can use that value in vmx_pending_intr() without having to use a vmx_getreg(). That circumvents the locking issue, removes the need for the special case #ifdef INVARIANTS/#endif code and may even improve the latency by skipping an iteration of VMPTRLD() and VMCLEAR().
Feb 12 2018
While a conditional branch dependent on global variable isn't quite the same as an indirect branch dependent on a global variable, it would seem the opportunity still exists to evict the cache line containing the global variable to give the CPU some time to speculatively execute in the neighborhood of the branch. What I've seen in other implementation is the placement of the rsb flushing code before any branches. Perhaps that's overly conservative but I think we should follow that approach too.
Feb 8 2018
Jan 15 2018
Dec 21 2017
Replace magic constants with #define, within the function, to clarify usage.
Jul 28 2017
May 19 2017
May 18 2017
Seems reasonable to me.
Mar 30 2017
Mar 29 2017
Is everyone reasonably content with this?
Mar 24 2017
Deleted debug drivel which snuck in.
Addressed Mark's request to create a function to capture the siginfo_t for the specific thread, and clear the stale siginfo_t for other threads, in the process receiving the signal.
Mar 23 2017
Mar 22 2017
I've reverted back to a note-per-thread and (hopefully) addressed some review comments.
I think I've incorporated all the feedback I received with the exception of adding to the procstat output the additional data collected in the 'gcore' case. In that case, the core file contains more data than I'm printing but I'm struggling on how to format it in a useful way. That could make a reasonable follow on commit.
Mar 20 2017
Sorry to be so noisy that's twice now that Differential threw away my inline note. To belabor the point, the structsize is part of the note itself to support procstat -- because that's how 'procstat' notes are formatted. If we don't want to use procstat to view the note I can omit the structsize but it does seem like a nice to have. That's assuming that the size of the note is sufficient for rudimentary versioning otherwise this is just a reinforcement of that.
Missed inline comment and the structsize being part of the note itself.
Thanks for the reviews. I will incorporate the feedback; some of which I have replied to 'inline'. Mark, I'll also take another pass at the usage and initialization of 'td_dbgksi'.
Mar 17 2017
Mark noted my diff was missing some context. I've generated with "svnlite diff -x -U9999".
This needs a bit more polish (and testing) but at a higher level how's this?
Mar 14 2017
Jun 26 2015
Jun 11 2015
Jun 10 2015
Jun 9 2015
This restructuring will be really handy. However, I think it's possible
to unify the handling of 'sysmem' and 'devmem' such that 'sysmem'
differs from 'devmem' only in persistance and accessibility (PROT_*).
May 21 2015
May 4 2015
Thanks, that makes sense. Looks good to me!
This looks very nice. My only feedback is that I got confused as to whether or not the "return fault (*fault)" provided by vmm_fetch_instruction was boolean or not. In most cases it was treated as such, but you've actually got the information to do better. Specifically around line 624 in the new vmm_instruction_emul.c you could set *fault to IDT_SS or IDT_GP. If you think no one will ever care about the specific fault, perhaps renaming fault to is_fault would further cement it's boolean nature.
Apr 25 2015
Dec 30 2014
Dec 29 2014
I'm still in the process of reviewing this, however at first glance I'm not sure I see any reason to remove the HPET Legacy Routing support.
Dec 19 2014
So odd that SFN was implemented minus the ability to actually enable it. Seems like the priority to commit jumped the priority to complete ;-)
Dec 16 2014
I had written a similar test-stub when I wrote the code originally. Obviously, I misinterpreted the results :-(
Dec 14 2014
Looks good to me.
Sep 9 2014
This looks good!
Aug 22 2014
Looks good to me, thanks for finding and fixing it!