Page MenuHomeFreeBSD

vmm(4), bhyve(8): Expose kernel-emulated special devices to userspace
ClosedPublic

Authored by cem on Apr 21 2020, 9:26 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 22, 9:29 PM
Unknown Object (File)
Fri, Mar 22, 9:29 PM
Unknown Object (File)
Fri, Mar 22, 9:29 PM
Unknown Object (File)
Fri, Mar 22, 9:29 PM
Unknown Object (File)
Fri, Mar 22, 9:29 PM
Unknown Object (File)
Mar 8 2024, 8:34 AM
Unknown Object (File)
Jan 4 2024, 10:39 PM
Unknown Object (File)
Jan 4 2024, 10:39 PM
Subscribers

Details

Summary

Expose the special kernel LAPIC, IOAPIC, and HPET devices to userspace
for use in, e.g., fallback instruction emulation (when userspace has a
newer instruction decode/emulation layer than the kernel vmm(4)).

Plumb the ioctl through libvmmapi and register the memory ranges in
bhyve(8).

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Don't panic the kernel if the user-supplied address range isn't in a known range.

sys/amd64/include/vmm_dev.h
273 ↗(On Diff #70860)

This needs to be added to the capability list in vmmapi.c:vm_get_ioctls()

usr.sbin/bhyve/apic.c
1 ↗(On Diff #70860)

minor naming nit: maybe kernemu_dev.c or similar ?

cem planned changes to this revision.Apr 28 2020, 4:14 PM

Thanks for taking a look! Does this approach seem plausibly reasonable, outside of the implementation-detail type issues already raised? Without it or something like it, I don't think we can really emulate instructions in userspace. I first looked at using the existing memory interface, but ordinary reads and writes have no way to specify the accessing vcpu, and the specific vcpu is essential for these magic regions.

sys/amd64/include/vmm_dev.h
273 ↗(On Diff #70860)

Thanks, I missed that.

Other similar ioctls seem to have GET/SET separate versions, but I'm not sure it buys us anything here. Are you ok with the combined get/setter ioctl, or should I split this one up as well?

usr.sbin/bhyve/apic.c
1 ↗(On Diff #70860)

Sure, that works for me. I'll rename the _init routine to correspond.

Thanks for taking a look! Does this approach seem plausibly reasonable, outside of the implementation-detail type issues already raised?

Yep, I think it's ok.

Other similar ioctls seem to have GET/SET separate versions, but I'm not sure it buys us anything here.
Are you ok with the combined get/setter ioctl, or should I split this one up as well?

Hmmm, if you're going to revisit the code anyway, it might be worth splitting that out for consistency.

cem marked 2 inline comments as done.
  • Split into two ioctls
  • Rename bhyve component s/apic/kernemu_dev/
  • Add ioctls to vm_get_ioctls()
This revision is now accepted and ready to land.May 15 2020, 4:05 AM