* Re: [PATCH net-next RFC 3/5] vhost: introduce vhost_add_used_idx()
From: Stefan Hajnoczi @ 2017-09-22 9:07 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1506067355-5771-4-git-send-email-jasowang@redhat.com>
On Fri, Sep 22, 2017 at 04:02:33PM +0800, Jason Wang wrote:
> This patch introduces a helper which just increase the used idx. This
> will be used in pair with vhost_prefetch_desc_indices() by batching
> code.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/vhost.c | 33 +++++++++++++++++++++++++++++++++
> drivers/vhost/vhost.h | 1 +
> 2 files changed, 34 insertions(+)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next] virtio-net: correctly set xdp_xmit for mergeable buffer
From: David Miller @ 2017-09-23 1:16 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, john.fastabend, linux-kernel, mst
In-Reply-To: <1506062338-3617-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 22 Sep 2017 14:38:58 +0800
> We should set xdp_xmit only when xdp_do_redirect() succeed.
>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks Jason.
^ permalink raw reply
* Re: [PATCH net-next RFC 1/5] vhost: split out ring head fetching logic
From: Jason Wang @ 2017-09-25 2:03 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <20170922083157.GA9243@stefanha-x1.localdomain>
On 2017年09月22日 16:31, Stefan Hajnoczi wrote:
> On Fri, Sep 22, 2017 at 04:02:31PM +0800, Jason Wang wrote:
>> +/* This looks in the virtqueue and for the first available buffer, and converts
>> + * it to an iovec for convenient access. Since descriptors consist of some
>> + * number of output then some number of input descriptors, it's actually two
>> + * iovecs, but we pack them into one and note how many of each there were.
>> + *
>> + * This function returns the descriptor number found, or vq->num (which is
>> + * never a valid descriptor number) if none was found. A negative code is
>> + * returned on error. */
>> +int __vhost_get_vq_desc(struct vhost_virtqueue *vq,
>> + struct iovec iov[], unsigned int iov_size,
>> + unsigned int *out_num, unsigned int *in_num,
>> + struct vhost_log *log, unsigned int *log_num,
>> + __virtio16 head)
> [...]
>> +int vhost_get_vq_desc(struct vhost_virtqueue *vq,
>> + struct iovec iov[], unsigned int iov_size,
>> + unsigned int *out_num, unsigned int *in_num,
>> + struct vhost_log *log, unsigned int *log_num)
> Please document vhost_get_vq_desc().
>
> Please also explain the difference between __vhost_get_vq_desc() and
> vhost_get_vq_desc() in the documentation.
Right, will document this in next version.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net-next RFC 2/5] vhost: introduce helper to prefetch desc index
From: Jason Wang @ 2017-09-25 2:04 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <20170922090257.GB9243@stefanha-x1.localdomain>
On 2017年09月22日 17:02, Stefan Hajnoczi wrote:
> On Fri, Sep 22, 2017 at 04:02:32PM +0800, Jason Wang wrote:
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index f87ec75..8424166d 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -2437,6 +2437,61 @@ struct vhost_msg_node *vhost_dequeue_msg(struct vhost_dev *dev,
>> }
>> EXPORT_SYMBOL_GPL(vhost_dequeue_msg);
>>
>> +int vhost_prefetch_desc_indices(struct vhost_virtqueue *vq,
>> + struct vring_used_elem *heads,
>> + u16 num, bool used_update)
> Missing doc comment.
Will fix this.
>
>> +{
>> + int ret, ret2;
>> + u16 last_avail_idx, last_used_idx, total, copied;
>> + __virtio16 avail_idx;
>> + struct vring_used_elem __user *used;
>> + int i;
> The following variable names are a little confusing:
>
> last_avail_idx vs vq->last_avail_idx. last_avail_idx is a wrapped
> avail->ring[] index, vq->last_avail_idx is a free-running counter. The
> same for last_used_idx vs vq->last_used_idx.
>
> num argument vs vq->num. The argument could be called nheads instead to
> make it clear that this is heads[] and not the virtqueue size.
>
> Not a bug but it took me a while to figure out what was going on.
I admit the name is confusing. Let me try better ones in V2.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH v1 0/4] Enable LBR for the guest
From: Wei Wang @ 2017-09-25 4:44 UTC (permalink / raw)
To: virtualization, kvm, linux-kernel, pbonzini, mst, rkrcmar, ak,
mingo
This patch series enables the Last Branch Recording feature for the
guest. Instead of trapping each LBR stack MSR access, the MSRs are
passthroughed to the guest. Those MSRs are switched (i.e. load and
saved) on VMExit and VMEntry.
Test:
Try "perf record -b ./test_program" on guest.
Wei Wang (4):
KVM/vmx: re-write the msr auto switch feature
KVM/vmx: auto switch MSR_IA32_DEBUGCTLMSR
perf/x86: add a function to get the lbr stack
KVM/vmx: enable lbr for the guest
arch/x86/events/intel/lbr.c | 23 +++++++
arch/x86/include/asm/perf_event.h | 14 ++++
arch/x86/kvm/vmx.c | 135 +++++++++++++++++++++++++++++++++-----
3 files changed, 154 insertions(+), 18 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v1 1/4] KVM/vmx: re-write the msr auto switch feature
From: Wei Wang @ 2017-09-25 4:44 UTC (permalink / raw)
To: virtualization, kvm, linux-kernel, pbonzini, mst, rkrcmar, ak,
mingo
In-Reply-To: <1506314696-4632-1-git-send-email-wei.w.wang@intel.com>
This patch clarifies a vague statement in the SDM: the recommended maximum
number of MSRs that can be automically switched by CPU during VMExit and
VMEntry is 512, rather than 512 Bytes of MSRs.
Depending on the CPU implementations, it may also support more than 512
MSRs to be auto switched. This can be calculated by
(MSR_IA32_VMX_MISC[27:25] + 1) * 512.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
---
arch/x86/kvm/vmx.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 63 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 0726ca7..8434fc8 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -158,6 +158,7 @@ module_param_named(preemption_timer, enable_preemption_timer, bool, S_IRUGO);
#define KVM_VMX_DEFAULT_PLE_WINDOW_SHRINK 0
#define KVM_VMX_DEFAULT_PLE_WINDOW_MAX \
INT_MAX / KVM_VMX_DEFAULT_PLE_WINDOW_GROW
+#define KVM_VMX_DEFAULT_MSR_AUTO_LOAD_COUNT 512
static int ple_gap = KVM_VMX_DEFAULT_PLE_GAP;
module_param(ple_gap, int, S_IRUGO);
@@ -178,9 +179,10 @@ static int ple_window_actual_max = KVM_VMX_DEFAULT_PLE_WINDOW_MAX;
static int ple_window_max = KVM_VMX_DEFAULT_PLE_WINDOW_MAX;
module_param(ple_window_max, int, S_IRUGO);
+static int msr_autoload_count_max = KVM_VMX_DEFAULT_MSR_AUTO_LOAD_COUNT;
+
extern const ulong vmx_return;
-#define NR_AUTOLOAD_MSRS 8
#define VMCS02_POOL_SIZE 1
struct vmcs {
@@ -588,8 +590,8 @@ struct vcpu_vmx {
bool __launched; /* temporary, used in vmx_vcpu_run */
struct msr_autoload {
unsigned nr;
- struct vmx_msr_entry guest[NR_AUTOLOAD_MSRS];
- struct vmx_msr_entry host[NR_AUTOLOAD_MSRS];
+ struct vmx_msr_entry *guest;
+ struct vmx_msr_entry *host;
} msr_autoload;
struct {
int loaded;
@@ -1942,6 +1944,7 @@ static void clear_atomic_switch_msr(struct vcpu_vmx *vmx, unsigned msr)
m->host[i] = m->host[m->nr];
vmcs_write32(VM_ENTRY_MSR_LOAD_COUNT, m->nr);
vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, m->nr);
+ vmcs_write32(VM_EXIT_MSR_STORE_COUNT, m->nr);
}
static void add_atomic_switch_msr_special(struct vcpu_vmx *vmx,
@@ -1997,7 +2000,7 @@ static void add_atomic_switch_msr(struct vcpu_vmx *vmx, unsigned msr,
if (m->guest[i].index == msr)
break;
- if (i == NR_AUTOLOAD_MSRS) {
+ if (i == msr_autoload_count_max) {
printk_once(KERN_WARNING "Not enough msr switch entries. "
"Can't add msr %x\n", msr);
return;
@@ -2005,6 +2008,7 @@ static void add_atomic_switch_msr(struct vcpu_vmx *vmx, unsigned msr,
++m->nr;
vmcs_write32(VM_ENTRY_MSR_LOAD_COUNT, m->nr);
vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, m->nr);
+ vmcs_write32(VM_EXIT_MSR_STORE_COUNT, m->nr);
}
m->guest[i].index = msr;
@@ -5501,6 +5505,7 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
vmcs_write32(VM_EXIT_MSR_STORE_COUNT, 0);
vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, 0);
vmcs_write64(VM_EXIT_MSR_LOAD_ADDR, __pa(vmx->msr_autoload.host));
+ vmcs_write64(VM_EXIT_MSR_STORE_ADDR, __pa(vmx->msr_autoload.guest));
vmcs_write32(VM_ENTRY_MSR_LOAD_COUNT, 0);
vmcs_write64(VM_ENTRY_MSR_LOAD_ADDR, __pa(vmx->msr_autoload.guest));
@@ -6670,6 +6675,21 @@ static void update_ple_window_actual_max(void)
ple_window_grow, INT_MIN);
}
+static void update_msr_autoload_count_max(void)
+{
+ u64 vmx_msr;
+ int n;
+
+ /*
+ * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is
+ * n, then (n + 1) * 512 is the recommended max number of MSRs to be
+ * included in the VMExit and VMEntry MSR auto switch list.
+ */
+ rdmsrl(MSR_IA32_VMX_MISC, vmx_msr);
+ n = ((vmx_msr & 0xe000000) >> 25) + 1;
+ msr_autoload_count_max = n * KVM_VMX_DEFAULT_MSR_AUTO_LOAD_COUNT;
+}
+
/*
* Handler for POSTED_INTERRUPT_WAKEUP_VECTOR.
*/
@@ -6837,6 +6857,7 @@ static __init int hardware_setup(void)
kvm_disable_tdp();
update_ple_window_actual_max();
+ update_msr_autoload_count_max();
/*
* Only enable PML when hardware supports PML feature, and both EPT
@@ -9248,6 +9269,19 @@ static void vmx_arm_hv_timer(struct kvm_vcpu *vcpu)
vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, delta_tsc);
}
+/*
+ * Currently, the CPU does not support the auto save of MSRs on VMEntry, so we
+ * save the MSRs for the host before entering into guest.
+ */
+static void vmx_save_host_msrs(struct msr_autoload *m)
+
+{
+ u32 i;
+
+ for (i = 0; i < m->nr; i++)
+ m->host[i].value = __rdmsr(m->host[i].index);
+}
+
static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -9304,6 +9338,8 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
vmx_arm_hv_timer(vcpu);
vmx->__launched = vmx->loaded_vmcs->launched;
+
+ vmx_save_host_msrs(&vmx->msr_autoload);
asm(
/* Store host registers */
"push %%" _ASM_DX "; push %%" _ASM_BP ";"
@@ -9504,6 +9540,7 @@ static void vmx_free_vcpu_nested(struct kvm_vcpu *vcpu)
static void vmx_free_vcpu(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
+ size_t bytes = msr_autoload_count_max * sizeof(struct vmx_msr_entry);
if (enable_pml)
vmx_destroy_pml_buffer(vmx);
@@ -9512,15 +9549,17 @@ static void vmx_free_vcpu(struct kvm_vcpu *vcpu)
vmx_free_vcpu_nested(vcpu);
free_loaded_vmcs(vmx->loaded_vmcs);
kfree(vmx->guest_msrs);
+ free_pages_exact(vmx->msr_autoload.host, bytes);
+ free_pages_exact(vmx->msr_autoload.guest, bytes);
kvm_vcpu_uninit(vcpu);
kmem_cache_free(kvm_vcpu_cache, vmx);
}
static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
{
- int err;
+ int err, cpu;
+ size_t bytes;
struct vcpu_vmx *vmx = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL);
- int cpu;
if (!vmx)
return ERR_PTR(-ENOMEM);
@@ -9559,6 +9598,17 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
goto free_msrs;
loaded_vmcs_init(vmx->loaded_vmcs);
+ bytes = msr_autoload_count_max * sizeof(struct vmx_msr_entry);
+ vmx->msr_autoload.guest = alloc_pages_exact(bytes,
+ GFP_KERNEL | __GFP_ZERO);
+ if (!vmx->msr_autoload.guest)
+ goto free_vmcs;
+
+ vmx->msr_autoload.host = alloc_pages_exact(bytes,
+ GFP_KERNEL | __GFP_ZERO);
+ if (!vmx->msr_autoload.guest)
+ goto free_autoload_guest;
+
cpu = get_cpu();
vmx_vcpu_load(&vmx->vcpu, cpu);
vmx->vcpu.cpu = cpu;
@@ -9566,11 +9616,11 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
vmx_vcpu_put(&vmx->vcpu);
put_cpu();
if (err)
- goto free_vmcs;
+ goto free_autoload_host;
if (cpu_need_virtualize_apic_accesses(&vmx->vcpu)) {
err = alloc_apic_access_page(kvm);
if (err)
- goto free_vmcs;
+ goto free_autoload_host;
}
if (enable_ept) {
@@ -9579,7 +9629,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
VMX_EPT_IDENTITY_PAGETABLE_ADDR;
err = init_rmode_identity_map(kvm);
if (err)
- goto free_vmcs;
+ goto free_autoload_host;
}
if (nested) {
@@ -9594,6 +9644,10 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm, unsigned int id)
return &vmx->vcpu;
+free_autoload_host:
+ free_pages_exact(vmx->msr_autoload.host, bytes);
+free_autoload_guest:
+ free_pages_exact(vmx->msr_autoload.guest, bytes);
free_vmcs:
free_vpid(vmx->nested.vpid02);
free_loaded_vmcs(vmx->loaded_vmcs);
--
2.7.4
^ permalink raw reply related
* [PATCH v1 2/4] KVM/vmx: auto switch MSR_IA32_DEBUGCTLMSR
From: Wei Wang @ 2017-09-25 4:44 UTC (permalink / raw)
To: virtualization, kvm, linux-kernel, pbonzini, mst, rkrcmar, ak,
mingo
In-Reply-To: <1506314696-4632-1-git-send-email-wei.w.wang@intel.com>
Passthrough the MSR_IA32_DEBUGCTLMSR to the guest, and take advantage of
the hardware VT-x feature to auto switch the msr upon VMExit and VMEntry.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
---
arch/x86/kvm/vmx.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8434fc8..5f5c2f1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5502,13 +5502,12 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
if (cpu_has_vmx_vmfunc())
vmcs_write64(VM_FUNCTION_CONTROL, 0);
- vmcs_write32(VM_EXIT_MSR_STORE_COUNT, 0);
- vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, 0);
vmcs_write64(VM_EXIT_MSR_LOAD_ADDR, __pa(vmx->msr_autoload.host));
vmcs_write64(VM_EXIT_MSR_STORE_ADDR, __pa(vmx->msr_autoload.guest));
- vmcs_write32(VM_ENTRY_MSR_LOAD_COUNT, 0);
vmcs_write64(VM_ENTRY_MSR_LOAD_ADDR, __pa(vmx->msr_autoload.guest));
+ add_atomic_switch_msr(vmx, MSR_IA32_DEBUGCTLMSR, 0, 0);
+
if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT)
vmcs_write64(GUEST_IA32_PAT, vmx->vcpu.arch.pat);
@@ -6821,6 +6820,7 @@ static __init int hardware_setup(void)
vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_CS, false);
vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_ESP, false);
vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, false);
+ vmx_disable_intercept_for_msr(MSR_IA32_DEBUGCTLMSR, false);
memcpy(vmx_msr_bitmap_legacy_x2apic_apicv,
vmx_msr_bitmap_legacy, PAGE_SIZE);
@@ -9285,7 +9285,7 @@ static void vmx_save_host_msrs(struct msr_autoload *m)
static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
- unsigned long debugctlmsr, cr3, cr4;
+ unsigned long cr3, cr4;
/* Don't enter VMX if guest state is invalid, let the exit handler
start emulation until we arrive back to a valid state */
@@ -9333,7 +9333,6 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
__write_pkru(vcpu->arch.pkru);
atomic_switch_perf_msrs(vmx);
- debugctlmsr = get_debugctlmsr();
vmx_arm_hv_timer(vcpu);
@@ -9445,10 +9444,6 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
#endif
);
- /* MSR_IA32_DEBUGCTLMSR is zeroed on vmexit. Restore it if needed */
- if (debugctlmsr)
- update_debugctlmsr(debugctlmsr);
-
#ifndef CONFIG_X86_64
/*
* The sysexit path does not restore ds/es, so we must set them to
--
2.7.4
^ permalink raw reply related
* [PATCH v1 3/4] perf/x86: add a function to get the lbr stack
From: Wei Wang @ 2017-09-25 4:44 UTC (permalink / raw)
To: virtualization, kvm, linux-kernel, pbonzini, mst, rkrcmar, ak,
mingo
In-Reply-To: <1506314696-4632-1-git-send-email-wei.w.wang@intel.com>
The LBR stack MSRs are architecturally specific. The perf subsystem has
already assigned the abstracted MSR values based on the CPU architecture.
This patch enables a caller outside the perf subsystem to get the LBR
stack info. This is useful for hyperviosrs to prepare the lbr feature
for the guest.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
---
arch/x86/events/intel/lbr.c | 23 +++++++++++++++++++++++
arch/x86/include/asm/perf_event.h | 14 ++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 8a6bbac..ea547ec 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1230,3 +1230,26 @@ void intel_pmu_lbr_init_knl(void)
x86_pmu.lbr_sel_mask = LBR_SEL_MASK;
x86_pmu.lbr_sel_map = snb_lbr_sel_map;
}
+
+/**
+ * perf_get_lbr_stack - get the lbr stack related MSRs
+ *
+ * @stack: the caller's memory to get the lbr stack
+ *
+ * Returns: 0 indicates that the lbr stack has been successfully obtained.
+ */
+int perf_get_lbr_stack(struct perf_lbr_stack *stack)
+{
+ stack->lbr_nr = x86_pmu.lbr_nr;
+ stack->lbr_tos = x86_pmu.lbr_tos;
+ stack->lbr_from = x86_pmu.lbr_from;
+ stack->lbr_to = x86_pmu.lbr_to;
+
+ if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
+ stack->lbr_info = MSR_LBR_INFO_0;
+ else
+ stack->lbr_info = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(perf_get_lbr_stack);
diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h
index f353061..c098462 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -266,7 +266,16 @@ struct perf_guest_switch_msr {
u64 host, guest;
};
+struct perf_lbr_stack {
+ int lbr_nr;
+ unsigned long lbr_tos;
+ unsigned long lbr_from;
+ unsigned long lbr_to;
+ unsigned long lbr_info;
+};
+
extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);
+extern int perf_get_lbr_stack(struct perf_lbr_stack *stack);
extern void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap);
extern void perf_check_microcode(void);
#else
@@ -276,6 +285,11 @@ static inline struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
return NULL;
}
+static inline int perf_get_lbr_stack(struct perf_lbr_stack *stack)
+{
+ return -1;
+}
+
static inline void perf_get_x86_pmu_capability(struct x86_pmu_capability *cap)
{
memset(cap, 0, sizeof(*cap));
--
2.7.4
^ permalink raw reply related
* [PATCH v1 4/4] KVM/vmx: enable lbr for the guest
From: Wei Wang @ 2017-09-25 4:44 UTC (permalink / raw)
To: virtualization, kvm, linux-kernel, pbonzini, mst, rkrcmar, ak,
mingo
In-Reply-To: <1506314696-4632-1-git-send-email-wei.w.wang@intel.com>
Passthrough the LBR stack to the guest, and auto switch the stack MSRs
upon VMEntry and VMExit.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
---
arch/x86/kvm/vmx.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5f5c2f1..35e02a7 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -107,6 +107,9 @@ static u64 __read_mostly host_xss;
static bool __read_mostly enable_pml = 1;
module_param_named(pml, enable_pml, bool, S_IRUGO);
+static bool __read_mostly enable_lbrv = 1;
+module_param_named(lbrv, enable_lbrv, bool, 0444);
+
#define KVM_VMX_TSC_MULTIPLIER_MAX 0xffffffffffffffffULL
/* Guest_tsc -> host_tsc conversion requires 64-bit division. */
@@ -5428,6 +5431,25 @@ static void ept_set_mmio_spte_mask(void)
VMX_EPT_MISCONFIG_WX_VALUE);
}
+static void auto_switch_lbr_msrs(struct vcpu_vmx *vmx)
+{
+ int i;
+ struct perf_lbr_stack lbr_stack;
+
+ perf_get_lbr_stack(&lbr_stack);
+
+ add_atomic_switch_msr(vmx, MSR_LBR_SELECT, 0, 0);
+ add_atomic_switch_msr(vmx, lbr_stack.lbr_tos, 0, 0);
+
+ for (i = 0; i < lbr_stack.lbr_nr; i++) {
+ add_atomic_switch_msr(vmx, lbr_stack.lbr_from + i, 0, 0);
+ add_atomic_switch_msr(vmx, lbr_stack.lbr_to + i, 0, 0);
+ if (lbr_stack.lbr_info)
+ add_atomic_switch_msr(vmx, lbr_stack.lbr_info + i, 0,
+ 0);
+ }
+}
+
#define VMX_XSS_EXIT_BITMAP 0
/*
* Sets up the vmcs for emulated real mode.
@@ -5508,6 +5530,9 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
add_atomic_switch_msr(vmx, MSR_IA32_DEBUGCTLMSR, 0, 0);
+ if (enable_lbrv)
+ auto_switch_lbr_msrs(vmx);
+
if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT)
vmcs_write64(GUEST_IA32_PAT, vmx->vcpu.arch.pat);
@@ -6721,6 +6746,28 @@ void vmx_enable_tdp(void)
kvm_enable_tdp();
}
+static void vmx_passthrough_lbr_msrs(void)
+{
+ int i;
+ struct perf_lbr_stack lbr_stack;
+
+ if (perf_get_lbr_stack(&lbr_stack) < 0) {
+ enable_lbrv = false;
+ return;
+ }
+
+ vmx_disable_intercept_for_msr(MSR_LBR_SELECT, false);
+ vmx_disable_intercept_for_msr(lbr_stack.lbr_tos, false);
+
+ for (i = 0; i < lbr_stack.lbr_nr; i++) {
+ vmx_disable_intercept_for_msr(lbr_stack.lbr_from + i, false);
+ vmx_disable_intercept_for_msr(lbr_stack.lbr_to + i, false);
+ if (lbr_stack.lbr_info)
+ vmx_disable_intercept_for_msr(lbr_stack.lbr_info + i,
+ false);
+ }
+}
+
static __init int hardware_setup(void)
{
int r = -ENOMEM, i, msr;
@@ -6822,6 +6869,9 @@ static __init int hardware_setup(void)
vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, false);
vmx_disable_intercept_for_msr(MSR_IA32_DEBUGCTLMSR, false);
+ if (enable_lbrv)
+ vmx_passthrough_lbr_msrs();
+
memcpy(vmx_msr_bitmap_legacy_x2apic_apicv,
vmx_msr_bitmap_legacy, PAGE_SIZE);
memcpy(vmx_msr_bitmap_longmode_x2apic_apicv,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v1 4/4] KVM/vmx: enable lbr for the guest
From: Paolo Bonzini @ 2017-09-25 9:16 UTC (permalink / raw)
To: Wei Wang, virtualization, kvm, linux-kernel, mst, rkrcmar, ak,
mingo
In-Reply-To: <1506314696-4632-5-git-send-email-wei.w.wang@intel.com>
On 25/09/2017 06:44, Wei Wang wrote:
> Passthrough the LBR stack to the guest, and auto switch the stack MSRs
> upon VMEntry and VMExit.
>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
This has to be enabled separately for each guest, because it may prevent
live migration to hosts with a different family/model.
Paolo
> ---
> arch/x86/kvm/vmx.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 5f5c2f1..35e02a7 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -107,6 +107,9 @@ static u64 __read_mostly host_xss;
> static bool __read_mostly enable_pml = 1;
> module_param_named(pml, enable_pml, bool, S_IRUGO);
>
> +static bool __read_mostly enable_lbrv = 1;
> +module_param_named(lbrv, enable_lbrv, bool, 0444);
> +
> #define KVM_VMX_TSC_MULTIPLIER_MAX 0xffffffffffffffffULL
>
> /* Guest_tsc -> host_tsc conversion requires 64-bit division. */
> @@ -5428,6 +5431,25 @@ static void ept_set_mmio_spte_mask(void)
> VMX_EPT_MISCONFIG_WX_VALUE);
> }
>
> +static void auto_switch_lbr_msrs(struct vcpu_vmx *vmx)
> +{
> + int i;
> + struct perf_lbr_stack lbr_stack;
> +
> + perf_get_lbr_stack(&lbr_stack);
> +
> + add_atomic_switch_msr(vmx, MSR_LBR_SELECT, 0, 0);
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_tos, 0, 0);
> +
> + for (i = 0; i < lbr_stack.lbr_nr; i++) {
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_from + i, 0, 0);
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_to + i, 0, 0);
> + if (lbr_stack.lbr_info)
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_info + i, 0,
> + 0);
> + }
> +}
> +
> #define VMX_XSS_EXIT_BITMAP 0
> /*
> * Sets up the vmcs for emulated real mode.
> @@ -5508,6 +5530,9 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
>
> add_atomic_switch_msr(vmx, MSR_IA32_DEBUGCTLMSR, 0, 0);
>
> + if (enable_lbrv)
> + auto_switch_lbr_msrs(vmx);
> +
> if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT)
> vmcs_write64(GUEST_IA32_PAT, vmx->vcpu.arch.pat);
>
> @@ -6721,6 +6746,28 @@ void vmx_enable_tdp(void)
> kvm_enable_tdp();
> }
>
> +static void vmx_passthrough_lbr_msrs(void)
> +{
> + int i;
> + struct perf_lbr_stack lbr_stack;
> +
> + if (perf_get_lbr_stack(&lbr_stack) < 0) {
> + enable_lbrv = false;
> + return;
> + }
> +
> + vmx_disable_intercept_for_msr(MSR_LBR_SELECT, false);
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_tos, false);
> +
> + for (i = 0; i < lbr_stack.lbr_nr; i++) {
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_from + i, false);
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_to + i, false);
> + if (lbr_stack.lbr_info)
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_info + i,
> + false);
> + }
> +}
> +
> static __init int hardware_setup(void)
> {
> int r = -ENOMEM, i, msr;
> @@ -6822,6 +6869,9 @@ static __init int hardware_setup(void)
> vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, false);
> vmx_disable_intercept_for_msr(MSR_IA32_DEBUGCTLMSR, false);
>
> + if (enable_lbrv)
> + vmx_passthrough_lbr_msrs();
> +
> memcpy(vmx_msr_bitmap_legacy_x2apic_apicv,
> vmx_msr_bitmap_legacy, PAGE_SIZE);
> memcpy(vmx_msr_bitmap_longmode_x2apic_apicv,
>
^ permalink raw reply
* Re: [PATCH v1 1/4] KVM/vmx: re-write the msr auto switch feature
From: Paolo Bonzini @ 2017-09-25 11:54 UTC (permalink / raw)
To: Wei Wang, virtualization, kvm, linux-kernel, mst, rkrcmar, ak,
mingo
In-Reply-To: <1506314696-4632-2-git-send-email-wei.w.wang@intel.com>
On 25/09/2017 06:44, Wei Wang wrote:
>
> +static void update_msr_autoload_count_max(void)
> +{
> + u64 vmx_msr;
> + int n;
> +
> + /*
> + * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is
> + * n, then (n + 1) * 512 is the recommended max number of MSRs to be
> + * included in the VMExit and VMEntry MSR auto switch list.
> + */
> + rdmsrl(MSR_IA32_VMX_MISC, vmx_msr);
> + n = ((vmx_msr & 0xe000000) >> 25) + 1;
> + msr_autoload_count_max = n * KVM_VMX_DEFAULT_MSR_AUTO_LOAD_COUNT;
> +}
> +
Any reasons to do this if it's unlikely that we'll ever update more than
512 MSRs?
Paolo
^ permalink raw reply
* Re: [PATCH v1 2/4] KVM/vmx: auto switch MSR_IA32_DEBUGCTLMSR
From: Paolo Bonzini @ 2017-09-25 11:57 UTC (permalink / raw)
To: Wei Wang, virtualization, kvm, linux-kernel, mst, rkrcmar, ak,
mingo
In-Reply-To: <1506314696-4632-3-git-send-email-wei.w.wang@intel.com>
On 25/09/2017 06:44, Wei Wang wrote:
> Passthrough the MSR_IA32_DEBUGCTLMSR to the guest, and take advantage of
> the hardware VT-x feature to auto switch the msr upon VMExit and VMEntry.
I think most bits in the MSR should not be passed through (for example
FREEZE_WHILE_SMM_EN, FREEZE_LBRS_ON_PMI etc.). Using auto-switch of
course is fine instead.
Paolo
^ permalink raw reply
* Re: [PATCH v1 4/4] KVM/vmx: enable lbr for the guest
From: Wei Wang @ 2017-09-25 12:57 UTC (permalink / raw)
To: Paolo Bonzini, virtualization, kvm, linux-kernel, mst, rkrcmar,
ak, mingo
In-Reply-To: <d4a81b5d-87ec-d118-112f-b017e58aa6e7@redhat.com>
On 09/25/2017 05:16 PM, Paolo Bonzini wrote:
> On 25/09/2017 06:44, Wei Wang wrote:
>> Passthrough the LBR stack to the guest, and auto switch the stack MSRs
>> upon VMEntry and VMExit.
>>
>> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> This has to be enabled separately for each guest, because it may prevent
> live migration to hosts with a different family/model.
Did you mean trapping MSR_IA32_DEBUGCTLMSR, instead of passing through it?
In that case, we would also need to modify the kernel driver (i.e. the
PMI handler)
to check MSR_IA32_DEBUGCTLMSR before reading the LBR MSRs. Then the guest
driver can notice that the feature that is in use has been disabled
after live
migration.
This kind of live migration disables features that are being used. Would
it be
common in real usage to migrate between different CPU models?
I think this issue isn't specific to the LBR feature. May I know how
would other
features be handled in this case? Thanks.
On the other hand, an alternative approach coming up to my mind is that we
can do some kind of feature negotiation at the very beginning of
migration, and
fails live migration if the feature negotiation fails.
Best,
Wei
^ permalink raw reply
* Re: [PATCH v1 1/4] KVM/vmx: re-write the msr auto switch feature
From: Wei Wang @ 2017-09-25 13:02 UTC (permalink / raw)
To: Paolo Bonzini, virtualization, kvm, linux-kernel, mst, rkrcmar,
ak, mingo
In-Reply-To: <7f9d54dd-546a-548f-5425-e4151e09fbdc@redhat.com>
On 09/25/2017 07:54 PM, Paolo Bonzini wrote:
> On 25/09/2017 06:44, Wei Wang wrote:
>>
>> +static void update_msr_autoload_count_max(void)
>> +{
>> + u64 vmx_msr;
>> + int n;
>> +
>> + /*
>> + * According to the Intel SDM, if Bits 27:25 of MSR_IA32_VMX_MISC is
>> + * n, then (n + 1) * 512 is the recommended max number of MSRs to be
>> + * included in the VMExit and VMEntry MSR auto switch list.
>> + */
>> + rdmsrl(MSR_IA32_VMX_MISC, vmx_msr);
>> + n = ((vmx_msr & 0xe000000) >> 25) + 1;
>> + msr_autoload_count_max = n * KVM_VMX_DEFAULT_MSR_AUTO_LOAD_COUNT;
>> +}
>> +
>
> Any reasons to do this if it's unlikely that we'll ever update more than
> 512 MSRs?
>
> Paolo
It isn't a must to allocate memory for 512 MSRs, but I think it would be
good to
allocate memory at least for 128 MSRs, because on skylake we have 32
triplets
of MSRs (FROM/TO/INFO), which are 96 in total already.
The disadvantage is that developers would need to manually calculate and
change
the number carefully when they need to add new MSRs for auto switching
in the
future. So, if consuming a little bit more memory isn't a concern, I
think we can
directly allocate memory based on what's recommended by the hardware.
Best,
Wei
^ permalink raw reply
* Re: [virtio-dev] RE: [RFC] virtio-iommu version 0.4
From: Jean-Philippe Brucker @ 2017-09-25 13:32 UTC (permalink / raw)
To: Tian, Kevin, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Cc: Lorenzo Pieralisi, mst@redhat.com, Marc Zyngier, Will Deacon,
eric.auger@redhat.com, Robin Murphy, eric.auger.pro@gmail.com
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D190DDCF8D@SHSMSX101.ccr.corp.intel.com>
On 21/09/17 07:27, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker
>> Sent: Wednesday, September 6, 2017 7:55 PM
>>
>> Hi Kevin,
>>
>> On 28/08/17 08:39, Tian, Kevin wrote:
>>> Here comes some comments:
>>>
>>> 1.1 Motivation
>>>
>>> You describe I/O page faults handling as future work. Seems you
>> considered
>>> only recoverable fault (since "aka. PCI PRI" being used). What about other
>>> unrecoverable faults e.g. what to do if a virtual DMA request doesn't find
>>> a valid mapping? Even when there is no PRI support, we need some basic
>>> form of fault reporting mechanism to indicate such errors to guest.
>>
>> I am considering recoverable faults as the end goal, but reporting
>> unrecoverable faults should use the same queue, with slightly different
>> fields and no need for the driver to reply to the device.
>
> what about adding a placeholder for now? Though same mechanism
> can be reused, it's an essential part to make virtio-iommu architecture
> complete even before talking support for recoverable faults. :-)
I'll see if I can come up with something simple for v0.5, but it seems
like a big chunk of work. I don't really know what to report to the guest
at the moment. I don't want to report vendor-specific details about the
fault, but it should still be useful content, to let the guest decide
whether they need to reset/kill the device or just print something
[...]
>> Yes I think adding MEM_T_IDENTITY will be necessary. I can see they are
>> used for both iGPU and USB controllers on my x86 machines. Do you know
>> more precisely what they are used for by the firmware?
>
> VTd spec has a clear description:
>
> 3.14 Handling Requests to Reserved System Memory
> Reserved system memory regions are typically allocated by BIOS at boot
> time and reported to OS as reserved address ranges in the system memory
> map. Requests-without-PASID to these reserved regions may either occur
> as a result of operations performed by the system software driver (for
> example in the case of DMA from unified memory access (UMA) graphics
> controllers to graphics reserved memory), or may be initiated by non
> system software (for example in case of DMA performed by a USB
> controller under BIOS SMM control for legacy keyboard emulation).
> For proper functioning of these legacy reserved memory usages, when
> system software enables DMA remapping, the second-level translation
> structures for the respective devices are expected to be set up to provide
> identity mapping for the specified reserved memory regions with read
> and write permissions.
>
> (one specific example for GPU happens in legacy VGA usage in early
> boot time before actual graphics driver is loaded)
Thanks for the explanation. So it is only legacy, and enabling nested mode
would be forbidden for a device with Reserved System Memory regions? I'm
wondering if virtio-iommu RESV regions will be extended to affect a
specific PASIDs (or all requests-with-PASID) in the future.
>> It's not necessary with the base virtio-iommu device though (v0.4),
>> because the device can create the identity mappings itself and report them
>> to the guest as MEM_T_BYPASS. However, when we start handing page
>
> when you say "the device can create ...", I think you really meant
> "host iommu driver can create identity mapping for assigned device",
> correct?
>
> Then yes, I think above works.
Yes it can be the host IOMMU driver, or simply Qemu sending VFIO ioctls to
create those identity mappings (they are reported in sysfs reserved_regions).
>> table
>> control over to the guest, the host won't be in control of IOVA->GPA
>> mappings and will need to gracefully ask the guest to do it.
>>
>> I'm not aware of any firmware description resembling Intel RMRR or AMD
>> IVMD on ARM platforms. I do think ARM platforms could need
>> MEM_T_IDENTITY
>> for requesting the guest to map MSI windows when page-table handover is
>> in
>> use (MSI addresses are translated by the physical SMMU, so a IOVA->GPA
>> mapping must be installed by the guest). But since a vSMMU would need a
>> solution as well, I think I'll try to implement something more generic.
>
> curious do you need identity mapping full IOVA->GPA->HPA translation,
> or just in GPA->HPA stage sufficient for above MSI scenario?
It has to be IOVA->GPA->HPA. So it'll be a bit complicated to implement
for us, I think we're going to need a VFIO ioctl to tell the host what
IOVA the guest allocated for its MSI, but it's not ideal.
Thanks,
Jean
^ permalink raw reply
* Re: [virtio-dev] [RFC] virtio-iommu version 0.4
From: Jean-Philippe Brucker @ 2017-09-25 13:47 UTC (permalink / raw)
To: Tian, Kevin, Auger Eric, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org
Cc: Lorenzo Pieralisi, mst@redhat.com, Marc Zyngier, Will Deacon,
Robin Murphy, eric.auger.pro@gmail.com
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D190DDD022@SHSMSX101.ccr.corp.intel.com>
On 21/09/17 07:41, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker@arm.com]
>> Sent: Wednesday, September 6, 2017 7:49 PM
>>
>>
>>> 2.6.8.2.1
>>> Multiple overlapping RESV_MEM properties are merged together. Device
>>> requirement? if same types I assume?
>>
>> Combination rules apply to device and driver. When the driver puts
>> multiple endpoints in the same domain, combination rules apply. They will
>> become important once the guest attempts to do things like combining
>> endpoints with different PASID capabilities in the same domain. I'm
>> considering these endpoints to be behind different physical IOMMUs.
>>
>> For reserved regions, we specify what the driver should do and what the
>> device should enforce with regard to mapping IOVAs of overlapping regions.
>> For example, if a device has some virtual address RESV_T_MSI and an other
>> device has the same virtual address RESV_T_IDENTITY, what should the
>> driver do?
>>
>> I think it should apply the RESV_T_IDENTITY. RESV_T_MSI is just a special
>> case of RESV_T_RESERVED, it's a hint for the IRQ subsystem and doesn't
>> have a meaning within a domain. From DMA mappings point of view, it is
>> effectively the same as RESV_T_RESERVED. When merging
>> RESV_T_RESERVED and
>> RESV_T_IDENTITY, we should make it RESV_T_IDENTITY. Because it is
>> required
>> for one endpoint to work (the one with IDENTITY) and is not accessed by
>> the other (the driver must not allocate this IOVA range for DMA).
>>
>> More generally, I'd like to add the following combination table to the
>> spec, that shows the resulting reserved region type after merging regions
>> from two endpoints. N: no reserved region, R: RESV_T_RESERVED, M:
>> RESV_T_MSI, I: RESV_T_IDENTITY. It is symmetric so I didn't fill the
>> bottom half.
>>
>> | N | R | M | I
>> ------------------
>> N | N | R | M | ?
>> ------------------
>> R | | R | R | I
>> ------------------
>> M | | | M | I
>> ------------------
>> I | | | | I
>>
>> The 'I' column is problematic. If one endpoint has an IDENTITY region and
>> the other doesn't have anything at that virtual address, then making that
>> region an identity mapping will result in the second endpoint being able
>> to access firmware memory. If using nested translation, stage-2 can help
>> us here. But in general we should allow the device to reject an attach
>> that would result in a N+I combination if the host considers it too dodgy.
>> I think the other combinations are safe enough.
>>
>
> will overlap happen in real? Can we simplify the spec to have device
> not reporting overlapping regions?
I think it's likely to happen, to have two endpoints with different
overlapping types. Reporting is easy, but handling mismatched reserved
regions is hard. So what I can do is leave these combination rules as
implementation detail, and let the device reject any domain attach that
overlaps mismatched RESV regions.
After all, putting multiple devices in the same domain is a nice feature
but might not be widely used in reality. It's not worth spending too much
time describing all possible behaviors for it (but still worth thinking
about to avoid introducing security holes).
Thanks,
Jean
^ permalink raw reply
* Re: [PATCH v3 0/2] guard virt_spin_lock() with a static key
From: Juergen Gross @ 2017-09-25 13:59 UTC (permalink / raw)
To: linux-kernel, xen-devel, x86, virtualization
Cc: jeremy, peterz, rusty, chrisw, mingo, tglx, hpa, longman,
akataria, boris.ostrovsky
In-Reply-To: <20170906173625.18158-1-jgross@suse.com>
Ping?
On 06/09/17 19:36, Juergen Gross wrote:
> With virt_spin_lock() being guarded by a static key the bare metal case
> can be optimized by patching the call away completely. In case a kernel
> running as a guest it can decide whether to use paravitualized
> spinlocks, the current fallback to the unfair test-and-set scheme, or
> to mimic the bare metal behavior.
>
> V3:
> - remove test for hypervisor environment from virt_spin_lock(9 as
> suggested by Waiman Long
>
> V2:
> - use static key instead of making virt_spin_lock() a pvops function
>
> Juergen Gross (2):
> paravirt/locks: use new static key for controlling call of
> virt_spin_lock()
> paravirt,xen: correct xen_nopvspin case
>
> arch/x86/include/asm/qspinlock.h | 11 ++++++++++-
> arch/x86/kernel/paravirt-spinlocks.c | 6 ++++++
> arch/x86/kernel/smpboot.c | 2 ++
> arch/x86/xen/spinlock.c | 2 ++
> kernel/locking/qspinlock.c | 4 ++++
> 5 files changed, 24 insertions(+), 1 deletion(-)
>
^ permalink raw reply
* Re: [PATCH v1 1/4] KVM/vmx: re-write the msr auto switch feature
From: Paolo Bonzini @ 2017-09-25 14:24 UTC (permalink / raw)
To: Wei Wang, virtualization, kvm, linux-kernel, mst, rkrcmar, ak,
mingo
In-Reply-To: <59C8FE6E.7070503@intel.com>
On 25/09/2017 15:02, Wei Wang wrote:
> On 09/25/2017 07:54 PM, Paolo Bonzini wrote:
>> On 25/09/2017 06:44, Wei Wang wrote:
>>> +static void update_msr_autoload_count_max(void)
>>> +{
>>> + u64 vmx_msr;
>>> + int n;
>>> +
>>> + /*
>>> + * According to the Intel SDM, if Bits 27:25 of
>>> MSR_IA32_VMX_MISC is
>>> + * n, then (n + 1) * 512 is the recommended max number of MSRs
>>> to be
>>> + * included in the VMExit and VMEntry MSR auto switch list.
>>> + */
>>> + rdmsrl(MSR_IA32_VMX_MISC, vmx_msr);
>>> + n = ((vmx_msr & 0xe000000) >> 25) + 1;
>>> + msr_autoload_count_max = n * KVM_VMX_DEFAULT_MSR_AUTO_LOAD_COUNT;
>>> +}
>>> +
>>
>> Any reasons to do this if it's unlikely that we'll ever update more than
>> 512 MSRs?
>>
>> Paolo
>
> It isn't a must to allocate memory for 512 MSRs, but I think it would
> be good to allocate memory at least for 128 MSRs, because on skylake
> we have 32 triplets of MSRs (FROM/TO/INFO), which are 96 in total
> already.
>
> The disadvantage is that developers would need to manually calculate
> and change the number carefully when they need to add new MSRs for
> auto switching in the future. So, if consuming a little bit more
> memory isn't a concern, I think we can directly allocate memory based
> on what's recommended by the hardware.
Sure. I was just thinking that it's unnecessary to actually use
VMX_MISC; sticking to one-page allocations is nicer.
Paolo
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 0/2] guard virt_spin_lock() with a static key
From: Waiman Long @ 2017-09-25 14:44 UTC (permalink / raw)
To: Juergen Gross, linux-kernel, xen-devel, x86, virtualization
Cc: jeremy, peterz, rusty, chrisw, mingo, tglx, hpa, akataria,
boris.ostrovsky
In-Reply-To: <780c50a0-160b-24e3-a5b2-6685953882e5@suse.com>
On 09/25/2017 09:59 AM, Juergen Gross wrote:
> Ping?
>
> On 06/09/17 19:36, Juergen Gross wrote:
>> With virt_spin_lock() being guarded by a static key the bare metal case
>> can be optimized by patching the call away completely. In case a kernel
>> running as a guest it can decide whether to use paravitualized
>> spinlocks, the current fallback to the unfair test-and-set scheme, or
>> to mimic the bare metal behavior.
>>
>> V3:
>> - remove test for hypervisor environment from virt_spin_lock(9 as
>> suggested by Waiman Long
>>
>> V2:
>> - use static key instead of making virt_spin_lock() a pvops function
>>
>> Juergen Gross (2):
>> paravirt/locks: use new static key for controlling call of
>> virt_spin_lock()
>> paravirt,xen: correct xen_nopvspin case
>>
>> arch/x86/include/asm/qspinlock.h | 11 ++++++++++-
>> arch/x86/kernel/paravirt-spinlocks.c | 6 ++++++
>> arch/x86/kernel/smpboot.c | 2 ++
>> arch/x86/xen/spinlock.c | 2 ++
>> kernel/locking/qspinlock.c | 4 ++++
>> 5 files changed, 24 insertions(+), 1 deletion(-)
>>
Acked-by: Waiman Long <longman@redhat.com>
^ permalink raw reply
* [PATCH] KVM: s390: Disable CONFIG_S390_GUEST_OLD_TRANSPORT by default
From: Thomas Huth @ 2017-09-25 14:45 UTC (permalink / raw)
To: Halil Pasic, Cornelia Huck; +Cc: linux-s390, kvm, virtualization
There is no recent user space application available anymore which still
supports this old virtio transport, so let's disable this by default.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
arch/s390/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 48af970..923bf04 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -930,7 +930,7 @@ config S390_GUEST
the KVM hypervisor.
config S390_GUEST_OLD_TRANSPORT
- def_bool y
+ def_bool n
prompt "Guest support for old s390 virtio transport (DEPRECATED)"
depends on S390_GUEST
help
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v1 4/4] KVM/vmx: enable lbr for the guest
From: Andi Kleen @ 2017-09-25 14:57 UTC (permalink / raw)
To: Wei Wang; +Cc: kvm, mst, rkrcmar, linux-kernel, virtualization, mingo, pbonzini
In-Reply-To: <1506314696-4632-5-git-send-email-wei.w.wang@intel.com>
> +static void auto_switch_lbr_msrs(struct vcpu_vmx *vmx)
> +{
> + int i;
> + struct perf_lbr_stack lbr_stack;
> +
> + perf_get_lbr_stack(&lbr_stack);
> +
> + add_atomic_switch_msr(vmx, MSR_LBR_SELECT, 0, 0);
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_tos, 0, 0);
> +
> + for (i = 0; i < lbr_stack.lbr_nr; i++) {
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_from + i, 0, 0);
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_to + i, 0, 0);
> + if (lbr_stack.lbr_info)
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_info + i, 0,
> + 0);
> + }
That will be really expensive and add a lot of overhead to every entry/exit.
perf can already context switch the LBRs on task context switch. With that
you can just switch LBR_SELECT, which is *much* cheaper because there
are far less context switches than exit/entries.
It implies that when KVM is running it needs to prevent perf from enabling
LBRs in the context of KVM, but that should be straight forward.
-Andi
^ permalink raw reply
* Re: [PATCH v1 0/4] Enable LBR for the guest
From: Andi Kleen @ 2017-09-25 14:59 UTC (permalink / raw)
To: Wei Wang; +Cc: kvm, mst, rkrcmar, linux-kernel, virtualization, mingo, pbonzini
In-Reply-To: <1506314696-4632-1-git-send-email-wei.w.wang@intel.com>
On Mon, Sep 25, 2017 at 12:44:52PM +0800, Wei Wang wrote:
> This patch series enables the Last Branch Recording feature for the
> guest. Instead of trapping each LBR stack MSR access, the MSRs are
> passthroughed to the guest. Those MSRs are switched (i.e. load and
> saved) on VMExit and VMEntry.
>
> Test:
> Try "perf record -b ./test_program" on guest.
I don't see where you expose the PERF capabilities MSR?
That's normally needed for LBR too to report the version
number.
-Andi
^ permalink raw reply
* Re: [PATCH] KVM: s390: Disable CONFIG_S390_GUEST_OLD_TRANSPORT by default
From: Halil Pasic @ 2017-09-25 17:54 UTC (permalink / raw)
To: Thomas Huth, Cornelia Huck; +Cc: linux-s390, kvm, virtualization
In-Reply-To: <1506350729-11311-1-git-send-email-thuth@redhat.com>
On 09/25/2017 04:45 PM, Thomas Huth wrote:
> There is no recent user space application available anymore which still
> supports this old virtio transport, so let's disable this by default.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
I don't have any objections, but there may be something I'm not aware of.
Let's see what Connie says. From my side it's ack.
Via whom is this supposed to go in? Looking at the MAINTAINERS, I would
say Martin or Heiko but I don't see them among the recipients.
Regards,
Halil
> ---
> arch/s390/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 48af970..923bf04 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -930,7 +930,7 @@ config S390_GUEST
> the KVM hypervisor.
>
> config S390_GUEST_OLD_TRANSPORT
> - def_bool y
> + def_bool n
> prompt "Guest support for old s390 virtio transport (DEPRECATED)"
> depends on S390_GUEST
> help
>
^ permalink raw reply
* Re: [PATCH] KVM: s390: Disable CONFIG_S390_GUEST_OLD_TRANSPORT by default
From: Christian Borntraeger @ 2017-09-25 18:37 UTC (permalink / raw)
To: Halil Pasic, Thomas Huth, Cornelia Huck; +Cc: linux-s390, kvm, virtualization
In-Reply-To: <3c2b8ae8-ca2a-7b26-8ebd-14f14c286529@linux.vnet.ibm.com>
On 09/25/2017 07:54 PM, Halil Pasic wrote:
>
>
> On 09/25/2017 04:45 PM, Thomas Huth wrote:
>> There is no recent user space application available anymore which still
>> supports this old virtio transport, so let's disable this by default.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>
> I don't have any objections, but there may be something I'm not aware of.
> Let's see what Connie says. From my side it's ack.
>
> Via whom is this supposed to go in? Looking at the MAINTAINERS, I would
> say Martin or Heiko but I don't see them among the recipients.
FWIW as the original author of that transport
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
I can pick this up for Martins/Heikos tree if you want.
>
> Regards,
> Halil
>
>> ---
>> arch/s390/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index 48af970..923bf04 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -930,7 +930,7 @@ config S390_GUEST
>> the KVM hypervisor.
>>
>> config S390_GUEST_OLD_TRANSPORT
>> - def_bool y
>> + def_bool n
>> prompt "Guest support for old s390 virtio transport (DEPRECATED)"
>> depends on S390_GUEST
>> help
>>
^ permalink raw reply
* Re: [PATCH v5 REPOST 1/6] hw_random: place mutex around read functions and buffers.
From: Dmitry Torokhov @ 2017-09-25 22:00 UTC (permalink / raw)
To: Amos Kong
Cc: Herbert Xu, kvm, Rusty Russell, lkml, virtualization,
linux-crypto, Michael Buesch, Matt Mackall, amit.shah
In-Reply-To: <1418028640-4891-2-git-send-email-akong@redhat.com>
A bit late to a party, but:
On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong <akong@redhat.com> wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
>
> There's currently a big lock around everything, and it means that we
> can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
> while the rng is reading. This is a real problem when the rng is slow,
> or blocked (eg. virtio_rng with qemu's default /dev/random backend)
>
> This doesn't help (it leaves the current lock untouched), just adds a
> lock to protect the read function and the static buffers, in preparation
> for transition.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> ---
...
>
> @@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf,
> goto out_unlock;
> }
>
> + mutex_lock(&reading_mutex);
I think this breaks O_NONBLOCK: we have hwrng core thread that is
constantly pumps underlying rng for data; the thread takes the mutex
and calls rng_get_data() that blocks until RNG responds. This means
that even user specified O_NONBLOCK here we'll be waiting until
[hwrng] thread releases reading_mutex before we can continue.
> if (!data_avail) {
> bytes_read = rng_get_data(current_rng, rng_buffer,
> rng_buffer_size(),
> !(filp->f_flags & O_NONBLOCK));
> if (bytes_read < 0) {
> err = bytes_read;
> - goto out_unlock;
> + goto out_unlock_reading;
> }
> data_avail = bytes_read;
> }
Thanks.
--
Dmitry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox