vmx_read_tsc_offset has a bug when running nested VMs. It should really be:
if (is_guest_mode(vcpu))
return to_vmx(vcpu)->nested.vmcs01_tsc_offset;
else
return vmcs_read64(TSC_OFFSET);
Perhaps a better name woulf be "vmx_get_l1_tsc_offset."
In any cas
7;t work with L2 (or
deeper) guests. Or perhaps I'm missing something?
On Mon, Sep 19, 2016 at 8:34 AM, Paolo Bonzini wrote:
>
>
> On 19/09/2016 17:30, Jim Mattson wrote:
>> vmx_read_tsc_offset has a bug when running nested VMs. It should really be:
>>
>>i
Doesn't that assume you can run the merge program in L1?
On Mon, Sep 19, 2016 at 10:37 PM, Paolo Bonzini wrote:
>
>
> On 20/09/2016 00:18, Jim Mattson wrote:
>> Hmmm. Yes, I think it does. With this patch series,
>> vcpu->arch.tsc_offset appears to contain L1's
wrote:
>
>
> On 21/09/2016 17:19, Jim Mattson wrote:
>> Doesn't that assume you can run the merge program in L1?
>
> You only need the TSC offset, but we should make sure that L0
> tracepoints contain enough information to figure out the L0->L2 TSC
> offsets (they
Does it still make sense to advertise "Enable VM Functions" in the
secondary processor-based VM-execution controls if we don't actually
support any VM Functions?
On Sat, Oct 14, 2017 at 7:31 PM, Wanpeng Li wrote:
> From: Wanpeng Li
>
> EPT switching is advertised unconditionally since it is emul
According to the SDM,
The IA32_VMX_EPT_VPID_CAP MSR exists only on processors that support
the 1-setting of the “activate secondary
controls” VM-execution control (only if bit 63 of the
IA32_VMX_PROCBASED_CTLS MSR is 1) and that support
either the 1-setting of the “enable EPT” VM-execution control
Following the same line of reasoning, what if
vmx->nested.nested_vmx_secondary_ctls_high is 0 after clearing
SECONDARY_EXEC_ENABLE_VMFUNC? Does it make sense to report
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS if we don't actually support any
of the secondary controls?
Reviewed-by: Jim Matt
ility.vpid
> is 0 and it is not read from MSR due to EPT is not exposed.
>
> The VPID can be used to tag linear mappings when EPT is not enabled. However,
> current logic just detects VPID capability if EPT is enabled, this patch
> fixes it.
>
> Cc: Paolo Bonzini
> Cc:
ini wrote:
> On 17/10/2017 19:29, Jim Mattson wrote:
>> Following the same line of reasoning, what if
>> vmx->nested.nested_vmx_secondary_ctls_high is 0 after clearing
>> SECONDARY_EXEC_ENABLE_VMFUNC? Does it make sense to report
>> CPU_BASED_ACTIVATE_SECONDARY_CONTROLS if
You're right, of course. My only remaining concern is that no real
hardware constrains these MSRs to three values as kvm does. On Intel
P6, only two values are allowed. On AMD CPUs, any value is allowed.
On Thu, Nov 2, 2017 at 10:35 AM, Paolo Bonzini wrote:
> On 19/10/2017 20:09, Jim
That seems reasonable to me. Thanks for the fix.
Reviewed-by: Jim Mattson
On Thu, Nov 2, 2017 at 5:50 PM, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Commit 4f350c6dbcb (kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure
> properly) can result in L1(run kvm-unit-tests/
ust be 0.
> - The linear address in bits 63:12 must be canonical.
>
> Reviewed-by: Konrad Rzeszutek Wilk
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Jim Mattson
> Signed-off-by: Wanpeng Li
> ---
> v3 -> v4:
> * simply condition
> * use && instead o
e performed on the field for the IA32_BNDCFGS MSR:
>>>>- Bits reserved in the IA32_BNDCFGS MSR must be 0.
>>>>- The linear address in bits 63:12 must be canonical.
>>>>
>>>> Reviewed-by: Konrad Rzeszutek Wilk
>>>> Cc: Paolo Bonzini
Reviewed-by: Jim Mattson
On Mon, Nov 6, 2017 at 9:44 AM, Janakarajan Natarajan
wrote:
> The function for CPUID 8001 ECX is set to 0xc001. Set it to
> 0x8001.
>
> Signed-off-by: Janakarajan Natarajan
> ---
> arch/x86/kvm/cpuid.h | 2 +-
> 1 file changed, 1 ins
r mappings when EPT is not enabled. However,
> current logic just detects VPID capability if EPT is enabled, this patch
> fixes it.
>
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Jim Mattson
> Signed-off-by: Wanpeng Li
> ---
> v2 -> v3:
> * add pr_warn_once
> v1
e guest attempts to write 1 to these
> registers should cause a #GP, this patch does it.
>
> Cc: Radim Krčmář
> Cc: Jim Mattson
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/x86.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/a
n 10/19/17 12:28 AM, Jim Mattson wrote:
>> The AMD APM says, "For each error-reporting register bank, software
>> should set the enable bits to 1 in the MCi_CTL register for the error
>> types it wants the processor to report. Software can write each
>> MCi_CTL with al
MCi_STATUS sounds fine, or any other Intel constraints that are
guarded by checks for virtualizing an Intel CPU.
On Wed, Oct 18, 2017 at 8:04 PM, Wanpeng Li wrote:
> On 10/19/17 10:49 AM, Jim Mattson wrote:
>
> Right. I was side-tracked by the code above yours for MCi_CTL.
> H
ave/restore to
work.
Reviewed-by: Jim Mattson
On Thu, Oct 19, 2017 at 6:47 AM, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Both Intel SDM and AMD APM mentioned that MCi_STATUS, when the register is
> implemented, this register can be cleared by explicitly writing 0s to this
> register
Model/DisplayFamily check is still required.
For all of the details, see the Intel white paper, "Retpoline: A
Branch Target Injection Mitigation" (document number 337131-001),
section 5.3: Virtual Machine CPU Identification.
Signed-off-by: Jim Mattson
Reviewed-by: Peter Shier
---
arch/x86/include/
gt;>
>> Signed-off-by: Vitaly Kuznetsov
> Reviewed-by: Paolo Bonzini
Reviewed-by: Jim Mattson
On a physical machine, I would expect the default local APIC page to
fall in the PCI hole, so it would be correct to sink writes and to
return all ones for reads. Does qemu implement a PCI hole, and does
this address fall into it?
On Fri, Jul 27, 2018 at 7:44 AM, Vitaly Kuznetsov wrote:
> When VM
On Fri, Jul 27, 2018 at 1:46 PM, Andy Lutomirski wrote:
>> On Jul 27, 2018, at 1:28 PM, Jim Mattson wrote:
>> Initializing this bit to zero helps with migration, but then if the
>> CPUID faulting bits in both MSRs are set, userspace has to take pains
>> to ensure t
On Sat, Jul 28, 2018 at 4:10 PM, Paolo Bonzini wrote:
> The shadow vmcs12 cannot be flushed on KVM_GET_NESTED_STATE,
> because at that point guest memory is assumed by userspace to
> be immutable. Capture the cache in vmx_get_nested_state, adding
> another page at the end if there is an active sh
M. To avoid this, delay the handling of the pages
> until just before the next vmentry. This is done with a new request
> and a new entry in kvm_x86_ops, which we will be able to reuse for
> nested VMX state migration.
>
> Extracted from a patch by Jim Mattson and KarimAllah Ahme
This looks similar to my "[PATCH] kvm: nVMX: Restore exit qual for
VM-entry failure due to MSR loading"
On Thu, Jul 12, 2018 at 4:35 AM, Vitaly Kuznetsov wrote:
> Commit e79f245ddec1 ("X86/KVM: Properly update 'tsc_offset' to represent
> the running guest") introduced a regression in enter_vmx_no
On Wed, Jan 10, 2018 at 8:27 AM, Paolo Bonzini wrote:
> I can answer (2) only.
>
> On 10/01/2018 17:19, Liran Alon wrote:
>> (2) On VMExit, Intel recommends to always save guest SPEC_CTRL value,
>> set IBRS to 1 (even if it is already set by guest) and stuff RSB. What
>> exactly does this write of
On Wed, Jan 10, 2018 at 9:23 AM, Nadav Amit wrote:
> Paolo Bonzini wrote:
>
>> On 10/01/2018 18:14, Jim Mattson wrote:
>>>>> If (a) is true, does "IBRS ALL THE TIME" usage is basically a CPU
>>>>> change to just create all BTB/BHB entries to be ta
The point behind the IPBP in vmx_vcpu_load is to prevent one VCPU from
steering the speculative execution of the next. If the VMCS address is
recycled, vmx_vcpu_load doesn't realize that the VCPUs are different,
and so it won't issue the IPBP.
On Thu, Jan 11, 2018 at 5:49 PM, Wanpeng Li wrote:
>
Nadav,
See section 2.5.1.2 (paragraph 3) in
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf.
On Tue, Jan 9, 2018 at 9:03 PM, Nadav Amit wrote:
> Paolo Bonzini wrote:
>
>> On 09/01/2018 17:48, Liran Alon wrote:
> + if (h
nless CPU[7,0].EDX[26] is 1.
>> Check that against host CPUID or guest CPUID, respectively for
>> host-initiated and guest-initiated accesses.
>>
>> Suggested-by: Jim Mattson
>> Signed-off-by: Paolo Bonzini
>> ---
>> This is for after X86_FEATURE_SPE
ID.(EAX=7H,ECX=0):EDX[27]? If the guest has write
access to MSR_IA32_SPEC_CTRL, it can set MSR_IA32_SPEC_CTRL[1]
(STIBP), even though setting that bit in the guest should raise #GP.
On Tue, Jan 30, 2018 at 8:43 AM, Mihai Carabas wrote:
> On 30.01.2018 18:33, Jim Mattson wrote:
>>
>&g
e_msr_bitmap.
>
> This prepares for choosing, on a per-VM basis, whether to intercept
> the SPEC_CTRL and PRED_CMD MSRs.
>
> Suggested-by: Jim Mattson
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/vmx.c | 267
> +
&g
On Mon, Jan 29, 2018 at 4:10 PM, KarimAllah Ahmed wrote:
> From: Ashok Raj
>
> Add MSR passthrough for MSR_IA32_PRED_CMD and place branch predictor
> barriers on switching between VMs to avoid inter VM Spectre-v2 attacks.
>
> [peterz: rebase and changelog rewrite]
> [karahmed: - rebase
>
On Tue, Jan 30, 2018 at 9:14 AM, David Woodhouse wrote:
> On Tue, 2018-01-30 at 08:57 -0800, Jim Mattson wrote:
>> It's really hard to tell which patches are being proposed for which
>> repositories, but assuming that everything else is correct, I don't
>> think y
On Mon, Jan 29, 2018 at 4:10 PM, KarimAllah Ahmed wrote:
> [ Based on a patch from Ashok Raj ]
>
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
> guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
> be using a retpoline+IBPB based approach.
>
> To a
On Tue, Jan 30, 2018 at 1:00 PM, KarimAllah Ahmed wrote:
> Ooops! I did not think at all about nested :)
>
> This should be addressed now, I hope:
>
> http://git.infradead.org/linux-retpoline.git/commitdiff/f7f0cbba3e0cffcee050a8a5a9597a162d57e572
+ if (cpu_has_vmx_msr_bitmap() && d
On Tue, Jan 30, 2018 at 3:50 PM, KarimAllah Ahmed wrote:
> Okay, I took a second look at the code (specially
> nested_vmx_merge_msr_bitmap).
>
> This means that I simply should not touch the MSR bitmap in set_msr in
> case of nested, I just need to properly update the l02 msr_bitmap in
> nested_vm
On Tue, Jan 30, 2018 at 4:19 PM, Paolo Bonzini wrote:
> The new code in nested_vmx_merge_msr_bitmap should be conditional on
> vmx->save_spec_ctrl_on_exit.
But then if L1 doesn't use MSR_IA32_SPEC_CTRL itself and it uses the
VM-entry MSR load list to set up L2's MSR_IA32_SPEC_CTRL, you will
never
On Wed, Jan 31, 2018 at 5:10 AM, KarimAllah Ahmed wrote:
> + vmx_disable_intercept_for_msr(vmx->vmcs01.msr_bitmap,
> MSR_IA32_PRED_CMD,
> + MSR_TYPE_W);
Why not disable this intercept eagerly, rather than lazily? Unlike
MSR_IA32_SPEC_CTR
On Wed, Jan 31, 2018 at 8:55 AM, Paolo Bonzini wrote:
> In fact this MSR can even be passed down unconditionally, since it needs
> no save/restore and has no ill performance effect on the sibling
> hyperthread.
I'm a bit surprised to hear that IBPB has no ill performance impact on
the sibling hy
On Wed, Jan 31, 2018 at 11:37 AM, KarimAllah Ahmed wrote:
> + nested_vmx_disable_intercept_for_msr(msr_bitmap_l1, msr_bitmap_l0,
> +MSR_IA32_PRED_CMD,
> +MSR_TYPE_W);
> +
I still think this should be pr
On Wed, Jan 31, 2018 at 11:37 AM, KarimAllah Ahmed wrote:
> +
> + if (to_vmx(vcpu)->save_spec_ctrl_on_exit) {
> + nested_vmx_disable_intercept_for_msr(
> + msr_bitmap_l1, msr_bitmap_l0,
> + MSR_IA32_SPEC_CTRL,
> +
On Wed, Jan 31, 2018 at 11:53 AM, David Woodhouse wrote:
> Rather than doing the expensive guest_cpu_has() every time (which is
> worse now as we realised we need two of them) perhaps we should
> introduce a local flag for that too?
That sounds good to me.
On Wed, Jan 31, 2018 at 12:01 PM, KarimAllah Ahmed wrote:
> but save_spec_ctrl_on_exit is also set for L2 write. So once L2 writes
> to it, this condition will be true and then the bitmap will be updated.
So if L1 or any L2 writes to the MSR, then save_spec_ctrl_on_exit is
set to true, even if t
You seem to be making the assumption that there is one L2. What if
there are 100 L2s, and only one has write-access to IA32_SPEC_CTRL? Or
what if there once was such an L2, but it's been gone for months? The
current mechanism penalizes *all* L2s if any L2, ever, has
write-access to IA32_SPEC_CTRL.
On Wed, Jan 31, 2018 at 1:00 PM, Paolo Bonzini wrote:
> Yes, but how would moving the field into struct loaded_vmcs do anything?
> Only vmon/vmoff would change anything in vmx->nested.vmcs02.
My suggestion was that nested_vmx_merge_msr_bitmap should set the
vmcs02 version of save_spec_ctrl_on_e
On Wed, Jan 31, 2018 at 12:21 PM, David Woodhouse wrote:
> Reading and writing this MSR is expensive. And if it's yielded to the
> guest in the MSR bitmap, that means we have to save its value on vmexit
> and set it back to zero.
Agreed. But my point is that if it's not yielded to the guest in t
On Wed, Jan 31, 2018 at 1:42 PM, Paolo Bonzini wrote:
> Can we just say it sucks to be L2 too? :) Because in the end as long as
> no one ever writes to spec_ctrl, everybody is happy.
Unfortunately, quite a few OS vendors shipped IBRS-based mitigations
earlier this month. (Has Redhat stopped wri
On Wed, Jan 31, 2018 at 1:59 PM, David Woodhouse wrote:
> I'm actually working on IBRS_ALL at the moment.
>
> I was tempted to *not* let the guests turn it off. Expose SPEC_CTRL but
> just make it a no-op.
Maybe we could convince Intel to add a LOCK bit to IA32_SPEC_CTRL like
the one in IA32_FEAT
On Sat, Jan 20, 2018 at 11:22 AM, KarimAllah Ahmed wrote:
> From: Ashok Raj
>
> Add MSR passthrough for MSR_IA32_PRED_CMD and place branch predictor
> barriers on switching between VMs to avoid inter VM specte-v2 attacks.
>
> [peterz: rebase and changelog rewrite]
> [dwmw2: fixes]
> [karahmed: -
Oh, but to do that properly, you need one of the per-vCPU bitmap
implementations that Paolo and I have independently posted.
On Mon, Jan 22, 2018 at 10:56 AM, Jim Mattson wrote:
> On Sat, Jan 20, 2018 at 11:22 AM, KarimAllah Ahmed wrote:
>> From: Ashok Raj
>>
>> Ad
On Sun, Jan 28, 2018 at 11:29 AM, KarimAllah Ahmed wrote:
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for guests
> that will only mitigate Spectre V2 through IBRS+IBPB and will not be using a
> retpoline+IBPB based approach.
>
> To avoid the overhead of atomically saving a
Why should this MSR be pass-through? I doubt that it would be accessed
frequently.
On Sun, Jan 28, 2018 at 4:58 PM, KarimAllah Ahmed wrote:
> Add direct access to MSR_IA32_SPEC_CTRL for guests. Future intel processors
> will use this MSR to indicate RDCL_NO (bit 0) and IBRS_ALL (bit 1).
>
> Cc: A
On Sun, Jan 28, 2018 at 4:58 PM, KarimAllah Ahmed wrote:
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: H. Peter Anvin
> Cc: x...@kernel.org
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed
> ---
> arch/x86
On Sun, Jan 28, 2018 at 4:58 PM, KarimAllah Ahmed wrote:
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
> guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
> be using a retpoline+IBPB based approach.
>
> To avoid the overhead of atomically saving an
gt; I forgot to fix up the wrong-MSR typo though, and we do still need to address
> reset.
>
> On Mon, 2018-01-29 at 10:43 -0800, Jim Mattson wrote:
>> On Sun, Jan 28, 2018 at 11:29 AM, KarimAllah Ahmed wrote:
>> >
>> > Add direct access to MSR_IA32_SPEC_CTRL for
On Sun, Jan 28, 2018 at 4:58 PM, KarimAllah Ahmed wrote:
> From: Ashok Raj
>
> Add MSR passthrough for MSR_IA32_PRED_CMD and place branch predictor
> barriers on switching between VMs to avoid inter VM Spectre-v2 attacks.
>
> [peterz: rebase and changelog rewrite]
> [karahmed: - rebase
>
On Mon, Jan 29, 2018 at 11:16 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jan 29, 2018 at 10:43:22AM -0800, Jim Mattson wrote:
>> On Sun, Jan 28, 2018 at 11:29 AM, KarimAllah Ahmed
>> wrote:
>> > Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
&g
For GCE, "you might be migrated to Skylake" is pretty much a
certainty. Even if you're in a zone that doesn't currently have
Skylake machines, chances are pretty good that it will have Skylake
machines some day in the not-too-distant future.
In general, making these kinds of decisions based on F/M
On Mon, Jan 29, 2018 at 1:50 PM, Eduardo Habkost wrote:
> On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote:
>> For GCE, "you might be migrated to Skylake" is pretty much a
>> certainty. Even if you're in a zone that doesn't currently have
>>
And if we expect to introduce Cascade Lake into the pool in the
future, we use a Cascade Lake model number?
It sounds like you are suggesting that we set the model number to the
highest model number that will ever be introduced into the pool, at
any time in the future. That approach would also fai
On Mon, Jan 29, 2018 at 1:49 PM, Daniel Kiper wrote:
> On Mon, Jan 29, 2018 at 12:31:13PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 29, 2018 at 08:46:03AM +, David Woodhouse wrote:
>> > On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote:
>> > >
>> > > Windows use IBRS and Microsoft d
The guest OS is responsible for protecting itself from intra-guest
attacks. The hypervisor can't do that. We want to give the guest OS
the tools it needs to make reasonable decisions about the intra-guest
protections it wants to enable, in an environment where the virtual
processor and the physical
I don't really understand the organization of this file, but I put
these MSRs in the /* Intel defined MSRs. */ block, between
MSR_IA32_TSC_ADJUST and MSR_IA32_BNDCFGS.
On Mon, Jan 8, 2018 at 10:35 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jan 08, 2018 at 07:08:40PM +0100, Paolo Bonzini wrote:
>>
Guest usage of MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD should be
predicated on guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL).
On Mon, Jan 8, 2018 at 10:08 AM, Paolo Bonzini wrote:
> Direct access to MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD is important
> for performance. Allow load/store of MSR_
Shouldn't there be an IBPB on *any* context switch away from a VCPU
thread, even if it is to a non-VCPU thread?
On Mon, Jan 8, 2018 at 10:08 AM, Paolo Bonzini wrote:
> From: Tim Chen
>
> Ensure an IBPB (Indirect branch prediction barrier) before every VCPU
> switch.
>
> Signed-off-by: Tim Chen
Reviewed-by: Jim Mattson
On Mon, Jan 8, 2018 at 12:07 PM, Liran Alon wrote:
>
>
> On 08/01/18 20:08, Paolo Bonzini wrote:
>>
>> Expose them to userspace, now that guests can use them.
>> I am not adding cpufeatures here to avoid having a kernel
>> that sho
I would like to campaign for removing all of the precomputed MSR
permission bitmaps, and using a separate bitmap for each vCPU, a la
svm.c.
On Fri, Jan 5, 2018 at 7:43 AM, Paolo Bonzini wrote:
> KVM has a small optimization where it doesn't save/restore
> MSR_KERNEL_GS_BASE if the guest is in 32-
On Mon, Jan 8, 2018 at 2:32 PM, Paolo Bonzini wrote:
>
>> I have:
>>
>> if (!have_spec_ctrl ||
>> (!msr_info->host_initiated &&
>> !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL)))
>> return 1;
>> msr_info->data = to_vmx(vcpu)->msr_ia32_spec_ctrl;
>> break;
>
>> I have:
>>
>> if (!have_spec
I'm going to try to get per-vCPU MSR bitmaps out today or tomorrow.
On Tue, Jan 9, 2018 at 8:11 AM, Paolo Bonzini wrote:
> On 09/01/2018 16:58, Liran Alon wrote:
>>
>> The only thing I a bit dislike is that currently these MSRs are always
>> pass-through to guest and therefore
>> there is no cas
Before VM-entry, don't we need to flush the BHB and the RSB to avoid
revealing KASLR information to the guest? (Thanks to Liran for
pointing this out.)
On Tue, Jan 9, 2018 at 12:47 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 09, 2018 at 03:39:09PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue,
If my documentation is up-to-date, writing IBRS does not clear the RSB
(except for parts which contain an RSB that is not filled by 32
CALLs).
On Tue, Jan 9, 2018 at 1:11 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 09, 2018 at 12:57:38PM -0800, Jim Mattson wrote:
>> Before VM-entry,
(unless one of IBRS
or IBPB flushes the BHB).
On Tue, Jan 9, 2018 at 1:42 PM, Paolo Bonzini wrote:
> On 09/01/2018 21:57, Jim Mattson wrote:
>> Before VM-entry, don't we need to flush the BHB and the RSB to avoid
>> revealing KASLR information to the guest? (Thanks to Liran for
On Mon, Apr 9, 2018 at 1:37 AM, KarimAllah Ahmed wrote:
> From: Jim Mattson
>
> For nested virtualization L0 KVM is managing a bit of state for L2 guests,
> this state can not be captured through the currently available IOCTLs. In
> fact the state captured through all of these IO
On Mon, Apr 9, 2018 at 1:37 AM, KarimAllah Ahmed wrote:
> + /*
> +* Force a nested exit that guarantees that any state capture
> +* afterwards by any IOCTLs (MSRs, etc) will not capture a mix of L1
> +* and L2 state.
> +*
> +* One example where that w
Is there a need for a new API for yielding MONITOR/MWAIT to the guest?
Why not just tie this to the guest CPUID.01H:ECX[MWAIT] being set?
On Mon, Mar 12, 2018 at 4:53 AM, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Allowing a guest to execute MWAIT without interception enables a guest
> to put a (p
kvm_cpuid_7_0_edx_x86_features.
>
> Signed-off-by: Eduardo Habkost
Reviewed-by: Jim Mattson
On Wed, Dec 5, 2018 at 2:02 PM Konrad Rzeszutek Wilk
wrote:
>
> On Wed, Dec 05, 2018 at 05:19:56PM -0200, Eduardo Habkost wrote:
> > Months ago, we have added code to allow direct access to MSR_IA32_SPEC_CTRL
> > to the guest, which makes STIBP available to guests. This was implemented
> > by com
On Mon, Dec 3, 2018 at 1:31 AM KarimAllah Ahmed wrote:
>
> Copy the VMCS12 directly from guest memory instead of the map->copy->unmap
> sequence. This also avoids using kvm_vcpu_gpa_to_page() and kmap() which
> assumes that there is a "struct page" for guest memory.
>
> Signed-off-by: KarimAllah A
I'm not convinced that the "one size fits all" and "context-free"
approaches to VMCS shadowing are terribly effective.
For example, we never shadow VMX_INSTRUCTION_INFO, but if we just
reflected an exit to L1 for which that field is defined, there's
probably a good chance that L1 will use it. We a
22: 0f 01 c3 vmresume
25: 48 89 4c 24 08mov%rcx,0x8(%rsp)
2a: 59pop%rcx
:
2b: 0f 96 81 88 56 00 00 setbe 0x5688(%rcx)
32: 48 89 81 00 03 00 00 mov%rax,0x300(%rcx)
39: 48 89 99 18 03 00 00 mov%rbx,0x318(%rcx)
%rcx should be poin
On Mon, Aug 20, 2018 at 9:00 AM, Thomas Gleixner wrote:
>
> On Tue, 7 Aug 2018, Jim Mattson wrote:
>
> > Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
> > conditions. On hardware, platform vulnerability can be determined
> > simply by checking t
On Tue, Oct 16, 2018 at 9:50 AM Vitaly Kuznetsov wrote:
>
> Per Hyper-V TLFS 5.0b:
>
> "The L1 hypervisor may choose to use enlightened VMCSs by writing 1 to
> the corresponding field in the VP assist page (see section 7.8.7).
> Another field in the VP assist page controls the currently active
> e
On Mon, Jan 7, 2019 at 1:09 AM Wei Wang wrote:
>
> On 01/03/2019 11:25 PM, Jim Mattson wrote:
> > On Wed, Jan 2, 2019 at 11:55 PM Wei Wang wrote:
> >
> >> Right, thanks. Probably better to change it to below:
> >>
> >> msr_info->data = 0;
> &
On Mon, Jan 7, 2019 at 10:20 AM Andi Kleen wrote:
>
> > The issue is compatibility. Prior to your change, reading this MSR
> > from a VM would raise #GP. After your change, it won't. That means
> > that if you have a VM migrating between hosts with kernel versions
> > before and after this change,
On Mon, Jan 7, 2019 at 12:14 PM Andi Kleen wrote:
>
> On Mon, Jan 07, 2019 at 10:48:38AM -0800, Jim Mattson wrote:
> > On Mon, Jan 7, 2019 at 10:20 AM Andi Kleen wrote:
> > >
> > > > The issue is compatibility. Prior to your change, reading this MSR
> > &g
On Wed, Dec 26, 2018 at 12:13 AM Yang Weijiang wrote:
>
> During Guest OS execution, it accesses these MSRs to
> configure CET runtime settings.
>
> Signed-off-by: Zhang Yi Z
> Signed-off-by: Yang Weijiang
> ---
> arch/x86/kvm/vmx.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
On Wed, Jan 2, 2019 at 10:24 AM Sean Christopherson
wrote:
>
> On Wed, Dec 26, 2018 at 04:15:29PM +0800, Yang Weijiang wrote:
> > For kvm Guest OS, right now, only bit 11(user mode CET) and bit 12
> > (supervisor CET) are supported in XSS MSR, if other bits are being set,
> > the write to XSS will
On Wed, Dec 26, 2018 at 2:01 AM Wei Wang wrote:
>
> The lbr stack is architecturally specific, for example, SKX has 32 lbr
> stack entries while HSW has 16 entries, so a HSW guest running on a SKX
> machine may not get accurate perf results. Currently, we forbid the
> guest lbr enabling when the g
On Wed, Dec 26, 2018 at 2:01 AM Wei Wang wrote:
>
> Bits [0, 5] of MSR_IA32_PERF_CAPABILITIES tell about the format of
> the addresses stored in the LBR stack. Expose those bits to the guest
> when the guest lbr feature is enabled.
>
> Signed-off-by: Wei Wang
> Cc: Paolo Bonzini
> Cc: Andi Kleen
On Wed, Jan 2, 2019 at 11:55 PM Wei Wang wrote:
> Right, thanks. Probably better to change it to below:
>
> msr_info->data = 0;
> data = native_read_msr(MSR_IA32_PERF_CAPABILITIES);
> if (vcpu->kvm->arch.lbr_in_guest)
> msr_info->data |= (data & X86_PERF_CAP_MASK_LBR_FMT);
>
This still brea
On Wed, Jan 2, 2019 at 11:16 PM Wei Wang wrote:
>
> On 01/03/2019 07:26 AM, Jim Mattson wrote:
> > On Wed, Dec 26, 2018 at 2:01 AM Wei Wang wrote:
> >> The lbr stack is architecturally specific, for example, SKX has 32 lbr
> >> stack entries while HSW has 16 entrie
On Fri, Jan 4, 2019 at 2:03 AM Wei Wang wrote:
>
> On 01/03/2019 11:34 PM, Jim Mattson wrote:
> > Fast forward to, say, 2021. You're decommissioning all Broadwell
> > servers in your data center. You have to migrate the running VMs off
> > of those Broadwell systems o
I believe that ESXi reads GUEST_CS_AR_BYTES on every VM-exit to
determine code size.
On Wed, Oct 17, 2018 at 10:02 AM, Paolo Bonzini wrote:
> On 17/10/2018 16:47, Vitaly Kuznetsov wrote:
+ if (!hv_evmcs || !(hv_evmcs->hv_clean_fields &
+ HV_VMX_ENLIGHTENED_CLEAN_F
On Wed, Oct 24, 2018 at 1:05 AM, Luwei Kang wrote:
> From: Chao Peng
>
> Intel Processor Trace virtualization can be work in one
> of 2 possible modes:
>
> a. System-Wide mode (default):
>When the host configures Intel PT to collect trace packets
>of the entire system, it can leave the re
(0), "D" (0)
> + : "cc"
> +#ifdef CONFIG_X86_64
> + , "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15"
> +#endif
> + );
> +
Looking at the second asm statement and the comment that precedes it,
my first question would be, "What about the registers not covered
here?" I'm also not convinced that the register-clearing asm statement
is actually "clearer" with some registers cleared as input arguments
and others cleared explicitly, but otherwise, the change looks fine to
me.
Reviewed-by: Jim Mattson
; Signed-off-by: Julian Stecklina
> Reviewed-by: Jan H. Schönherr
> Reviewed-by: Konrad Jan Miller
Reviewed-by: Jim Mattson
On Fri, Oct 26, 2018 at 8:46 AM, Sean Christopherson
wrote:
> Since clearing the GPRs exists to mitigate speculation junk, I think
> we should keep the explicit XOR zeroing instead of deferring to the
> compiler. Explicit XORs will ensure the resulting assembly is the
> same regardless of compil
; Cc: H. Peter Anvin
> Cc: x...@kernel.org
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Fixes: 6de84e581c0 ("nVMX x86: check posted-interrupt descriptor addresss on
> vmentry of L2")
> Signed-off-by: KarimAllah Ahmed
Reviewed-by: Jim Mattson
1 - 100 of 448 matches
Mail list logo
