Page MenuHomeFreeBSD

Correct undesirable interaction between caching of %cr4 in bhyve and invltlb_glob().
ClosedPublic

Authored by kib on Apr 19 2018, 11:28 PM.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kib created this revision.Apr 19 2018, 11:28 PM
kib updated this revision to Diff 41668.Apr 19 2018, 11:29 PM

Update comment (actually commit the last edits).

jhb accepted this revision.Apr 20 2018, 5:00 PM

This looks sensible to me.

This revision is now accepted and ready to land.Apr 20 2018, 5:00 PM
grehan accepted this revision.Apr 21 2018, 7:01 PM
grehan added a subscriber: grehan.

This looks fine, though I'm interested in the circumstances that this can happen - can module-load pre-empt an existing kernel thread that is in the midst of invltlb_glob() ?

kib added a comment.Apr 21 2018, 8:05 PM

This looks fine, though I'm interested in the circumstances that this can happen - can module-load pre-empt an existing kernel thread that is in the midst of invltlb_glob() ?

Yes, exactly. I did not see anything in the vmm.ko load code which disabled preemption, and preemption can happen while pmap does an invalidation in the kernel pmap. We only pin the thread, we do not enter critical section there.

Of course, it is very bad luck to actually get it in real life. I did not, I just read the code.

BTW, there is another similar 'unlikely thing I saw in vmx_support.S. vmx_enter_guest uses stack space below the bottom to form the INVEPT descriptor. Until very recent time, we could get e.g. MCE executed on the thread stack with interrupts disabled. MCE was changed to use IST, but IMO we should be more careful. And, amd64 kernel does not use red zone.

This revision was automatically updated to reflect the committed changes.