[PATCH v2 3/5] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO

[HATAYAMA Daisuke]

From: Avi Kivity <avi at 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