ioctls: Don't panic on unsupported exit reason #195
Conversation
sboeuf
requested review from
acatangiu,
alxiord,
andreeaflorescu,
lauralt and
sameo
as code owners
|
In our case, this is particularly useful to support |
src/ioctls/vcpu.rs
Outdated
| /// Corresponds to an exit reason that is unknown from the current version | ||
| /// of the kvm-ioctls crate. Let the consumer decide about what to do with | ||
| /// it. | ||
| Future(u32), |
There was a problem hiding this comment.
Can we have it as Unknown instead?
There was a problem hiding this comment.
I wanted to use Unknown, but there's an actual KVM exit reason called KVM_EXIT_UNKNOWN :(
Do you have any other idea?
There was a problem hiding this comment.
Right, I forgot about that one. We can name it Unsupported? Returning this as Unsupported is not going to bring much information though, it is just a stepping stone I assume until we add the actual variants defined here?
There was a problem hiding this comment.
Really funny, a known unknown and an unknown unknown:)
There was a problem hiding this comment.
Really funny, a known unknown and an unknown unknown:)
Exactly 😆
There was a problem hiding this comment.
Yes I think Unsupported would be appropriate here.
There was a problem hiding this comment.
it is just a stepping stone I assume until we add the actual variants defined here?
Yes exactly, but we have to wait for these things to land in upstream Linux kernel before we can update the kvm-bindings and kvm-ioctls.
In case the underlying KVM version is more recent than what is known and supported by the kvm-ioctls crate, and in case KVM reports an unknown reason for a VM exit, we don't want the vCPU run() to panic. A more elegant way of handling such situation is by propagating the exit reason up to the consumer's crate as it might know what to do with it. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
In case the underlying KVM version is more recent than what is known
and supported by the kvm-ioctls crate, and in case KVM reports an
unknown reason for a VM exit, we don't want the vCPU run() to panic.
A more elegant way of handling such situation is by propagating the exit
reason up to the consumer's crate as it might know what to do with it.
Signed-off-by: Sebastien Boeuf sebastien.boeuf@intel.com