On 23/09/20 18:50, Sean Christopherson wrote:
> Add a helper function and several wrapping macros to consolidate the
> copy-paste code in vmx_compute_secondary_exec_control() for adjusting
> controls that are dependent on guest CPUID bits.
>
> No functional change intended.
>
> Signed-off-by: Sea
On 23/09/20 19:04, Sean Christopherson wrote:
>> Two of the three instances are a bit different though. What about this
>> which at least shortens the comment to 2 fewer lines:
> Any objection to changing those to "Flush (on non-coherent CPUs)"? I agree
> it would be helpful to call out the detai
On 23/09/20 18:36, Sean Christopherson wrote:
> +static inline bool pt_output_base_valid(struct kvm_vcpu *vcpu, u64 base)
> +{
> + /* The base must be 128-byte aligned and a legal physical address. */
> + return !(base & (~((1UL << cpuid_maxphyaddr(vcpu)) - 1) | 0x7f));
> +}
The fact that
On 23/09/20 18:33, Sean Christopherson wrote:
> Move initialization of 'struct kvm_mmu' fields into alloc_mmu_pages() to
> consolidate code, and rename the helper to __kvm_mmu_create().
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/kvm/mmu/mmu.c | 25
On 19/09/20 06:55, Sean Christopherson wrote:
> Side topic, while I love the comment (I do, honestly) regarding in-place
> encryption, this is the fourth? instance of the same 4-line comment (6 lines
> if you count the /* and */. Maybe it's time to do something like
>
> /* LAUNCH_SECRET doe
On 12/08/20 20:06, Sean Christopherson wrote:
> Add tracepoints for the early consistency checks in nested_vmx_run().
> The "VMLAUNCH vs. VMRESUME" check in particular is useful to trace, as
> there is no architectural way to check VMCS.LAUNCH_STATE, and subtle
> bugs such as VMCLEAR on the wrong H
On 23/09/20 16:32, Jim Mattson wrote:
> You don’t buy my argument that this should be per-VM, then? I’d bet that
> we have very close to 0 customers who care about emulating the reserved
> bits properly for 46-but wide VMs, but there may be someone out there
> using shadow paging in a nested kvm.
On 26/08/20 03:55, Yang Weijiang wrote:
> This is a follow-up patch to fix an issue left in commit:
> 98b0bf02738004829d7e26d6cb47b2e469aaba86
> selftests: kvm: Use a shorter encoding to clear RAX
>
> With the change in the commit, we also need to modify "xor" instruction
> length from 3 to 2 in a
On 03/09/20 16:11, Mohammed Gamal wrote:
> This patch exposes allow_smaller_maxphyaddr to the user as a module parameter.
>
> Since smaller physical address spaces are only supported on VMX, the parameter
> is only exposed in the kvm_intel module.
> Modifications to VMX page fault and EPT violatio
On 22/09/20 03:48, Sean Christopherson wrote:
> This should be genericized to not be SEV specific. TDX has a similar
> scarcity issue in the form of key IDs, which IIUC are analogous to SEV ASIDs
> (gave myself a quick crash course on SEV ASIDs). Functionally, I doubt it
> would change anything,
On 22/09/20 21:11, Babu Moger wrote:
>
>
>> -Original Message-----
>> From: Paolo Bonzini
>> Sent: Tuesday, September 22, 2020 8:39 AM
>> To: Sean Christopherson
>> Cc: Moger, Babu ; vkuzn...@redhat.com;
>> jmatt...@google.com; wanpen.
On 22/09/20 17:39, Maxim Levitsky wrote:
>>> I'll talk to Maxim and see if he can work on the kvmclock migration stuff.
>
> We talked about this on IRC and now I am also convinced that we should
> implement
> proper TSC migration instead, so I guess I'll drop this patch and I will
> implement it
On 17/09/20 21:23, Cathy Avery wrote:
>
> 2) There is a workaround in nested_svm_vmexit() where
>
>if (svm->vmcb01->control.asid == 0)
>svm->vmcb01->control.asid = svm->nested.vmcb02->control.asid;
>
>This was done as a result of the kvm selftest 'state_test'. In that
>test s
On 21/09/20 16:07, Cathy Avery wrote:
>>> - if (npt_enabled)
>>> - svm->vmcb->save.cr3 = hsave->save.cr3;
>>> + if (!npt_enabled)
>>> + svm->vmcb01->save.cr3 = kvm_read_cr3(&svm->vcpu);
>> Does this mean the original code is missing the following?
>>
>> else
>>
On 22/09/20 16:54, Haiwei Li wrote:
>> EXIT_FASTPATH_REENTER_GUEST handling up to vcpu_enter_guest)...
> Hi, Paolo
>
> I have sent a patch to do this,
>
> https://lore.kernel.org/kvm/20200915113033.61817-1-lihaiwei.ker...@gmail.com/
Cool, thanks. I think I'll just squash it in Wanpeng's if you
On 14/09/20 22:43, Krish Sadhukhan wrote:
>>
>
> Not related to your changes, but should we get rid of the variable
> 'exit_fastpath' and just do,
>
> return svm_exit_handler_fastpath(vcpu);
>
> It seems the variable isn't used anywhere else and svm_vcpu_run()
> doesn't return from anywh
On 14/09/20 17:06, Sean Christopherson wrote:
>> I think these should take a vector instead, and add 64 in the functions.
>
> And "s/int bit/u32 vector" + BUILD_BUG_ON(vector > 32)?
Not sure if we can assume it to be constant, but WARN_ON_ONCE is good
enough as far as performance is concerned. T
On 15/09/20 21:15, Sean Christopherson wrote:
> Clean up KVM's handling of IRQ and NMI exits to move the invocation of the
> IRQ handler to a standalone assembly routine, and to then consolidate the
> NMI handling to use the same indirect call approach instead of using INTn.
>
> The IRQ cleanup wa
On 16/09/20 19:34, Sean Christopherson wrote:
>
> The intent of posting the patch standalone is so that SGX, SEV-ES, and/or TDX
> have "ready to go" support in upstream, i.e. can change only the VMX/SVM
> implementation of is_emulated(). I'm a-ok dropping the handle_ud() change,
> or even the who
On 16/09/20 01:27, Sean Christopherson wrote:
> Replace the existing kvm_x86_ops.need_emulation_on_page_fault() with a
> more generic is_emulatable(), and unconditionally call the new function
> in x86_emulate_instruction().
>
> KVM will use the generic hook to support multiple security related
>
On 16/09/20 10:36, lihaiwei.ker...@gmail.com wrote:
> From: Haiwei Li
>
> Use __GFP_ZERO while alloc_page().
>
> Signed-off-by: Haiwei Li
> ---
> arch/x86/kvm/svm/avic.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/a
On 21/09/20 18:23, Sean Christopherson wrote:
> Avoid "should" in code comments and describe what the code is doing, not what
> it should be doing. The only exception for this is when the code has a known
> flaw/gap, e.g. "KVM should do X, but because of Y, KVM actually does Z".
>
>> +
On 19/09/20 02:09, Gustavo A. R. Silva wrote:
> Reviewed-by: Gustavo A. R. Silva
Queued, without stable. Thanks.
Paolo
On 22/09/20 07:23, yadong...@intel.com wrote:
> From: Yadong Qi
>
> Background: We have a lightweight HV, it needs INIT-VMExit and
> SIPI-VMExit to wake-up APs for guests since it do not monitor
> the Local APIC. But currently virtual wait-for-SIPI(WFS) state
> is not supported in nVMX, so when r
tation for KVM_CAP_S390_DIAG318
Marc Zyngier (2):
KVM: arm64: Assume write fault on S1PTW permission fault on instruction
fetch
KVM: arm64: Remove S1PTW check from kvm_vcpu_dabt_iswrite()
Paolo Bonzini (2):
Merge tag 'kvmarm-fixes-5.9-2' of git://git.kernel.org/.../kvmarm/kvmarm
into kv
On 20/09/20 18:16, Sean Christopherson wrote:
>> Maxim, your previous version was adding some error handling to
>> kvm_x86_ops.set_efer. I don't remember what was the issue; did you have
>> any problems propagating all the errors up to KVM_SET_SREGS (easy),
>> kvm_set_msr (harder) etc.?
> I object
On 14/09/20 11:11, lihaiwei.ker...@gmail.com wrote:
> From: Haiwei Li
>
> When CONFIG_SMP is not set, an build error occurs with message "error:
> use of undeclared identifier 'kvm_send_ipi_mask_allbutself'"
>
> Fixes: 0f990222108d ("KVM: Check the allocation of pv cpu mask", 2020-09-01)
> Repor
gt;>
>> for (i = 0; i < npages; i++) {
>> --
>
> Took the first two, Paolo lemme know if I should route this one through
> tip too.
>
> Thx.
>
Yeah, it's innocuous enough as far as conflicts are concerned.
Acked-by: Paolo Bonzini
Paolo
On 17/09/20 18:29, Sean Christopherson wrote:
>> +vcpu->arch.efer = old_efer;
>> +kvm_make_request(KVM_REQ_OUT_OF_MEMORY, vcpu);
> I really dislike KVM_REQ_OUT_OF_MEMORY. It's redundant with -ENOMEM and
> creates a huge discrepancy with respe
On 17/09/20 04:25, yadong...@intel.com wrote:
> From: Yadong Qi
>
> Background: We have a lightweight HV, it needs INIT-VMExit and
> SIPI-VMExit to wake-up APs for guests since it do not monitoring
> the Local APIC. But currently virtual wait-for-SIPI(WFS) state
> is not supported in KVM, so when
On 22/08/20 18:42, Andy Lutomirski wrote:
> On VMX, when a VM exits, the VM's
> value of MSR_TSC_AUX is live, and we can take an NMI, MCE, or
> abominable new #SX, #VE, #VC, etc on the next instruction boundary.
> And unless we use the atomic MSR switch mechanism, the result is that
> we're going t
SVM: nSVM: correctly restore GIF on vmexit from nesting after migration
SVM: nSVM: setup nested msr permission bitmap on nested state load
KVM: nSVM: more strict SMM checks when returning to nested guest
KVM: emulator: more strict rsm checks.
Paolo Bonzini (1):
Merge tag &#
On 11/09/20 21:27, Babu Moger wrote:
> The following series adds the support for PCID/INVPCID on AMD guests.
> While doing it re-structured the vmcb_control_area data structure to
> combine all the intercept vectors into one 32 bit array. Makes it easy
> for future additions. Re-arranged few pcid r
On 11/09/20 21:28, Babu Moger wrote:
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 1a5f3908b388..11892e86cb39 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -1003,11 +1003,11 @@ static void init_vmcb(struct vcpu_svm *svm)
>
> set_dr_interc
On 27/08/20 19:11, Maxim Levitsky wrote:
> + hsave_page = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_ZERO);
> + if (!hsave_page)
> + goto error;
> +
I think an error here should be just an internal error userspace exit,
or a -ENOMEM from KVM_RUN; not a #GP in the guest[1]. However,
On 27/08/20 18:27, Maxim Levitsky wrote:
> This patch series contains few nested SVM fixes from
> testing I did this weekend.
>
> Patch #1 fixes issue where we were setting the GIF (global interrupt flag)
> on first nested VMexit, after migration thus making the nested guest crash
> from unexpecte
On 27/08/20 18:27, Maxim Levitsky wrote:
> However in nested_svm_vmexit we were first were setting GIF to false,
> but then we overwrite this with value from the hsave area.
Do you mean we are overwriting the resulting intercepts with values from
the hsave area? If so, I can rewrite the commit me
On 11/09/20 23:21, Borislav Petkov wrote:
> On Fri, Sep 11, 2020 at 07:25:58PM +, Krish Sadhukhan wrote:
>
> <-- patches need commit message.
>
> ...
>
>> diff --git a/arch/x86/kernel/cpu/scattered.c
>> b/arch/x86/kernel/cpu/scattered.c
>> index 62b137c3c97a..033c112e03fc 100644
>> --- a/ar
On 10/09/20 11:50, Wanpeng Li wrote:
> Collect sporadic patches for easy apply.
>
> Wanpeng Li (9):
> KVM: LAPIC: Return 0 when getting the tscdeadline timer if the lapic
> is hw disabled
> KVM: LAPIC: Guarantee the timer is in tsc-deadline mode when setting
> KVM: LAPIC: Fix updating DF
On 10/09/20 11:50, Wanpeng Li wrote:
> From: Wanpeng Li
>
> The kick after setting KVM_REQ_PENDING_TIMER is used to handle the timer
> fires on a different pCPU which vCPU is running on, this kick is expensive
> since memory barrier, rcu, preemption disable/enable operations. We don't
> need this
On 09/09/20 10:41, Wanpeng Li wrote:
> Any Reviewed-by for these two patches? :)
> On Wed, 19 Aug 2020 at 16:55, Wanpeng Li wrote:
>>
>> From: Wanpeng Li
>>
>> There is missing apic map recalculation after updating DFR, if it is
>> INIT RESET, in x2apic mode, local apic is software enabled before
On 09/09/20 10:47, Wanpeng Li wrote:
>> One more thing:
>>
>> VMX version does
>>
>> vmx_complete_interrupts(vmx);
>> if (is_guest_mode(vcpu))
>> return EXIT_FASTPATH_NONE;
>>
>> and on SVM we analyze is_guest_mode() inside
>> svm_exit_handlers_fastpath() - should we
The overall patch is fairly simple:
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 03dd7bac8034..d6ce75e107c0 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -2938,8 +2938,6 @@ static int handle_exit(struct kvm_vcpu *vcpu,
fastpath_t exit_fastpath)
i
On 11/09/20 18:04, Sean Christopherson wrote:
> This doesn't actually verify that @data == 0. kvm_pv_async_pf_enabled()
> returns true iff KVM_ASYNC_PF_ENABLED and KVM_ASYNC_PF_DELIVERY_AS_INT are
> set, e.g. this would allow setting one and not the other. This also allows
> userspace to set vcp
On 11/09/20 11:31, Vitaly Kuznetsov wrote:
> Even without in-kernel LAPIC we should allow writing '0' to
> MSR_KVM_ASYNC_PF_EN as we're not enabling the mechanism. In
> particular, QEMU with 'kernel-irqchip=off' fails to start
> a guest with
>
> qemu-system-x86_64: error: failed to set MSR 0x4b564
On 25/08/20 21:56, David Rientjes wrote:
> There may be many encrypted regions that need to be unregistered when a
> SEV VM is destroyed. This can lead to soft lockups. For example, on a
> host running 4.15:
>
> watchdog: BUG: soft lockup - CPU#206 stuck for 11s! [t_virtual_machi:194348]
> CPU:
On 11/09/20 07:56, Yi Li wrote:
> There is no need to calculate wildcard in each loop
> since wildcard is not changed.
>
> Signed-off-by: Yi Li
> ---
> virt/kvm/eventfd.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> index
On 02/09/20 15:54, Lai Jiangshan wrote:
> From: Lai Jiangshan
>
> When kvm_mmu_get_page() gets a page with unsynced children, the spt
> pagetable is unsynchronized with the guest pagetable. But the
> guest might not issue a "flush" operation on it when the pagetable
> entry is changed from zero o
On 28/08/20 10:56, Chenyi Qiang wrote:
> The first three patches fix a issue for the nested VMX controls MSRs. The
> issue happens when I use QEMU to run nested VM. The VM_{ENTRY,
> EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL and VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS
> in L1 MSR_IA32_VMX_TRUE_{ENTRY, EXIT}_CTLS
On 02/09/20 20:32, Jim Mattson wrote:
>
> /* If not VM_EXIT_CLEAR_BNDCFGS, the L2 value propagates to L1. */
> if (vmcs12->vm_exit_controls & VM_EXIT_CLEAR_BNDCFGS)
> vmcs_write64(GUEST_BNDCFGS, 0);
>
> BTW, where does the L2 value propagate to L1 if not VM_EXIT_CLEAR_BNDCFGS?
Hmm, nowh
On 01/09/20 13:41, Haiwei Li wrote:
> From: Haiwei Li
>
> check the allocation of per-cpu __pv_cpu_mask. Initialize ops only when
> successful.
>
> Signed-off-by: Haiwei Li
> ---
> arch/x86/kernel/kvm.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff
On 07/09/20 20:55, Rustam Kovhaev wrote:
> when kmalloc() fails in kvm_io_bus_unregister_dev(), before removing
> the bus, we should iterate over all other devices linked to it and call
> kvm_iodevice_destructor() for them
>
> Fixes: 90db10434b16 ("KVM: kvm_io_bus_unregister_dev() should never fai
I_SCAN_INITIAL);
> + } else {
> + scsi_add_device(shost, 0, target, lun);
> + }
> break;
> case VIRTIO_SCSI_EVT_RESET_REMOVED:
> sdev = scsi_device_lookup(shost, 0, target, lun);
>
Acked-by: Paolo Bonzini
On 03/09/20 20:32, Jim Mattson wrote:
>> [Checking writes to CR3] would be way too slow. Even the current
>> trapping of present #PF can introduce some slowdown depending on the
>> workload.
>
> Yes, I was concerned about that...which is why I would not want to
> enable pedantic mode. But if you'r
On 03/09/20 19:57, Jim Mattson wrote:
> On Thu, Sep 3, 2020 at 7:12 AM Mohammed Gamal wrote:
>> This patch exposes allow_smaller_maxphyaddr to the user as a module
>> parameter.
>>
>> Since smaller physical address spaces are only supported on VMX, the
>> parameter
>> is only exposed in the kvm_
On 27/08/20 22:40, Sean Christopherson wrote:
> Paolo pushed an alternative solution for 5.8, commit 5e105c88ab485 ("KVM:
> nVMX: check for invalid hdr.vmx.flags"). His argument was that there was
> no point in adding proper padding since we already broke the ABI, i.e.
> damage done.
>
> So rathe
On 27/08/20 22:40, Sean Christopherson wrote:
> Paolo pushed an alternative solution for 5.8, commit 5e105c88ab485 ("KVM:
> nVMX: check for invalid hdr.vmx.flags"). His argument was that there was
> no point in adding proper padding since we already broke the ABI, i.e.
> damage done.
>
> So rathe
tils
* MMU notifier fix for arm64
Jim Mattson (2):
kvm: x86: Toggling CR4.SMAP does not load PDPTEs in PAE mode
kvm: x86: Toggling CR4.PKE does not load PDPTEs in PAE mode
Paolo Bonzini (1):
KVM: x86: fix access code
fore the patch can just remove the RDPID alternative.
Fixes: eaad981291ee3 ("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")
Cc: Dave Hansen
Cc: Chang Seok Bae
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: Paolo Bonzini
Cc: k...@vger.kernel.org
Reported-by: Tom Lendacky
Debugged-by: Tom Len
On 21/08/20 11:48, Borislav Petkov wrote:
>> It's not like we grab MSRs every day. The user-return notifier restores
>> 6 MSRs (7 on very old processors). The last two that were added were
>> MSR_TSC_AUX itself in 2009 (!) and MSR_IA32_TSX_CTRL last year.
> What about "If it is a shared resource,
On 21/08/20 11:22, Borislav Petkov wrote:
>> Hence the assumption that KVM makes (and has made ever since TSC_AUX was
>> introduced.
> And *this* is the problem. KVM can't just be grabbing MSRs and claiming
> them because it started using them first. You guys need to stop this. If
> it is a shared
On 21/08/20 11:28, Thomas Gleixner wrote:
> We all know that MSRs are slow, but as a general rule I have to make it
> entirely clear that the kernel has precedence over KVM.
I totally agree. I just don't think that it matters _in this case_,
because the kernel hardly has any reason to use TSC_AUX
On 21/08/20 10:16, Borislav Petkov wrote:
> On Fri, Aug 21, 2020 at 10:09:01AM +0200, Paolo Bonzini wrote:
>> One more MSR *is* a big deal: KVM's vmentry+vmexit cost is around 1000
>> cycles, adding 100 clock cycles for 2 WRMSRs is a 10% increase.
>
> The kernel uses T
On 21/08/20 09:47, Borislav Petkov wrote:
> On Thu, Aug 20, 2020 at 07:50:50PM -0700, Sean Christopherson wrote:
>> + * Disallow RDPID if KVM is enabled as it may consume a guest's TSC_AUX
>> + * if an NMI arrives in KVM's run loop. KVM loads guest's TSC_AUX on
>> + * VM-Enter and may
On 20/08/20 18:30, Tom Lendacky wrote:
>>> running the x86 sefltests on a bad kernel without running any guests?
>>
>> I'll give that a try.
>
> All the selftests passed.
Do the KVM selftests also pass? Especially the dirty_log_test might be
interesting since it can be run for a longer time.
Pa
On 19/08/20 23:25, Andy Lutomirski wrote:
> wrmsrl(MSR_KERNEL_GS_BASE, current->thread.gsbase);
> load_gs_index(svm->host.gs);
>
> Surely that should do load_gs_index() *before* wrmsrl(). But that's
> not the problem at hand.
The wrmsrl is writing the inactive GS base so the orde
On 20/08/20 11:13, Maxim Levitsky wrote:
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 06668e0f93e7..f0bb7f622dca 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -3924,7 +3924,7 @@ static int svm_pre_leave_smm(struct kvm_vcpu *vcpu,
> const char *
On 20/08/20 11:13, Maxim Levitsky wrote:
> No functional changes.
>
> Signed-off-by: Maxim Levitsky
> ---
> arch/x86/kvm/svm/nested.c | 10 +-
> arch/x86/kvm/svm/svm.c| 13 +++--
> arch/x86/kvm/svm/svm.h| 2 +-
> 3 files changed, 13 insertions(+), 12 deletions(-)
>
> di
On 20/08/20 11:13, Maxim Levitsky wrote:
> @@ -3912,6 +3914,14 @@ static int svm_pre_leave_smm(struct kvm_vcpu *vcpu,
> const char *smstate)
> vmcb_gpa = GET_SMSTATE(u64, smstate, 0x7ee0);
>
> if (guest) {
> + /*
> + * This can happen if SVM was not enabled p
On 20/08/20 12:23, Maxim Levitsky wrote:
> I fully agree that adding local variable is a good idea anyway.
>
> I was just noting that svm->nested.vmcb is already about the nested
> (e.g vmcb12) thus I was thinking that naming this field vmcb12 would be
> redundant and not accepted this way.
We wa
On 20/08/20 12:05, Maxim Levitsky wrote:
>> You probably should set clean to 0 also if the guest doesn't have the
>> VMCBCLEAN feature (so, you first need an extra patch to add the
>> VMCBCLEAN feature to cpufeatures.h). It's probably best to cache the
>> guest vmcbclean in struct vcpu_svm, too.
>
On 20/08/20 12:00, Maxim Levitsky wrote:
>> Please use vmcb12_gpa, and svm->nested.vmcb12 for the VMCB in patch 6.
>>
>> (You probably also what to have local variables named vmcb12 in patch 6
>> to avoid too-long lines).
> The limit was raised to 100 chars recently, thats why I allowed some lines
On 20/08/20 11:13, Maxim Levitsky wrote:
> + u32 clean = nested_vmcb->control.clean;
> +
> + if (svm->nested.vmcb_gpa != vmcb_gpa) {
> + svm->nested.vmcb_gpa = vmcb_gpa;
> + clean = 0;
> + }
You probably should set clean to 0 also if the guest doesn't have the
V
On 18/08/20 12:16, Will Deacon wrote:
> Please note that I'm planning on rewriting most of the arm64 KVM page-table
> code for 5.10, so if you can get this series in early (e.g. for -rc2), then
> it would _really_ help with managing the kvm/arm64 queue for the next merge
> window.
Yes, I plan to s
On 18/08/20 18:49, Jason Gunthorpe wrote:
> On Tue, Aug 18, 2020 at 06:27:21PM +0200, Paolo Bonzini wrote:
>> On 18/08/20 13:50, Jason Gunthorpe wrote:
>>> For instance, what about suspend/resume of containers using idxd?
>>> Wouldn't you want to have the same b
On 18/08/20 13:50, Jason Gunthorpe wrote:
> For instance, what about suspend/resume of containers using idxd?
> Wouldn't you want to have the same basic approach of controlling the
> wq from userspace that virtualization uses?
The difference is that VFIO more or less standardizes the approach you
On 23/07/20 01:02, Thomas Gleixner wrote:
>> I am cc'ing Fenghua, who has volunteered to work on this. Addind support
>> for SERIALIZE in sync_core() should not block merging these patches,
>> correct?
> Come on. We are not serving KVM first before making this usable on bare
> metal.
This in the e
rmitted.
>
> Cheers,
>
> Will
>
> [1] https://android-kvm.googlesource.com/linux/+/refs/heads/topic/pgtable
>
> Cc: Marc Zyngier
> Cc: Suzuki K Poulose
> Cc: James Morse
> Cc: Thomas Bogendoerfer
> Cc: Paul Mackerras
> Cc: Paolo Bonzini
> Cc: Sean
On 17/08/20 20:42, Sean Christopherson wrote:
>
> Don't suppose you'd be in the mood to kill the bare 'unsigned'?
>
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
u32 is even better.
> Alternatively, what about capturing the result in a new variable (instead of
> defining the mask
On 17/08/20 20:42, Sean Christopherson wrote:
>
> Don't suppose you'd be in the mood to kill the bare 'unsigned'?
>
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
u32 is even better.
> Alternatively, what about capturing the result in a new variable (instead of
> defining the mask
On 17/08/20 19:22, Sean Christopherson wrote:
>> This splats when running the PKU unit test, although the test still passed.
>> I haven't yet spent the brain power to determine if this is a benign warning,
>> i.e. simply unexpected, or if permission_fault() fault truly can't handle PK
>> faults.
I
("KVM: x86: Add helper functions for illegal GPA checking
and page fault injection")
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/x86.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2db369a64f29..a6e42ce607ca 1
tly and, while at it, fix the "clobbers"
of the asm.
Reported-by: Yang Weijiang
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
tools/testing/selftests/kvm/x86_64/debug_regs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86_64/debu
On 13/08/20 14:13, Thomas Gleixner wrote:
Add metricfs support for displaying percpu irq counters for x86.
The top directory is /sys/kernel/debug/metricfs/irq_x86.
Then there is a subdirectory for each x86-specific irq counter.
For example:
cat /sys/kernel/debug/met
On 13/08/20 12:11, Thomas Gleixner wrote:
>> Add metricfs support for displaying percpu irq counters for x86.
>> The top directory is /sys/kernel/debug/metricfs/irq_x86.
>> Then there is a subdirectory for each x86-specific irq counter.
>> For example:
>>
>>cat /sys/kernel/debug/metricfs/irq_x8
On 12/08/20 15:31, pet...@infradead.org wrote:
> This isn't about x86, I want these checks in generic code. We have the
> flag, it needs checking.
>
> unpriv users have no busniess getting anything from a possible hv.
Ah ok if it's generic that sounds good.
>> That would be the case of an unpriv
On 12/08/20 14:56, Xu, Like wrote:
>
> My proposal is to define:
> the "hypervisor privilege levels" events in the KVM/x86 context as
> all the host kernel events plus /dev/kvm user space events.
What are "/dev/kvm user space events"? In any case, this patch should
be included only in the series
On 12/08/20 13:11, pet...@infradead.org wrote:
>> x86 does not have a hypervisor privilege level, so it never uses
>
> Arguably it does when Xen, but I don't think we support that, so *phew*.
Yeah, I suppose you could imagine having paravirtualized perf counters
where the Xen privileged domain co
On 12/08/20 07:07, Like Xu wrote:
> To emulate PMC counter for guest, KVM would create an
> event on the host with 'exclude_guest=0, exclude_hv=0'
> which simply makes no sense and is utterly broken.
>
> To keep perf semantics consistent, any event created by
> pmc_reprogram_counter() should both
ranch 'kvm-arm64/ptrauth-nvhe' into kvmarm-master/next-WIP
Merge branch 'kvm-arm64/target-table-no-more' into kvmarm-master/next-WIP
Merge branch 'kvm-arm64/misc-5.9' into kvmarm-master/next-WIP
Merge branch 'kvm-arm64/el2-obj-v4.1' into kv
ed
> make[1]: *** [arch/mips/kvm] Error 2
> Makefile:1785: recipe for target 'arch/mips' failed
> make: *** [arch/mips] Error 2
>
> Signed-off-by: Xingxing Su
> ---
> +cc Paolo Bonzini and k...@vger.kernel.org.
>
> arch/mips/kvm/vz.c | 3 +--
> 1 file ch
On 11/08/20 01:59, Luck, Tony wrote:
>
> Part 1: Add TSXLDTRK to cpufeatures.h Part 2: Add TSXLDTRK to
> arch/x86/kvm/cpuid.c (on top of the version that Paolo committed with
> SERIALIZE)
>
> Paolo: The 5.9 merge window is still open this week. Will you send
> the KVM serialize patch to Linus bef
On 10/08/20 12:16, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in an error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> tools/testing/selftests/kvm/lib/sparsebit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing
On 10/08/20 03:17, Jiaxun Yang wrote:
> There is a fallthrough comment being forgotten,
> GCC complains about it:
>
> arch/mips/kvm/emulate.c: In function kvm_mips_emulate_load:
> arch/mips/kvm/emulate.c:1936:21: error: this statement may fall through
> 1936 | vcpu->mmio_needed = 1; /* unsigned
On 09/08/20 09:47, Cathy Zhang wrote:
> Expose the SERIALIZE and TSX Suspend Load Address Tracking
> features in KVM CPUID, so when running on processors which
> support them, KVM could pass this information to guests and
> they can make use of these features accordingly.
>
> SERIALIZE is a faster
PA checking and page fault
injection
KVM: x86: mmu: Move translate_gpa() to mmu.c
KVM: x86: mmu: Add guest physical address check in translate_gpa()
KVM: VMX: Add guest physical address check in EPT violation and misconfig
KVM: x86: Add a capability for GUEST_MAXPHYADDR < HO
On 05/08/20 19:10, Ben Gardon wrote:
>>
>> Alternatively, what about moving this logic into mmu_page_zap_pte()? That
>> can be done with a little massaging of FNAME(invlpg) and would avoid what is
>> effectively redundant checks on is_shadow_present_pte() and is_last_spte().
>> Patches attached an
k the test results...
Marc Zyngier (1):
KVM: arm64: Prevent vcpu_has_ptrauth from generating OOL functions
Paolo Bonzini (4):
selftests: kvm: do not set guest mode flag
KVM: nVMX: check for required but missing VMCS12 in KVM_SET_NESTED_STATE
KVM: nVMX: check for invalid hdr
On 31/07/20 09:16, Peng Wu wrote:
> The declaration of function kvm_mips_complete_mmio_load
> has only one formal parameter,but two parameters are passed
> when called. So, the following error is seen while building
> emulate.c
>
> arch/mips/kvm/emulate.c: In function ‘kvm_mips_emulate_load’:
> ar
On 31/07/20 05:12, Wanpeng Li wrote:
> From: Wanpeng Li
>
> 'Commit 8566ac8b8e7c ("KVM: SVM: Implement pause loop exit logic in SVM")'
> drops disable pause loop exit/pause filtering capability completely, I
> guess it is a merge fault by Radim since disable vmexits capabilities and
> pause lo
901 - 1000 of 4022 matches
Mail list logo
