Re: [PATCH 1/13] KVM: userspace interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Arnd Bergmann wrote:
On Thursday 26 October 2006 19:22, Avi Kivity wrote:
+
+/* for KVM_RUN */
+struct kvm_run {
+       /* in */
+       __u32 vcpu;
+       __u32 emulated;  /* skip current instruction */
+       __u32 mmio_completed; /* mmio request completed */
+
+       /* out */
+       __u32 exit_type;
+       __u32 exit_reason;
+       __u32 instruction_length;
+       union {
+               /* KVM_EXIT_UNKNOWN */
+               struct {
+                       __u32 hardware_exit_reason;
+               } hw;
+               /* KVM_EXIT_EXCEPTION */
+               struct {
+                       __u32 exception;
+                       __u32 error_code;
+               } ex;
+               /* KVM_EXIT_IO */
+               struct {
+#define KVM_EXIT_IO_IN  0
+#define KVM_EXIT_IO_OUT 1
+                       __u8 direction;
+                       __u8 size; /* bytes */
+                       __u8 string;
+                       __u8 string_down;
+                       __u8 rep;
+                       __u8 pad;
+                       __u16 port;
+                       __u64 count;
+                       union {
+                               __u64 address;
+                               __u32 value;
+                       };
+               } io;
+               struct {
+               } debug;
+               /* KVM_EXIT_MMIO */
+               struct {
+                       __u64 phys_addr;
+                       __u8  data[8];
+                       __u32 len;
+                       __u8  is_write;
+               } mmio;
+       };
+};

This data structure looks like it can become maintenance problem. It's
already sufficiently complex that I would assume that you need to extend
it in the future even further, which is hard to do in a compatible
way. How confident are you that, for a given exit reason, you don't need
to add or extend the existing fields further, thereby breaking the ABI?
Do you have a plan how to deal with such breakage?


I guess we can reserve some extra space, and if we need even more space a new exit reason can specify a pointer to receive the exit data.

Of course, userspace should not get an unexpected exit reason. I'm not worried about the short term, since it's likely there will only be a single user (modified qemu), long term we'll have userspace enable new features explicitly.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux