From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> To: avi@redhat.com Cc: zhangyanfei@cn.fujitsu.com, mtosatti@redhat.com, ebiederm@xmission.com, luto@mit.edu, joerg.roedel@amd.com, dzickus@redhat.com, paul.gortmaker@windriver.com, ludwig.nussel@suse.de, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kexec@lists.infradead.org, gregkh@linuxfoundation.org Subject: Re: [PATCH v2 3/5] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO Date: Fri, 15 Jun 2012 12:03:46 +0900 (JST) [thread overview] Message-ID: <20120615.120346.21747125.d.hatayama@jp.fujitsu.com> (raw) In-Reply-To: <4FD9E936.3030001@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> To: avi@redhat.com Cc: dzickus@redhat.com, luto@mit.edu, kvm@vger.kernel.org, joerg.roedel@amd.com, mtosatti@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, paul.gortmaker@windriver.com, zhangyanfei@cn.fujitsu.com, ebiederm@xmission.com, gregkh@linuxfoundation.org, ludwig.nussel@suse.de Subject: Re: [PATCH v2 3/5] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO Date: Fri, 15 Jun 2012 12:03:46 +0900 (JST) [thread overview] Message-ID: <20120615.120346.21747125.d.hatayama@jp.fujitsu.com> (raw) In-Reply-To: <4FD9E936.3030001@redhat.com> 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-06-15 3:04 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-05-16 7:50 [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump zhangyanfei 2012-05-16 7:50 ` zhangyanfei 2012-05-16 7:52 ` [PATCH v2 1/5] x86: Add helper variables and functions to hold VMCSINFO zhangyanfei 2012-05-16 7:52 ` zhangyanfei 2012-06-14 13:28 ` Avi Kivity 2012-06-14 13:28 ` Avi Kivity 2012-06-14 13:28 ` Avi Kivity 2012-05-16 7:54 ` [PATCH v2 2/5] KVM: Export symbols for module vmcsinfo-intel zhangyanfei 2012-05-16 7:54 ` zhangyanfei 2012-05-16 7:54 ` zhangyanfei 2012-05-16 7:55 ` [PATCH v2 3/5] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO zhangyanfei 2012-05-16 7:55 ` zhangyanfei 2012-05-16 7:55 ` zhangyanfei 2012-06-14 13:37 ` Avi Kivity 2012-06-14 13:37 ` Avi Kivity 2012-06-14 13:37 ` Avi Kivity 2012-06-15 3:03 ` HATAYAMA Daisuke [this message] 2012-06-15 3:03 ` HATAYAMA Daisuke 2012-05-16 7:56 ` [PATCH v2 4/5] ksysfs: Export VMCSINFO via sysfs zhangyanfei 2012-05-16 7:56 ` zhangyanfei 2012-05-16 7:56 ` zhangyanfei 2012-05-16 7:57 ` [PATCH v2 5/5] Documentation: Add ABI entry for sysfs file vmcsinfo and vmcsinfo_maxsize zhangyanfei 2012-05-16 7:57 ` zhangyanfei 2012-05-16 7:57 ` zhangyanfei 2012-06-14 13:21 ` Avi Kivity 2012-06-14 13:21 ` Avi Kivity 2012-06-14 13:21 ` Avi Kivity 2012-05-20 17:43 ` [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump Avi Kivity 2012-05-20 17:43 ` Avi Kivity 2012-05-20 17:43 ` Avi Kivity 2012-05-21 2:32 ` Yanfei Zhang 2012-05-21 2:32 ` Yanfei Zhang 2012-05-21 8:34 ` Avi Kivity 2012-05-21 8:34 ` Avi Kivity 2012-05-21 8:34 ` Avi Kivity 2012-05-21 9:08 ` Yanfei Zhang 2012-05-21 9:08 ` Yanfei Zhang 2012-05-21 9:08 ` Yanfei Zhang 2012-05-21 9:36 ` Avi Kivity 2012-05-21 9:36 ` Avi Kivity 2012-05-21 9:36 ` Avi Kivity 2012-05-22 3:40 ` Yanfei Zhang 2012-05-22 3:40 ` Yanfei Zhang 2012-05-22 3:40 ` Yanfei Zhang 2012-05-28 5:25 ` Yanfei Zhang 2012-05-28 5:25 ` Yanfei Zhang 2012-05-28 13:28 ` Avi Kivity 2012-05-28 13:28 ` Avi Kivity 2012-05-28 13:28 ` Avi Kivity 2012-05-29 7:06 ` Yanfei Zhang 2012-05-29 7:06 ` Yanfei Zhang 2012-06-11 5:35 ` Yanfei Zhang 2012-06-11 5:35 ` Yanfei Zhang 2012-06-11 5:35 ` Yanfei Zhang 2012-06-14 13:15 ` Avi Kivity 2012-06-14 13:15 ` Avi Kivity 2012-06-14 13:15 ` Avi Kivity 2012-06-18 7:25 ` YOSHIDA Masanori 2012-06-18 7:25 ` YOSHIDA Masanori 2012-06-18 7:25 ` YOSHIDA Masanori 2012-05-21 18:58 ` Eric Northup 2012-05-21 18:58 ` Eric Northup 2012-05-21 18:58 ` Eric Northup 2012-05-22 3:53 ` Yanfei Zhang 2012-05-22 3:53 ` Yanfei Zhang 2012-05-22 3:53 ` Yanfei Zhang 2012-05-22 20:53 ` Eric Northup 2012-05-22 20:53 ` Eric Northup 2012-05-22 20:53 ` Eric Northup
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20120615.120346.21747125.d.hatayama@jp.fujitsu.com \ --to=d.hatayama@jp.fujitsu.com \ --cc=avi@redhat.com \ --cc=dzickus@redhat.com \ --cc=ebiederm@xmission.com \ --cc=gregkh@linuxfoundation.org \ --cc=joerg.roedel@amd.com \ --cc=kexec@lists.infradead.org \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=ludwig.nussel@suse.de \ --cc=luto@mit.edu \ --cc=mtosatti@redhat.com \ --cc=paul.gortmaker@windriver.com \ --cc=zhangyanfei@cn.fujitsu.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.