Thanks!

In D35001#793469, @jhb wrote:

I'm axing the devclass argument to DRIVER_MODULE since it is unused the vast majority of the time. If you'd rather not hardcode the string we could instead use driver->name instead of the hardcoded string.

Note however that we hardcode the driver name a few lines below in the call to BUS_ADD_CHILD, so if we are really worried about that then we need to change BUS_ADD_CHILD to also use driver->name.

Hm, isn't this more fragile, as we need to keep the string in driver_t in sync with the call to devclass_find()?

Pull out tsc_init calls from the early_clock_source_init() handlers.

It might be better to pull tsc_init() call out of the hook implementation, now that all of them call it anyway.

• Rebase over changes in tsc.c.
• Add KASSERT.
• Call tsc_init from Xen PVH early_clock_source_init hook.

Update vt man page.

s/read hardware/real hardware/ in the commit message I think.

Update comment.

Fix kp comments

Thanks! Will run the universe build if there are no further comments.

Thanks for the update, I'm going over the dependencies to check how this all fits together.

Forgot to hit summit yesterday...

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?

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.

LGTM, will push

For Xen bits.

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.

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.

In D31507#710357, @kib wrote:

Note that 'relocatable' means variyng not VA, but PA. Loader still maps the kernel at KERNBASE.