kvm-ioctls: Add KVM_X86_SET_MSR_FILTER vm ioctl

[ludfjig]

Summary of the PR

Adds KVM_X86_SET_MSR_FILTER vm ioctl. This is my first contribution so I might be missing something, feedback greatly appreciated. I'm not sure whether there needs to be an actual test running vcpu that tries to read/write some MSR

Closes #358

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[ludfjig]

CI is red, but looks unrelated to this change I believe

[RuoqingHe]

CI is red, but looks unrelated to this change I believe

Yes, leave it to me

[roypat]

I wonder if we could have a slightly higher level, but safe API here. E.g. kvm_msr_filer::bitmap is a pointer to array of u8s that has nmsrs many bits. We could just have an function that takes a Vec, range checks against nmsrs, and then convert its arguments to the kvm_msr_filter structure and does the ioctl maybe? The other args could even be enums then I think

[ludfjig]

I wonder if we could have a slightly higher level, but safe API here. E.g. kvm_msr_filer::bitmap is a pointer to array of u8s that has nmsrs many bits. We could just have an function that takes a Vec, range checks against nmsrs, and then convert its arguments to the kvm_msr_filter structure and does the ioctl maybe? The other args could even be enums then I think

Thanks for reviewing. That sounds reasonable to me. Do you prefer to have 2 versions of it around (keep the old function around as an unsafe _unchecked()), or do you only want the safe one?

[ludfjig]

Note this comment