kern: Introduce RLIMIT_VMM
AcceptedPublic
Actions

Authored by bnovkov on Thu, Nov 13, 11:13 AM.

Details

Reviewers

markj
olce
corvink

Group Reviewers

bhyve

Summary

This change introduces a new per-UID limit for controlling the
number of vmm instances, in anticipation of unprivileged bhyve.
This limit is designed to prevent a user from creating an unlimited
amount of vmm instances.

Sponsored by: The FreeBSD Foundation
Sponsored by: Klara, Inc.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

bnovkov created this revision.Thu, Nov 13, 11:13 AM

Herald added a reviewer: olce. · View Herald TranscriptThu, Nov 13, 11:13 AM

Herald added subscribers: olce, imp. · View Herald Transcript

bnovkov requested review of this revision.Thu, Nov 13, 11:13 AM

Harbormaster completed remote builds in B68594: Diff 166350.Thu, Nov 13, 11:13 AM

bnovkov added a child revision: D53729: vmm: Add ability to destroy VMs on close.Thu, Nov 13, 11:13 AM

corvink added a subscriber: corvink.Fri, Nov 14, 6:54 AM

corvink added inline comments.

sys/dev/vmm/vmm_dev.c
991	Why changing this to thread?
1187	It would be great to explain in the commit message why we want to restrict the number of vmms and especially, why we're choosing this default value.

Address @corvink 's comments.

bnovkov added inline comments.Mon, Nov 17, 2:47 PM

sys/dev/vmm/vmm_dev.c
991	Whoops, that was a leftover from an unrelated previous attempt, thanks for catching it!
1187	I've expanded the commit message, but the limit itself is fairly arbitrary. I'm open to suggestions if you think there's a more reasonable value.

corvink accepted this revision.Tue, Nov 18, 6:53 AM

corvink added inline comments.

sys/dev/vmm/vmm_dev.c
1187	I just prefer that we're adding a short reason why choosing this default limit. If it's just a random pick, it's fine but it's worth mentioning in the commit message that it's just a random pick. So, if someone ever wonders why we've chosen this limit he can check the commit message.

This revision is now accepted and ready to land.Tue, Nov 18, 6:53 AM

usr.bin/procstat/procstat_rlimit.c should be updated too.

sys/dev/vmm/vmm_dev.c
20	This sorts after queue.h.
1187	I agree, there should be a comment. Thinking a bit more, having a max of 1024 is a bit silly, it's possibly too low on large count-count machines. Maybe let's just have it be 4mp_ncpus or 8mp_ncpus? Also this needs to be overridable with a tunable, like hw.vmm.maxcpu above.
sys/kern/kern_resource.c
1776