lkml.org 
[lkml]   [2006]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/13] KVM: userspace interface
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-10-27 07:55    [W:3.208 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site