From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Nadav Har'El" <nyh@math.technion.ac.il>
Cc: Gleb Natapov <gleb@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [PATCH] KVM: nVMX: Fix content of MSR_IA32_VMX_ENTRY/EXIT_CTLS
Date: Mon, 04 Mar 2013 16:52:14 +0100 [thread overview]
Message-ID: <5134C32E.3030107@siemens.com> (raw)
In-Reply-To: <20130304153754.GB16279@fermat.math.technion.ac.il>
On 2013-03-04 16:37, Nadav Har'El wrote:
> On Sun, Mar 03, 2013, Jan Kiszka wrote about "[PATCH] KVM: nVMX: Fix content of MSR_IA32_VMX_ENTRY/EXIT_CTLS":
>> /* Note that guest use of VM_EXIT_ACK_INTR_ON_EXIT is not supported. */
>> #ifdef CONFIG_X86_64
>> nested_vmx_exit_ctls_high = VM_EXIT_HOST_ADDR_SPACE_SIZE;
>> #else
>> nested_vmx_exit_ctls_high = 0;
>> #endif
>> + nested_vmx_exit_ctls_high |= 0x36dff;
>
> Can you please compose this 0x36dff out of constants? Is
> VM_EXIT_HOST_ADDR_SPACE_SIZE one of them?
Nope. These are bits enumerated by the spec to be always 1 unless that
bit 55 is 1 - what happens to them then remains unclear to me, but is
not important right now. I'm about to stick them all into a constant.
>
> It's important to verify that we actually support all these bits - even
> if we *should* support them, it doesn't mean we actually do (but if we
> do, we should say we do).
No, we just implement what the spec demands here. Leaving any of them 0
would make our implementation non-conforming, not just "special" as it
is right now.
>
>> - nested_vmx_entry_ctls_low = 0;
>> + /* If bit 55 of VMX_BASIC is off, bits 0-8 and 12 must be 1. */
>> + nested_vmx_entry_ctls_low = 0x11ff;
>
> Setting nested_vmx_entry_ctls_low = 0 just means that although the spec
> says only 1 setting is supported, we *also* support 0 setting. I'm not
> sure why this is a bad thing. Our VMX will be even better than the
> real processors' ;-)
Bad idea. We first need to make it correct, then we can think about
optimizations. This is very important if you want to support hypervisors
for which you have no code, just the knowledge that they work on real hw.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
prev parent reply other threads:[~2013-03-04 15:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-03 12:04 [PATCH] KVM: nVMX: Fix content of MSR_IA32_VMX_ENTRY/EXIT_CTLS Jan Kiszka
2013-03-04 13:24 ` Paolo Bonzini
2013-03-04 14:42 ` Jan Kiszka
2013-03-04 15:37 ` Nadav Har'El
2013-03-04 15:52 ` Jan Kiszka [this message]
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=5134C32E.3030107@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=gleb@redhat.com \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=nyh@math.technion.ac.il \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox