s/read hardware/real hardware/ in the commit message I think.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 7 2022
Feb 3 2022
Jan 18 2022
Jan 17 2022
Jan 13 2022
Dec 29 2021
Dec 28 2021
Fix kp comments
Thanks! Will run the universe build if there are no further comments.
Nov 23 2021
Nov 18 2021
Nov 17 2021
Nov 16 2021
Nov 12 2021
Thanks for the update, I'm going over the dependencies to check how this all fits together.
Nov 10 2021
Forgot to hit summit yesterday...
Nov 8 2021
In D30726#742538, @ehem_freebsd_m5p.com wrote:In D30726#742521, @royger wrote:I'm unsure you actually need to split those apart. Wouldn't Arm also require some kind of locking of the architecture specific bits?
See D30936. The goal is everything being protected by xen_intr_x86_lock is very x86-specific and destined to split away from this file. Whereas the portions which remain protected by xen_intr_isrc_lock are mostly architecture-independent and will remain in this file. Splitting the locks allows them to be static.
I'm unsure you actually need to split those apart. Wouldn't Arm also require some kind of locking of the architecture specific bits?
Oct 27 2021
Can you please base this on top of current code? AFAICT there's no need to move those fields to xen_arch_isrc just to end up removing them afterwards.
Oct 21 2021
Oct 20 2021
Oct 15 2021
LGTM, will push
Sep 17 2021
Aug 31 2021
In D31711#716440, @ehem_freebsd_m5p.com wrote:No, then you would be doing arithmetic on a void pointer, which isn't officially legal (size of void being undefined). Better to do the math on integers and cast to the correct type.
On second thought it might have been easier to just cast to void * and forget about the parentheses.
Aug 29 2021
In D31711#715619, @dim wrote:In D31711#715616, @royger wrote:I think you can also remove the cast to vm_paddr_t while there, the field is declared as uint64_t.
Hm, won't that give problems on i386? I'll see what a i386 build does.
I think you can also remove the cast to vm_paddr_t while there, the field is declared as uint64_t.
Aug 12 2021
In D31507#710357, @kib wrote:Note that 'relocatable' means variyng not VA, but PA. Loader still maps the kernel at KERNBASE.
Aug 11 2021
Aug 2 2021
Jul 28 2021
Jul 14 2021
I would name this xen_percpu_evtchn{_enabled} or some such. Given the current usage I think xen_support_evtchn_rebind is confusing, as it's not about rebinding an event channel, but being able to assign event channels to vCPUs.
Jul 7 2021
Jul 2 2021
Jul 1 2021
Jun 30 2021
Just replied to the most controversial part I think, will try to review the rest tomorrow. Thanks!
Jun 22 2021
Jun 16 2021
Thanks and sorry for the delay! Mostly nits, I think the only major question is whether you need to use the dma system to allocate the memory for the vcpu time infos. I think it would be fine to just use plain malloc.
Jun 15 2021
Jun 11 2021
Thanks! For the record: the lock is not currently needed given the only caller has APs and interrupts disabled. I'm fine with adding this safeguard, but it should be noted in the commit message IMO that this is not currently an issue.