lkml.org 
[lkml]   [2012]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v2 3/5] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO
    From
    From: Avi Kivity <avi@redhat.com>
    Subject: Re: [PATCH v2 3/5] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO
    Date: Thu, 14 Jun 2012 16:37:58 +0300

    > On 05/16/2012 10:55 AM, zhangyanfei wrote:
    <cut>
    >> +
    >> +/*
    >> + * The format of VMCSINFO is given below:
    >> + * +-------------+--------------------------+
    >> + * | Byte offset | Contents |
    >> + * +-------------+--------------------------+
    >> + * | 0 | VMCS revision identifier |
    >> + * +-------------+--------------------------+
    >> + * | 4 | <field><encoded offset> |
    >> + * +-------------+--------------------------+
    >> + * | 16 | <field><encoded offset> |
    >> + * +-------------+--------------------------+
    >> + * ......
    >> + *
    >> + * The first 32 bits of VMCSINFO contains the VMCS revision
    >> + * identifier.
    >> + * The remainder of VMCSINFO is used for <field><encoded offset>
    >> + * sets. Each set takes 12 bytes: field occupys 4 bytes
    >> + * and its corresponding encoded offset occupys 8 bytes.
    >> + *
    >> + * Encoded offsets are raw values read by vmcs_read{16, 64, 32, l},
    >> + * and they are all unsigned extended to 8 bytes for each
    >> + * <field><encoded offset> set has the same size.
    >> + * We do not decode offsets here. The decoding work is delayed
    >> + * in userspace tools.
    >
    > It's better to do the decoding here, or no one will know how to do it.
    > Also have an nfields field.

    We did so because actual internal format is unkown; it could possibly
    be encrypted, although unlikely. We thought processing such unkown
    data should have been done in userland debugging tools. But decoding
    them here is no problem; the decode is of simple shift operations and
    has no risk affecting system status, there's only possibility to
    display broken values, which is same as the case displaying the
    encrypted values for users.

    FYI, the assumptions behind the reverse enginerring method are:

    - For each field, the corresponding offset is unique; IOW, arbitrary
    two offsets for the corresponding two fields are different each
    other.
    - Field size remains 8 bytes, 16 bytes, 32 bytes even on vmcs region.
    - Each field is 8 byte alighed on vmcs region.
    - Some fields may be big endition on vmcs region.
    - We found this fact under development. We give up if the data is
    modified more drastically.
    - offset < vmcs region size

    Thanks.
    HATAYAMA, Daisuke



    \
     
     \ /
      Last update: 2012-06-15 05:41    [W:0.026 / U:149.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site