Re: [PATCH] target-i386: clear guest TSC on reset

[Fernando Luis Vázquez Cao]

On 12/06/2013 11:22 PM, Marcelo Tosatti wrote:

On Fri, Dec 06, 2013 at 05:24:18PM +0900, Fernando Luis Vázquez Cao wrote:

I also wanted to make sure that the initialization that we do
in kvm_arch_vcpu_postcreate on power up and the subsequent
TSC writeback work well together, but I didn't have time to
test it (reading the code, I would say that the TSC generation
counter may end up being increased a few times but the TSCs
would eventually converge).

A basic test should be fine, because the matching code is in use
today.


I applied my two patches to QEMU and I did some testing
with SMP guests (4 VCPUs).

When the host's TSC is stable all the TSC offsets are matched
as expected:

   [ 4544.779699] kvm: VCPU 0 new tsc generation 1, clock 0
   [ 4544.799691] kvm: VCPU 1 matched tsc offset for 0
   [ 4544.835687] kvm: VCPU 2 matched tsc offset for 0
   [ 4544.882229] kvm: VCPU 3 matched tsc offset for 0
   [ 4544.983740] kvm: VCPU 0 matched tsc offset for 0
   [ 4545.015727] kvm: VCPU 1 matched tsc offset for 0
   [ 4545.031762] kvm: VCPU 2 matched tsc offset for 0
   [ 4545.043756] kvm: VCPU 3 matched tsc offset for 0
   [ 4545.382113] kvm: VCPU 0 matched tsc offset for 0
   [ 4545.382138] kvm: VCPU 1 matched tsc offset for 0
   [ 4545.382155] kvm: VCPU 2 matched tsc offset for 0
   [ 4545.382171] kvm: VCPU 3 matched tsc offset for 0

Regarding unstable TSC hosts, I created one by executing

   TSCBSP=`rdmsr -d -p 0 16`; sleep 1s; wrmsr -p 0 16 $TSCBSP

as you suggested. After doing this KVM will adjust the TSC
offsets to make up for the deltas on the host side:

   [ 5232.172074] kvm: VCPU 0 new tsc generation 1, clock 0
   [ 5232.180759] kvm: SMP vm created on host with unstable TSC; guest 
TSC will not be reliable

   [ 5232.204069] kvm: VCPU 1 adjusted tsc offset by 105344
   [ 5232.268070] kvm: VCPU 2 adjusted tsc offset by 210721
   [ 5232.332066] kvm: VCPU 3 adjusted tsc offset by 210708
   [ 5232.444127] kvm: VCPU 0 adjusted tsc offset by 368959
   [ 5232.458448] kvm: VCPU 1 adjusted tsc offset by 47158
   [ 5232.470400] kvm: VCPU 2 adjusted tsc offset by 39352
   [ 5232.482359] kvm: VCPU 3 adjusted tsc offset by 39371
   [ 5232.875343] kvm: VCPU 0 adjusted tsc offset by 1293878
   [ 5232.875371] kvm: VCPU 1 adjusted tsc offset by 121
   [ 5232.875392] kvm: VCPU 2 adjusted tsc offset by 69
   [ 5232.875412] kvm: VCPU 3 adjusted tsc offset by 62

But despite KVM's efforts on the guest side the check in
check_tsc_sync_source() fails and the TSC is marked unstable:

   tsc: Marking TSC unstable due to check_tsc_sync_source failed

By the way, without my patches applied to QEMU the end result
is the same:

   [  266.300068] kvm: VCPU 0 new tsc generation 1, clock 0
   [  266.308746] kvm: SMP vm created on host with unstable TSC; guest 
TSC will not be reliable

   [  266.332067] kvm: VCPU 1 adjusted tsc offset by 105354
   [  266.396065] kvm: VCPU 2 adjusted tsc offset by 210714
   [  266.428273] kvm: VCPU 3 adjusted tsc offset by 106045

In other words, things seem to be working as expected.

- Fernando
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL 4/5] vfio-pci: Add debug config options to disable MSI/X KVM support

[Paolo Bonzini]

Il 06/12/2013 23:36, Alex Williamson ha scritto:
#define VFIO_ALLOW_MMAP 1
#define VFIO_ALLOW_KVM_INTX 1
   +#define VFIO_ALLOW_KVM_MSI 1
   +#define VFIO_ALLOW_KVM_MSIX 1
  
  Why not make these device properties instead?
 Honestly, I don't think they're that useful to the average or even to
 the advanced user.  Each of these disables an acceleration/bypass path
 and gives more logging output when debug is enabled.  Otherwise we don't
 get debugging to see when mmap'd BARs are accessed and we can't tell
 when interrupts happen relative to other accesses.  For instance it was
 pretty obvious to find the Nvidia MSI ACK when seeing a config space
 write immediately following an MSI injection.  Without debugging
 enabled, these just slow things down and I don't know of any cases where
 a device behaves better with these features disabled.

Yeah, behaving better is unlikely.  I was thinking of them as a
debugging features.

As to debug messages, have you considered replacing them with tracepoints?

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: VMX: shadow VM_(ENTRY|EXIT)_CONTROLS vmcs field

[Jan Kiszka]

On 2013-12-09 07:55, Gleb Natapov wrote:
 On Sun, Dec 08, 2013 at 02:00:11PM +0100, Jan Kiszka wrote:
 On 2013-11-27 17:58, Paolo Bonzini wrote:
 Il 25/11/2013 14:37, Gleb Natapov ha scritto:
 VM_(ENTRY|EXIT)_CONTROLS vmcs fields are read/written on each guest
 entry but most times it can be avoided since values do not changes.
 Keep fields copy in memory to avoid unnecessary reads from vmcs.

 Signed-off-by: Gleb Natapov g...@redhat.com
 diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
 index b2fe1c2..29c1c7f 100644
 --- a/arch/x86/kvm/vmx.c
 +++ b/arch/x86/kvm/vmx.c
 @@ -418,6 +418,8 @@ struct vcpu_vmx {
u64   msr_host_kernel_gs_base;
u64   msr_guest_kernel_gs_base;
  #endif
 +  u32 vm_entry_controls_shadow;
 +  u32 vm_exit_controls_shadow;
/*
 * loaded_vmcs points to the VMCS currently used in this vcpu. For a
 * non-nested (L1) guest, it always points to vmcs01. For a nested
 @@ -1326,6 +1328,62 @@ static void vmcs_set_bits(unsigned long field, u32 
 mask)
vmcs_writel(field, vmcs_readl(field) | mask);
  }
  
 +static inline void vm_entry_controls_init(struct vcpu_vmx *vmx, u32 val)
 +{
 +  vmcs_write32(VM_ENTRY_CONTROLS, val);
 +  vmx-vm_entry_controls_shadow = val;
 +}
 +
 +static inline void vm_entry_controls_set(struct vcpu_vmx *vmx, u32 val)
 +{
 +  if (vmx-vm_entry_controls_shadow != val)
 +  vm_entry_controls_init(vmx, val);
 +}
 +
 +static inline u32 vm_entry_controls_get(struct vcpu_vmx *vmx)
 +{
 +  return vmx-vm_entry_controls_shadow;
 +}
 +
 +
 +static inline void vm_entry_controls_setbit(struct vcpu_vmx *vmx, u32 val)
 +{
 +  vm_entry_controls_set(vmx, vm_entry_controls_get(vmx) | val);
 +}
 +
 +static inline void vm_entry_controls_clearbit(struct vcpu_vmx *vmx, u32 
 val)
 +{
 +  vm_entry_controls_set(vmx, vm_entry_controls_get(vmx)  ~val);
 +}
 +
 +static inline void vm_exit_controls_init(struct vcpu_vmx *vmx, u32 val)
 +{
 +  vmcs_write32(VM_EXIT_CONTROLS, val);
 +  vmx-vm_exit_controls_shadow = val;
 +}
 +
 +static inline void vm_exit_controls_set(struct vcpu_vmx *vmx, u32 val)
 +{
 +  if (vmx-vm_exit_controls_shadow != val)
 +  vm_exit_controls_init(vmx, val);
 +}
 +
 +static inline u32 vm_exit_controls_get(struct vcpu_vmx *vmx)
 +{
 +  return vmx-vm_exit_controls_shadow;
 +}
 +
 +
 +static inline void vm_exit_controls_setbit(struct vcpu_vmx *vmx, u32 val)
 +{
 +  vm_exit_controls_set(vmx, vm_exit_controls_get(vmx) | val);
 +}
 +
 +static inline void vm_exit_controls_clearbit(struct vcpu_vmx *vmx, u32 
 val)
 +{
 +  vm_exit_controls_set(vmx, vm_exit_controls_get(vmx)  ~val);
 +}
 +
  static void vmx_segment_cache_clear(struct vcpu_vmx *vmx)
  {
vmx-segment_cache.bitmask = 0;
 @@ -1410,11 +1468,11 @@ static void update_exception_bitmap(struct 
 kvm_vcpu *vcpu)
vmcs_write32(EXCEPTION_BITMAP, eb);
  }
  
 -static void clear_atomic_switch_msr_special(unsigned long entry,
 -  unsigned long exit)
 +static void clear_atomic_switch_msr_special(struct vcpu_vmx *vmx,
 +  unsigned long entry, unsigned long exit)
  {
 -  vmcs_clear_bits(VM_ENTRY_CONTROLS, entry);
 -  vmcs_clear_bits(VM_EXIT_CONTROLS, exit);
 +  vm_entry_controls_clearbit(vmx, entry);
 +  vm_exit_controls_clearbit(vmx, exit);
  }
  
  static void clear_atomic_switch_msr(struct vcpu_vmx *vmx, unsigned msr)
 @@ -1425,14 +1483,15 @@ static void clear_atomic_switch_msr(struct 
 vcpu_vmx *vmx, unsigned msr)
switch (msr) {
case MSR_EFER:
if (cpu_has_load_ia32_efer) {
 -  clear_atomic_switch_msr_special(VM_ENTRY_LOAD_IA32_EFER,
 +  clear_atomic_switch_msr_special(vmx,
 +  VM_ENTRY_LOAD_IA32_EFER,
VM_EXIT_LOAD_IA32_EFER);
return;
}
break;
case MSR_CORE_PERF_GLOBAL_CTRL:
if (cpu_has_load_perf_global_ctrl) {
 -  clear_atomic_switch_msr_special(
 +  clear_atomic_switch_msr_special(vmx,
VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL,
VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL);
return;
 @@ -1453,14 +1512,15 @@ static void clear_atomic_switch_msr(struct 
 vcpu_vmx *vmx, unsigned msr)
vmcs_write32(VM_EXIT_MSR_LOAD_COUNT, m-nr);
  }
  
 -static void add_atomic_switch_msr_special(unsigned long entry,
 -  unsigned long exit, unsigned long guest_val_vmcs,
 -  unsigned long host_val_vmcs, u64 guest_val, u64 host_val)
 +static void add_atomic_switch_msr_special(struct vcpu_vmx *vmx,
 +  unsigned long entry, unsigned long exit,
 +  unsigned long guest_val_vmcs, unsigned long host_val_vmcs,
 +  u64 guest_val, u64 host_val)
  {
vmcs_write64(guest_val_vmcs, guest_val);
vmcs_write64(host_val_vmcs, host_val);
 -  vmcs_set_bits(VM_ENTRY_CONTROLS, entry);
 -  vmcs_set_bits(VM_EXIT_CONTROLS, exit);
 +  

Re: [RFC PATCH v3 1/2] add support for Hyper-V reference time counter

[Paolo Bonzini]

Il 08/12/2013 12:33, Vadim Rozenfeld ha scritto:
 Signed-off: Peter Lieven p...@dlh.net
 Signed-off: Gleb Natapov g...@redhat.com
 Signed-off: Vadim Rozenfeld vroze...@redhat.com
 
 v1 - v2
 1. mark TSC page dirty as suggested by 
 Eric Northup digitale...@google.com and Gleb
 2. disable local irq when calling get_kernel_ns, 
 as it was done by Peter Lieven p...@dlhnet.de
 3. move check for TSC page enable from second patch
 to this one.
 
 ---
  arch/x86/include/asm/kvm_host.h|  2 ++
  arch/x86/include/uapi/asm/hyperv.h | 13 +
  arch/x86/kvm/x86.c | 39 
 +-
  include/uapi/linux/kvm.h   |  1 +
  4 files changed, 54 insertions(+), 1 deletion(-)
 
 diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
 index ae5d783..2fd0753 100644
 --- a/arch/x86/include/asm/kvm_host.h
 +++ b/arch/x86/include/asm/kvm_host.h
 @@ -605,6 +605,8 @@ struct kvm_arch {
   /* fields used by HYPER-V emulation */
   u64 hv_guest_os_id;
   u64 hv_hypercall;
 + u64 hv_ref_count;
 + u64 hv_tsc_page;
  
   #ifdef CONFIG_KVM_MMU_AUDIT
   int audit_point;
 diff --git a/arch/x86/include/uapi/asm/hyperv.h 
 b/arch/x86/include/uapi/asm/hyperv.h
 index b8f1c01..462efe7 100644
 --- a/arch/x86/include/uapi/asm/hyperv.h
 +++ b/arch/x86/include/uapi/asm/hyperv.h
 @@ -28,6 +28,9 @@
  /* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
  #define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE  (1  1)
  
 +/* A partition's reference time stamp counter (TSC) page */
 +#define HV_X64_MSR_REFERENCE_TSC 0x4021
 +
  /*
   * There is a single feature flag that signifies the presence of the MSR
   * that can be used to retrieve both the local APIC Timer frequency as
 @@ -198,6 +201,9 @@
  #define HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_MASK \
   (~((1ull  HV_X64_MSR_APIC_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
  
 +#define HV_X64_MSR_TSC_REFERENCE_ENABLE  0x0001
 +#define HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT   12
 +
  #define HV_PROCESSOR_POWER_STATE_C0  0
  #define HV_PROCESSOR_POWER_STATE_C1  1
  #define HV_PROCESSOR_POWER_STATE_C2  2
 @@ -210,4 +216,11 @@
  #define HV_STATUS_INVALID_ALIGNMENT  4
  #define HV_STATUS_INSUFFICIENT_BUFFERS   19
  
 +typedef struct _HV_REFERENCE_TSC_PAGE {
 + __u32 tsc_sequence;
 + __u32 res1;
 + __u64 tsc_scale;
 + __s64 tsc_offset;
 +} HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
 +
  #endif
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 21ef1ba..5e4e495a 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -840,7 +840,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
  static u32 msrs_to_save[] = {
   MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
   MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
 - HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
 + HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL, HV_X64_MSR_TIME_REF_COUNT,

You need to bump KVM_SAVE_MSRS_BEGIN.

   HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
   MSR_KVM_PV_EOI_EN,
   MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
 @@ -1826,6 +1826,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
   switch (msr) {
   case HV_X64_MSR_GUEST_OS_ID:
   case HV_X64_MSR_HYPERCALL:
 + case HV_X64_MSR_REFERENCE_TSC:
 + case HV_X64_MSR_TIME_REF_COUNT:
   r = true;
   break;
   }
 @@ -1865,6 +1867,29 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, 
 u32 msr, u64 data)
   if (__copy_to_user((void __user *)addr, instructions, 4))
   return 1;
   kvm-arch.hv_hypercall = data;
 + local_irq_disable();
 + kvm-arch.hv_ref_count = get_kernel_ns() + 
 kvm-arch.kvmclock_offset;
 + local_irq_enable();

Please add a patch that moves these four lines from KVM_GET_CLOCK and
KVM_SET_CLOCK

local_irq_disable();
now_ns = get_kernel_ns();
delta = user_ns.clock - now_ns;
local_irq_enable();
kvm-arch.kvmclock_offset = delta;
kvm_gen_update_masterclock(kvm);

local_irq_disable();
now_ns = get_kernel_ns();
user_ns.clock = kvm-arch.kvmclock_offset + now_ns;
local_irq_enable();

For example u64 kvm_get_clock_ns(struct kvm *) and void
kvm_set_clock_ns(struct kvm *, u64).  You can then use the
kvm_get_clock_ns function in this patch.

 + break;
 + }
 + case HV_X64_MSR_REFERENCE_TSC: {
 + u64 gfn;
 + unsigned long addr;
 + HV_REFERENCE_TSC_PAGE tsc_ref;
 + tsc_ref.tsc_sequence = 0;

Please zero it with memset.  You're leaking values from the stack to the
guest.

 + if (!(data  HV_X64_MSR_TSC_REFERENCE_ENABLE)) {
 +  

Re: [RFC PATCH v3 2/2] add support for Hyper-V partition reference time enlightenment

[Paolo Bonzini]

Il 08/12/2013 12:33, Vadim Rozenfeld ha scritto:
 + tsc_ref.tsc_sequence =
 + boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 1 : 0;
 + tsc_ref.tsc_scale =
 + ((1LL  32) / vcpu-arch.virtual_tsc_khz)  32;
 + tsc_ref.tsc_offset = 0;
   if (__copy_to_user((void __user *)addr, tsc_ref, 
 sizeof(tsc_ref)))
   return 1;
   mark_page_dirty(kvm, gfn);
   kvm-arch.hv_tsc_page = data;
 + kvm-arch.hv_ref_count = 0;
   break;
   }
   default:
 @@ -3879,6 +3884,19 @@ long kvm_arch_vm_ioctl(struct file *filp,
   local_irq_enable();
   kvm-arch.kvmclock_offset = delta;
   kvm_gen_update_masterclock(kvm);
 +
 + if (kvm-arch.hv_tsc_page  HV_X64_MSR_TSC_REFERENCE_ENABLE) {
 + HV_REFERENCE_TSC_PAGE* tsc_ref;
 + u64 curr_time;
 + tsc_ref = (HV_REFERENCE_TSC_PAGE*)gfn_to_hva(kvm, 
 + kvm-arch.hv_tsc_page  
 HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
 + tsc_ref-tsc_sequence =
 + boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 
 tsc_ref-tsc_sequence + 1 : 0;
 + tsc_ref-tsc_scale = ((1LL  32) / 
 __get_cpu_var(cpu_tsc_khz))  32;

Why shouldn't this be vcpu-arch.virtual_tsc_khz?

 + curr_time = (((tsc_ref-tsc_scale  32) * 
 native_read_tsc())  32) + 
 + tsc_ref-tsc_offset;
 + tsc_ref-tsc_offset = kvm-arch.hv_ref_time - curr_time;
 + }

The difference in setting tsc_ref-tsc_scale is the only important
change between the two occurrences.  If you can avoid that difference
and you move this to a separate function, you can reuse that new
function in set_msr_hyperv_pw as well.

Also, kvm_set_tsc_khz should recompute the reference page's values as
well, so you'd have three uses.

Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Problem after update windows VirtIO drivers

[Carlos Rodrigues]

Hello,

After update the VirtIO drivers for Windows Server 2008 R2 64-bit, when
i reboot virtual machine, the windows OS get stuck on loading bar.

The VirtIO drivers is the latest stable that i made the download from
http://alt.fedoraproject.org/pub/alt/virtio-win/stable/virtio-win-0.1-74.iso

And i use version 1.2.1 of kvm and the OS of host is Centos 5.8.

I try to install a fresh and clean version same Windows and same drivers
and get the same problem. With virtio-win-0.1-52 version of drivers, the
windows server works properly.

I will use the oldest stable version of drivers, but anyone knows some
issue with latest drivers?

Regards,

-- 
Carlos Rodrigues 

Engenheiro de Software Sénior

Eurotux Informática, S.A. | www.eurotux.com

(t) +351 253 680 300 (m) +351 911 926 110



--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] KVM: PPC: Add devname:kvm aliases for modules

[Alexander Graf]

Systems that support automatic loading of kernel modules through
device aliases should try and automatically load kvm when /dev/kvm
gets opened.

Add code to support that magic for all PPC kvm targets, even the
ones that don't support modules yet.

Signed-off-by: Alexander Graf ag...@suse.de
---
 arch/powerpc/kvm/44x.c   | 3 +++
 arch/powerpc/kvm/book3s.c| 7 +++
 arch/powerpc/kvm/book3s_hv.c | 3 +++
 arch/powerpc/kvm/book3s_pr.c | 3 +++
 arch/powerpc/kvm/e500.c  | 3 +++
 arch/powerpc/kvm/e500mc.c| 3 +++
 6 files changed, 22 insertions(+)

diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 93221e8..fea2a11 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -231,3 +231,6 @@ static void __exit kvmppc_44x_exit(void)
 
 module_init(kvmppc_44x_init);
 module_exit(kvmppc_44x_exit);
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 8912608..5892599 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -879,3 +879,10 @@ static void kvmppc_book3s_exit(void)
 
 module_init(kvmppc_book3s_init);
 module_exit(kvmppc_book3s_exit);
+
+/* On 32bit this is our one and only kernel module */
+#ifdef CONFIG_KVM_BOOK3S_32
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
+#endif
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 93203bb..86d1f4d 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2215,4 +2215,7 @@ static void kvmppc_book3s_exit_hv(void)
 
 module_init(kvmppc_book3s_init_hv);
 module_exit(kvmppc_book3s_exit_hv);
+#include linux/miscdevice.h
 MODULE_LICENSE(GPL);
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index fe14ca3..b97e21e 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1583,5 +1583,8 @@ void kvmppc_book3s_exit_pr(void)
 module_init(kvmppc_book3s_init_pr);
 module_exit(kvmppc_book3s_exit_pr);
 
+#include linux/miscdevice.h
 MODULE_LICENSE(GPL);
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
 #endif
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index 497b142..080dbe0 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -573,3 +573,6 @@ static void __exit kvmppc_e500_exit(void)
 
 module_init(kvmppc_e500_init);
 module_exit(kvmppc_e500_exit);
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 4132cd2..352c629 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -391,3 +391,6 @@ static void __exit kvmppc_e500mc_exit(void)
 
 module_init(kvmppc_e500mc_init);
 module_exit(kvmppc_e500mc_exit);
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/9] ARM: KVM: Allow creating the VGIC after VCPUs

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:
Rework the VGIC initialization slightly to allow initialization of 
the

vgic cpu-specific state even if the irqchip (the VGIC) hasn't been
created by user space yet.  This is safe, because the vgic data
structures are already allocated when the CPU is allocated if VGIC
support is compiled into the kernel.  Further, the init process does 
not

depend on any other information and the sacrifice is a slight
performance degradation for creating VMs in the no-VGIC case.

The reason is that the new device control API doesn't mandate 
creating
the VGIC before creating the VCPU and it is unreasonable to require 
user

space to create the VGIC before creating the VCPUs.

At the same time move the irqchip_in_kernel check out of
kvm_vcpu_first_run_init and into the init function to make the 
per-vcpu

and global init functions symmetric and add comments on the exported
functions making it a bit easier to understand the init flow by only
looking at vgic.c.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org


Looks good to me:

Acked-by: Marc Zyngier marc.zyng...@arm.com

M.


---
 arch/arm/kvm/arm.c  |7 ---
 virt/kvm/arm/vgic.c |   22 +++---
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 2bc2ec4..e80b6a1 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -464,6 +464,8 @@ static void update_vttbr(struct kvm *kvm)

 static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
 {
+   int ret;
+
if (likely(vcpu-arch.has_run_once))
return 0;

@@ -473,9 +475,8 @@ static int kvm_vcpu_first_run_init(struct 
kvm_vcpu *vcpu)

 * Initialize the VGIC before running a vcpu the first time on
 * this VM.
 */
-   if (irqchip_in_kernel(vcpu-kvm) 
-   unlikely(!vgic_initialized(vcpu-kvm))) {
-   int ret = kvm_vgic_init(vcpu-kvm);
+   if (unlikely(!vgic_initialized(vcpu-kvm))) {
+   ret = kvm_vgic_init(vcpu-kvm);
if (ret)
return ret;
}
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 81e9481..5e9df47 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1243,15 +1243,19 @@ static irqreturn_t
vgic_maintenance_handler(int irq, void *data)
return IRQ_HANDLED;
 }

+/**
+ * kvm_vgic_vcpu_init - Initialize per-vcpu VGIC state
+ * @vcpu: pointer to the vcpu struct
+ *
+ * Initialize the vgic_cpu struct and vgic_dist struct fields 
pertaining to

+ * this vcpu and enable the VGIC for this VCPU
+ */
 int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
 {
struct vgic_cpu *vgic_cpu = vcpu-arch.vgic_cpu;
struct vgic_dist *dist = vcpu-kvm-arch.vgic;
int i;

-   if (!irqchip_in_kernel(vcpu-kvm))
-   return 0;
-
if (vcpu-vcpu_id = VGIC_MAX_CPUS)
return -EBUSY;

@@ -1383,10 +1387,22 @@ out:
return ret;
 }

+/**
+ * kvm_vgic_init - Initialize global VGIC state before running any 
VCPUs

+ * @kvm: pointer to the kvm struct
+ *
+ * Map the virtual CPU interface into the VM before running any 
VCPUs.  We
+ * can't do this at creation time, because user space must first set 
the
+ * virtual CPU interface address in the guest physical address 
space.  Also

+ * initialize the ITARGETSRn regs to 0 on the emulated distributor.
+ */
 int kvm_vgic_init(struct kvm *kvm)
 {
int ret = 0, i;

+   if (!irqchip_in_kernel(kvm))
+   return 0;
+
mutex_lock(kvm-lock);

if (vgic_initialized(kvm))


--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: PPC: fix couple of memory leaks in MPIC/XICS devices

[Alexander Graf]

On 04.09.2013, at 14:16, Paul Mackerras pau...@samba.org wrote:

 On Sun, Sep 01, 2013 at 03:53:46PM +0300, Gleb Natapov wrote:
 XICS failed to free xics structure on error path. MPIC destroy handler
 forgot to delete kvm_device structure.
 
 Signed-off-by: Gleb Natapov g...@redhat.com
 
 Acked-by: Paul Mackerras pau...@samba.org

Thanks, applied to kvm-ppc-queue.


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/9] KVM: arm-vgic: Support KVM_CREATE_DEVICE for VGIC

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:

Support creating the ARM VGIC device through the KVM_CREATE_DEVICE
ioctl, which can then later be leveraged to use the
KVM_{GET/SET}_DEVICE_ATTR, which is useful both for setting addresses 
in

a more generic API than the ARM-specific one and is useful for
save/restore of VGIC state.

Adds KVM_CAP_DEVICE_CTRL to ARM capabilities.

Note that we change the check for creating a VGIC from bailing out if
any VCPUs were created, to bailing out if any VCPUs were ever run.  
This

is an important distinction that shouldn't break anything, but allows
creating the VGIC after the VCPUs have been created.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org

Changelog[v3]:
 - Prevent race in kvm_vgic_create by trying to take all the vcpu
   locks before creating the vgic.

Changelog[v2]:
 - None
---
 Documentation/virtual/kvm/devices/arm-vgic.txt |   10 
 arch/arm/kvm/arm.c |1 +
 include/linux/kvm_host.h   |1 +
 include/uapi/linux/kvm.h   |1 +
 virt/kvm/arm/vgic.c|   58
+++-
 virt/kvm/kvm_main.c|6 ++-
 6 files changed, 74 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/arm-vgic.txt

diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt
b/Documentation/virtual/kvm/devices/arm-vgic.txt
new file mode 100644
index 000..38f27f7
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
@@ -0,0 +1,10 @@
+ARM Virtual Generic Interrupt Controller (VGIC)
+===
+
+Device types supported:
+  KVM_DEV_TYPE_ARM_VGIC_V2 ARM Generic Interrupt Controller v2.0
+
+Only one VGIC instance may be instantiated through either this API 
or the

+legacy KVM_CREATE_IRQCHIP api.  The created VGIC will act as the VM
interrupt
+controller, requiring emulated user-space devices to inject
interrupts to the
+VGIC instead of directly to CPUs.
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index e80b6a1..984908d 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -190,6 +190,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_IRQCHIP:
r = vgic_present;
break;
+   case KVM_CAP_DEVICE_CTRL:
case KVM_CAP_USER_MEMORY:
case KVM_CAP_SYNC_MMU:
case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 9523d2a..e68d9db 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1076,6 +1076,7 @@ struct kvm_device *kvm_device_from_filp(struct
file *filp);
 extern struct kvm_device_ops kvm_mpic_ops;
 extern struct kvm_device_ops kvm_xics_ops;
 extern struct kvm_device_ops kvm_vfio_ops;
+extern struct kvm_device_ops kvm_arm_vgic_ops;


Can we rename this to kvm_arm_vgic_v2_ops in order to be consistent 
with KVM_DEV_TYPE_ARM_VGIC_V2?




 #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT

diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 902f124..b647c29 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -853,6 +853,7 @@ struct kvm_device_attr {
 #define  KVM_DEV_VFIO_GROUP1
 #define   KVM_DEV_VFIO_GROUP_ADD   1
 #define   KVM_DEV_VFIO_GROUP_DEL   2
+#define KVM_DEV_TYPE_ARM_VGIC_V2   5

 /*
  * ioctls for VM fds
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 5e9df47..e3fbb5e 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1433,20 +1433,40 @@ out:

 int kvm_vgic_create(struct kvm *kvm)
 {
-   int ret = 0;
+   int i, vcpu_lock_idx = -1, ret = 0;
+   struct kvm_vcpu *vcpu;

mutex_lock(kvm-lock);

-   if (atomic_read(kvm-online_vcpus) || kvm-arch.vgic.vctrl_base) {
+   if (kvm-arch.vgic.vctrl_base) {
ret = -EEXIST;
goto out;
}

+   kvm_for_each_vcpu(i, vcpu, kvm) {
+   if (!mutex_trylock(vcpu-mutex))
+   goto out_unlock;
+   vcpu_lock_idx = i;
+   }


I think this deserves a comment explaining that vcpu-mutex is taken by 
vcpu_load...



+   kvm_for_each_vcpu(i, vcpu, kvm) {
+   if (vcpu-arch.has_run_once) {
+   ret = -EBUSY;
+   goto out_unlock;
+   }
+   }
+
spin_lock_init(kvm-arch.vgic.lock);
kvm-arch.vgic.vctrl_base = vgic_vctrl_base;
kvm-arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
kvm-arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;

+out_unlock:
+   for (; vcpu_lock_idx = 0; vcpu_lock_idx--) {
+   vcpu = kvm_get_vcpu(kvm, vcpu_lock_idx);
+   mutex_unlock(vcpu-mutex);
+   }
+
 out:
mutex_unlock(kvm-lock);
return ret;
@@ -1510,3 +1530,37 @@ int kvm_vgic_set_addr(struct kvm *kvm,
unsigned long type, u64 

Re: [PATCH 0/2 v3] kvm/powerpc: hypercall related cleanup

[Alexander Graf]

On 08.10.2013, at 06:02, Bharat Bhushan r65...@freescale.com wrote:

 From: Bharat Bhushan bharat.bhus...@freescale.com
 
 This patchset does some code cleanup around kvm-hypercall.

Thanks, applied to kvm-ppc-queue.


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/9] KVM: arm-vgic: Set base addr through device API

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:
Support setting the distributor and cpu interface base addresses in 
the

VM physical address space through the KVM_{SET,GET}_DEVICE_ATTR API
in addition to the ARM specific API.

This has the added benefit of being able to share more code in user
space and do things in a uniform manner.

Also deprecate the older API at the same time, but backwards
compatibility will be maintained.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org

Changelog[v3]:
 - Spelling nits
 - Fix error codes from vgic_get_attr

Changelog[v2]:
 - None
---
 Documentation/virtual/kvm/api.txt  |7 +-
 Documentation/virtual/kvm/devices/arm-vgic.txt |   11 +++
 arch/arm/include/uapi/asm/kvm.h|8 +++
 arch/arm/kvm/arm.c |2 +-
 include/kvm/arm_vgic.h |2 +-
 virt/kvm/arm/vgic.c|   89

 6 files changed, 104 insertions(+), 15 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index a30035d..867112f 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2391,7 +2391,8 @@ struct kvm_reg_list {
 This ioctl returns the guest registers that are supported for the
 KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.

-4.85 KVM_ARM_SET_DEVICE_ADDR
+
+4.85 KVM_ARM_SET_DEVICE_ADDR (deprecated)

 Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
 Architectures: arm, arm64
@@ -2429,6 +2430,10 @@ must be called after calling
KVM_CREATE_IRQCHIP, but before calling
 KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of 
the

 base addresses will return -EEXIST.

+Note, this IOCTL is deprecated and the more flexible 
SET/GET_DEVICE_ATTR API

+should be used instead.
+
+
 4.86 KVM_PPC_RTAS_DEFINE_TOKEN

 Capability: KVM_CAP_PPC_RTAS
diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt
b/Documentation/virtual/kvm/devices/arm-vgic.txt
index 38f27f7..c9febb2 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
@@ -8,3 +8,14 @@ Only one VGIC instance may be instantiated through
either this API or the
 legacy KVM_CREATE_IRQCHIP api.  The created VGIC will act as the VM
interrupt
 controller, requiring emulated user-space devices to inject
interrupts to the
 VGIC instead of directly to CPUs.
+
+Groups:
+  KVM_DEV_ARM_VGIC_GRP_ADDR
+  Attributes:
+KVM_VGIC_V2_ADDR_TYPE_DIST (rw, 64-bit)
+  Base address in the guest physical address space of the GIC
distributor
+  register mappings.
+
+KVM_VGIC_V2_ADDR_TYPE_CPU (rw, 64-bit)
+  Base address in the guest physical address space of the GIC
virtual cpu
+  interface register mappings.
diff --git a/arch/arm/include/uapi/asm/kvm.h
b/arch/arm/include/uapi/asm/kvm.h
index bd3b2f7..26a375c 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -159,6 +159,14 @@ struct kvm_arch_memory_slot {
 #define KVM_REG_ARM_VFP_FPINST 0x1009
 #define KVM_REG_ARM_VFP_FPINST20x100A

+/* Device Control API: ARM VGIC */
+#define KVM_DEV_ARM_VGIC_GRP_ADDR  0
+#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
+#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS  2
+#define   KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
+#define   KVM_DEV_ARM_VGIC_CPUID_MASK  (0xffULL 
KVM_DEV_ARM_VGIC_CPUID_SHIFT)
+#define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT0
+#define   KVM_DEV_ARM_VGIC_OFFSET_MASK (0xULL 
KVM_DEV_ARM_VGIC_OFFSET_SHIFT)


What are these #defines for? I suppose they are used in a subsequent 
patch? If so, can we please move them?


M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/9] irqchip: arm-gic: Define additional MMIO offsets and masks

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:
Define CPU interface offsets for the GICC_ABPR, GICC_APR, and 
GICC_IIDR
registers.  Define distributor registers for the GICD_SPENDSGIR and 
the
GICD_CPENDSGIR.  KVM/ARM needs to know about these definitions to 
fully

support save/restore of the VGIC.

Also define some masks and shifts for the various GICH_VMCR fields.

Cc: Thomas Gleixner t...@linutronix.de
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org


Acked-by: Marc Zyngier marc.zyng...@arm.com


---
 include/linux/irqchip/arm-gic.h |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/irqchip/arm-gic.h
b/include/linux/irqchip/arm-gic.h
index 0e5d9ec..28b28fc 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -17,6 +17,9 @@
 #define GIC_CPU_EOI0x10
 #define GIC_CPU_RUNNINGPRI 0x14
 #define GIC_CPU_HIGHPRI0x18
+#define GIC_CPU_ALIAS_BINPOINT 0x1c
+#define GIC_CPU_ACTIVEPRIO 0xd0
+#define GIC_CPU_IDENT  0xfc

 #define GIC_DIST_CTRL  0x000
 #define GIC_DIST_CTR   0x004
@@ -31,6 +34,8 @@
 #define GIC_DIST_TARGET0x800
 #define GIC_DIST_CONFIG0xc00
 #define GIC_DIST_SOFTINT   0xf00
+#define GIC_DIST_SGI_CLEAR 0xf10
+#define GIC_DIST_SGI_SET   0xf20

 #define GICH_HCR   0x0
 #define GICH_VTR   0x4
@@ -54,6 +59,15 @@
 #define GICH_LR_ACTIVE_BIT (1  29)
 #define GICH_LR_EOI(1  19)

+#define GICH_VMCR_CTRL_SHIFT   0
+#define GICH_VMCR_CTRL_MASK(0x21f  GICH_VMCR_CTRL_SHIFT)
+#define GICH_VMCR_PRIMASK_SHIFT27
+#define GICH_VMCR_PRIMASK_MASK (0x1f  GICH_VMCR_PRIMASK_SHIFT)
+#define GICH_VMCR_BINPOINT_SHIFT   21
+#define GICH_VMCR_BINPOINT_MASK(0x7  
GICH_VMCR_BINPOINT_SHIFT)
+#define GICH_VMCR_ALIAS_BINPOINT_SHIFT 18
+#define GICH_VMCR_ALIAS_BINPOINT_MASK  (0x7 
GICH_VMCR_ALIAS_BINPOINT_SHIFT)
+
 #define GICH_MISR_EOI  (1  0)
 #define GICH_MISR_U(1  1)


--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/9] KVM: arm-vgic: Make vgic mmio functions more generic

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:
Rename the vgic_ranges array to vgic_dist_ranges to be more specific 
and

to prepare for handling CPU interface register access as well (for
save/restore of VGIC state).

Pass offset from distributor or interface MMIO base to
find_matching_range function instead of the physical address of the
access in the VM memory map.  This allows other callers unaware of 
the

VM specifics, but with generic VGIC knowledge to reuse the function.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org


Acked-by: Marc Zyngier marc.zyng...@arm.com


---
 virt/kvm/arm/vgic.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index edca754..9b9fa20 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -602,7 +602,7 @@ struct mmio_range {
phys_addr_t offset);
 };

-static const struct mmio_range vgic_ranges[] = {
+static const struct mmio_range vgic_dist_ranges[] = {
{
.base   = GIC_DIST_CTRL,
.len= 12,
@@ -669,14 +669,13 @@ static const struct mmio_range vgic_ranges[] = 
{

 static const
 struct mmio_range *find_matching_range(const struct mmio_range 
*ranges,

   struct kvm_exit_mmio *mmio,
-  phys_addr_t base)
+  phys_addr_t offset)
 {
const struct mmio_range *r = ranges;
-   phys_addr_t addr = mmio-phys_addr - base;

while (r-len) {
-   if (addr = r-base 
-   (addr + mmio-len) = (r-base + r-len))
+   if (offset = r-base 
+   (offset + mmio-len) = (r-base + r-len))
return r;
r++;
}
@@ -713,7 +712,8 @@ bool vgic_handle_mmio(struct kvm_vcpu *vcpu,
struct kvm_run *run,
return true;
}

-   range = find_matching_range(vgic_ranges, mmio, base);
+   offset = mmio-phys_addr - base;
+   range = find_matching_range(vgic_dist_ranges, mmio, offset);
if (unlikely(!range || !range-handle_mmio)) {
pr_warn(Unhandled access %d %08llx %d\n,
mmio-is_write, mmio-phys_addr, mmio-len);


--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] KVM: PPC: Unify FP/VMX/VSX state handling between KVM and main kernel

[Alexander Graf]

On 15.10.2013, at 11:43, Paul Mackerras pau...@samba.org wrote:

 This series makes use of the new thread_fp_state and thread_vr_state
 structures to unify the way that floating-point and vector state is
 handled.  With both KVM and the main kernel using the same structures
 to store this state for various contexts, we can reduce the amount of
 code for loading and storing this state and also eliminate some extra
 copies.  Overall, this series removes a net 240 lines of code.
 
 This series also provides the foundation for implementing support for
 POWER8 transactional memory in KVM.
 
 These patches are against the merge of Ben Herrenschmidt's for-kvm
 branch and Alex Graf's kvm-ppc-queue branch.

Thanks, applied all to kvm-ppc-queue.


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/9] KVM: arm-vgic: Add vgic reg access from dev attr

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:

Add infrastructure to handle distributor and cpu interface register
accesses through the KVM_{GET/SET}_DEVICE_ATTR interface by adding 
the
KVM_DEV_ARM_VGIC_GRP_DIST_REGS and KVM_DEV_ARM_VGIC_GRP_CPU_REGS 
groups

and defining the semantics of the attr field to be the MMIO offset as
specified in the GICv2 specs.

Set the cpu field (physical CPU index) on the vcpu struct to -1 in
kvm_arch_vcpu_put so we have a method to check if the vcpu is running 
or

not without having to grab the VCPU mutexes.

Missing register accesses or other changes in individual register 
access

functions to support save/restore of the VGIC state is added in
subsequent patches.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org

Changelog[v3]:
 - Spelling and formatting nits
 - Fill in the phys_addr in kvm_exit_mmio
 - Put kvm_exit_mmio matching struct on stack
 - Change if-else-if to switch statement in vgic_attr_regs_access
 - Properly synchronize access to the VGIC with all VCPUs and the VM
   structure, ensuring no VCPUs are running while user space is
   accessing VGIC registers.


I have some doubts about this last point, see below.


Changelog[v2]:
 - Added implementation specific format for the GICC_APRn registers.
---
 Documentation/virtual/kvm/devices/arm-vgic.txt |   52 
 arch/arm/kvm/arm.c |1 +
 virt/kvm/arm/vgic.c|  169

 3 files changed, 222 insertions(+)

diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt
b/Documentation/virtual/kvm/devices/arm-vgic.txt
index c9febb2..7f4e91b 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
@@ -19,3 +19,55 @@ Groups:
 KVM_VGIC_V2_ADDR_TYPE_CPU (rw, 64-bit)
   Base address in the guest physical address space of the GIC
virtual cpu
   interface register mappings.
+
+  KVM_DEV_ARM_VGIC_GRP_DIST_REGS
+  Attributes:
+The attr field of kvm_device_attr encodes two values:
+bits: | 63     40 | 39 ..  32  |  31   0 |
+values:   |reserved   |   cpu id   |  offset |
+
+All distributor regs are (rw, 32-bit)
+
+The offset is relative to the Distributor base address as
defined in the
+GICv2 specs.  Getting or setting such a register has the same 
effect as
+reading or writing the register on the actual hardware from the 
cpu
+specified with cpu id field.  Note that most distributor fields 
are not

+banked, but return the same value regardless of the cpu id used
to access
+the register.
+  Limitations:
+- Priorities are not implemented, and registers are RAZ/WI
+  Errors:
+-ENODEV: Getting or setting this register is not yet supported
+-EBUSY: One or more VCPUs are running
+
+  KVM_DEV_ARM_VGIC_GRP_CPU_REGS
+  Attributes:
+The attr field of kvm_device_attr encodes two values:
+bits: | 63     40 | 39 ..  32  |  31   0 |
+values:   |reserved   |   cpu id   |  offset |
+
+All CPU interface regs are (rw, 32-bit)
+
+The offset specifies the offset from the CPU interface base 
address as
+defined in the GICv2 specs.  Getting or setting such a register 
has the
+same effect as reading or writing the register on the actual 
hardware.

+
+The Active Priorities Registers APRn are implementation defined,
so we set a
+fixed format for our implementation that fits with the model of 
a GICv2
+implementation without the security extensions which we present 
to the

+guest.  This interface always exposes four register APR[0-3]
describing the
+maximum possible 128 preemption levels.  The semantics of the 
register
+indicate if any interrupts in a given preemption level are in 
the active

+state by setting the corresponding bit.
+
+Thus, preemption level X has one or more active interrupts if
and only if:
+
+  APRn[X mod 32] == 0b1,  where n = X / 32
+
+Bits for undefined preemption levels are RAZ/WI.
+
+  Limitations:
+- Priorities are not implemented, and registers are RAZ/WI
+  Errors:
+-ENODEV: Getting or setting this register is not yet supported
+-EBUSY: One or more VCPUs are running
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index a0bf0d8..35acac8 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -342,6 +342,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, 
int cpu)


 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
+   vcpu-cpu = -1;
kvm_arm_set_running_vcpu(NULL);
 }


This guy deserves to be in a separate patch, with a proper comment and 
maybe a #define for the -1 value. Something like KVM_VCPU_NOT_RUNNING?



diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 9b9fa20..ecf6dcf 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -589,6 +589,20 @@ static bool handle_mmio_sgi_reg(struct kvm_vcpu 
*vcpu,

return false;
 }

Re: [PATCH v3 7/9] KVM: arm-vgic: Support unqueueing of LRs to the dist

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:
To properly access the VGIC state from user space it is very 
unpractical

to have to loop through all the LRs in all register access functions.
Instead, support moving all pending state from LRs to the 
distributor,

but leave active state LRs alone.

Note that to accurately present the active and pending state to VCPUs
reading these distributor registers from a live VM, we would have to
stop all other VPUs than the calling VCPU and ask each CPU to unqueue
their LR state onto the distributor and add fields to track active 
state

on the distributor side as well.  We don't have any users of such
functionality yet and there are other inaccuracies of the GIC 
emulation,

so don't provide accurate synchronized access to this state just yet.
However, when the time comes, having this function should help.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org

Changelog[3]:
 - New patch in series
---
 virt/kvm/arm/vgic.c |   80
+++
 1 file changed, 75 insertions(+), 5 deletions(-)

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index ecf6dcf..44c669b 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -589,6 +589,72 @@ static bool handle_mmio_sgi_reg(struct kvm_vcpu 
*vcpu,

return false;
 }

+#define LR_CPUID(lr)   \
+   (((lr)  GICH_LR_PHYSID_CPUID)  GICH_LR_PHYSID_CPUID_SHIFT)
+#define LR_IRQID(lr)   \
+   ((lr)  GICH_LR_VIRTUALID)
+
+static void vgic_retire_lr(int lr_nr, int irq, struct vgic_cpu 
*vgic_cpu)

+{
+   clear_bit(lr_nr, vgic_cpu-lr_used);
+   vgic_cpu-vgic_lr[lr_nr] = ~GICH_LR_STATE;
+   vgic_cpu-vgic_irq_lr_map[irq] = LR_EMPTY;
+}
+
+/**
+ * vgic_unqueue_irqs - move pending IRQs from LRs to the distributor
+ * @vgic_cpu: Pointer to the vgic_cpu struct holding the LRs
+ *
+ * Move any pending IRQs that have already been assigned to LRs back 
to the

+ * emulated distributor state so that the complete emulated state
can be read
+ * from the main emulation structures without investigating the LRs.
+ *
+ * Note that IRQs in the active state in the LRs get their pending
state moved
+ * to the distributor but the active state stays in the LRs, because
we don't
+ * track the active state on the distributor side.
+ */
+static void vgic_unqueue_irqs(struct kvm_vcpu *vcpu)
+{
+   struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+   struct vgic_cpu *vgic_cpu = vcpu-arch.vgic_cpu;
+   int vcpu_id = vcpu-vcpu_id;
+   int i, irq, source_cpu;
+   u32 *lr;
+
+   for_each_set_bit(i, vgic_cpu-lr_used, vgic_cpu-nr_lr) {
+   lr = vgic_cpu-vgic_lr[i];
+   irq = LR_IRQID(*lr);
+   source_cpu = LR_CPUID(*lr);
+
+   /*
+* If the LR holds only an active interrupt (not pending) then
+* just leave it alone.
+*/
+   if (!__test_and_clear_bit(__ffs(GICH_LR_PENDING_BIT),
+ (unsigned long *)lr))
+   continue;


Now you got me confused. The comment talks about the active bit, but 
you're actually clearing the pending bit. Surely that deserves a better 
explanation.



+
+   /*
+* If the interrupt was only pending (not active or pending
+* and active) then we have effectively cleared the LR and it
+* should be marked as free for other use.
+*/
+   if (!(*lr  GICH_LR_STATE))
+   vgic_retire_lr(i, irq, vgic_cpu);


Why not directly testing the active bit? It'd be more consistent with 
the above if you used a similar method.



+   /*
+* Finally, reestablish the pending state on the distributor
+* and the CPU interface.  It may have already been pending,
+* but that is fine, then we are only setting a few bits that
+* were already set.
+*/
+   vgic_dist_irq_set(vcpu, irq);
+   if (irq  VGIC_NR_SGIS)
+   dist-irq_sgi_sources[vcpu_id][irq] |= 1  source_cpu;
+   vgic_update_state(vcpu-kvm);
+   }
+}
+
 static bool handle_mmio_sgi_clear(struct kvm_vcpu *vcpu,
  struct kvm_exit_mmio *mmio,
  phys_addr_t offset)
@@ -848,8 +914,6 @@ static void vgic_update_state(struct kvm *kvm)
}
 }

-#define LR_CPUID(lr)   \
-   (((lr)  GICH_LR_PHYSID_CPUID)  GICH_LR_PHYSID_CPUID_SHIFT)
 #define MK_LR_PEND(src, irq)   \
 	(GICH_LR_PENDING_BIT | ((src)  GICH_LR_PHYSID_CPUID_SHIFT) | 
(irq))


@@ -871,9 +935,7 @@ static void vgic_retire_disabled_irqs(struct
kvm_vcpu *vcpu)
int irq = vgic_cpu-vgic_lr[lr]  GICH_LR_VIRTUALID;

if (!vgic_irq_is_enabled(vcpu, irq)) {
-   vgic_cpu-vgic_irq_lr_map[irq] = LR_EMPTY;
-   clear_bit(lr, 

Re: Problem after update windows VirtIO drivers

[Alon Levy]

On 12/09/2013 04:45 PM, Carlos Rodrigues wrote:
 Hello,
 
 After update the VirtIO drivers for Windows Server 2008 R2 64-bit, when
 i reboot virtual machine, the windows OS get stuck on loading bar.
 
 The VirtIO drivers is the latest stable that i made the download from
 http://alt.fedoraproject.org/pub/alt/virtio-win/stable/virtio-win-0.1-74.iso
 
 And i use version 1.2.1 of kvm and the OS of host is Centos 5.8.
 
 I try to install a fresh and clean version same Windows and same drivers
 and get the same problem. With virtio-win-0.1-52 version of drivers, the
 windows server works properly.
 
 I will use the oldest stable version of drivers, but anyone knows some
 issue with latest drivers?
 

I have an issue that also existed with 0.65, on windows 7 64 bit: when I
have qxl enabled as well I get a crash shortly after initialization of
qxl (at the login screen) in a memory management function of the qxl
driver, indicating something overwrote parts of the allocators
accounting structures. When I disable the virtio driver (leaving the
virtio device) the problem goes away.

Vadim, is this a known problem? (sorry for hijacking the thread)

 Regards,
 

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 8/9] KVM: arm-vgic: Add GICD_SPENDSGIR and GICD_CPENDSGIR handlers

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:
Handle MMIO accesses to the two registers which should support both 
the
case where the VMs want to read/write either of these registers and 
the
case where user space reads/writes these registers to do save/restore 
of

the VGIC state.

Note that the added complexity compared to simple set/clear enable
registers stems from the bookkeping of source cpu ids.  It may be
possible to change the underlying data structure to simplify the
complexity, but since this is not in the critical path at all, this 
will

do.

Also note that reading this register from a live guest will not be
accurate compared to on hardware, because some state may be living on
the CPU LRs and the only way to give a consistent read would be to 
force

stop all the VCPUs and request them to unqueu the LR state onto the
distributor.  Until we have an actual user of live reading this
register, we can live with the difference.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org


Looks pretty good to me. Small note below, but otherwise:

Acked-by: Marc Zyngier marc.zyng...@arm.com



Changelog[v3]:
 - Renamed read/write SGI set/clear functions
 - Rely on unqueuing of interrupts from LRs instead of reading LRs
   directly
 - Deduplicate code

Changelog[v2]:
 - Use struct kvm_exit_mmio accessors for -data field.
---
 virt/kvm/arm/vgic.c |   70
---
 1 file changed, 66 insertions(+), 4 deletions(-)

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 44c669b..16053eb 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -655,18 +655,80 @@ static void vgic_unqueue_irqs(struct kvm_vcpu 
*vcpu)

}
 }

-static bool handle_mmio_sgi_clear(struct kvm_vcpu *vcpu,
- struct kvm_exit_mmio *mmio,
- phys_addr_t offset)
+/* Handle reads of GICD_CPENDSGIRn and GICD_SPENDSGIRn */
+static bool read_set_clear_sgi_pend_reg(struct kvm_vcpu *vcpu,
+   struct kvm_exit_mmio *mmio,
+   phys_addr_t offset)
 {
+   struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+   int sgi;
+   int min_sgi = (offset  ~0x3) * 4;
+   int max_sgi = min_sgi + 3;
+   int vcpu_id = vcpu-vcpu_id;
+   u32 reg = 0;
+
+   /* Copy source SGIs from distributor side */
+   for (sgi = min_sgi; sgi = max_sgi; sgi++) {
+   int shift = 8 * (sgi - min_sgi);
+   reg |= (u32)dist-irq_sgi_sources[vcpu_id][sgi]  shift;
+   }
+
+   mmio_data_write(mmio, ~0, reg);
return false;
 }

+static bool write_set_clear_sgi_pend_reg(struct kvm_vcpu *vcpu,
+struct kvm_exit_mmio *mmio,
+phys_addr_t offset, bool set)
+{
+   struct vgic_dist *dist = vcpu-kvm-arch.vgic;
+   int sgi;
+   int min_sgi = (offset  ~0x3) * 4;
+   int max_sgi = min_sgi + 3;
+   int vcpu_id = vcpu-vcpu_id;
+   u32 reg;
+   bool updated = false;
+
+   reg = mmio_data_read(mmio, ~0);
+
+   /* Clear pending SGIs on the distributor */
+   for (sgi = min_sgi; sgi = max_sgi; sgi++) {
+   u8 mask = reg  (8 * (sgi - min_sgi));
+   if (set) {
+   if ((dist-irq_sgi_sources[vcpu_id][sgi]  mask) != 
mask)
+   updated = true;
+   dist-irq_sgi_sources[vcpu_id][sgi] |= mask;
+   } else {
+   if (dist-irq_sgi_sources[vcpu_id][sgi]  mask)
+   updated = true;
+   dist-irq_sgi_sources[vcpu_id][sgi] = ~mask;
+   }
+   }
+
+   if (updated)
+   vgic_update_state(vcpu-kvm);


So I realize we have that construct everywhere. Surely it'd be worth it 
moving the mmio calls to vgic_update_state into vgic_handle_mmio. Or 
have I missed something?



+   return updated;
+}
+
 static bool handle_mmio_sgi_set(struct kvm_vcpu *vcpu,
struct kvm_exit_mmio *mmio,
phys_addr_t offset)
 {
-   return false;
+   if (!mmio-is_write)
+   return read_set_clear_sgi_pend_reg(vcpu, mmio, offset);
+   else
+   return write_set_clear_sgi_pend_reg(vcpu, mmio, offset, true);
+}
+
+static bool handle_mmio_sgi_clear(struct kvm_vcpu *vcpu,
+ struct kvm_exit_mmio *mmio,
+ phys_addr_t offset)
+{
+   if (!mmio-is_write)
+   return read_set_clear_sgi_pend_reg(vcpu, mmio, offset);
+   else
+   return write_set_clear_sgi_pend_reg(vcpu, mmio, offset, false);
 }

 /*


--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v3 9/9] KVM: arm-vgic: Support CPU interface reg access

[Marc Zyngier]

On 2013-11-17 04:30, Christoffer Dall wrote:
Implement support for the CPU interface register access driven by 
MMIO

address offsets from the CPU interface base address.  Useful for user
space to support save/restore of the VGIC state.

This commit adds support only for the same logic as the current VGIC
support, and no more.  For example, the active priority registers are
handled as RAZ/WI, just like setting priorities on the emulated
distributor.

Signed-off-by: Christoffer Dall christoffer.d...@linaro.org


Acked-by: Marc Zyngier marc.zyng...@arm.com


---
 virt/kvm/arm/vgic.c |   81
++-
 1 file changed, 73 insertions(+), 8 deletions(-)

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 16053eb..a08b89a 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -71,6 +71,10 @@
 #define VGIC_ADDR_UNDEF(-1)
 #define IS_VGIC_ADDR_UNDEF(_x)  ((_x) == VGIC_ADDR_UNDEF)

+#define PRODUCT_ID_KVM 0x4b/* ASCII code K */
+#define IMPLEMENTER_ARM0x43b
+#define GICC_ARCH_VERSION_V2   0x2
+
 /* Physical address of vgic virtual cpu interface */
 static phys_addr_t vgic_vcpu_base;

@@ -312,7 +316,7 @@ static bool handle_mmio_misc(struct kvm_vcpu 
*vcpu,

u32 word_offset = offset  3;

switch (offset  ~3) {
-   case 0: /* CTLR */
+   case 0: /* GICD_CTLR */
reg = vcpu-kvm-arch.vgic.enabled;
vgic_reg_access(mmio, reg, word_offset,
ACCESS_READ_VALUE | ACCESS_WRITE_VALUE);
@@ -323,15 +327,15 @@ static bool handle_mmio_misc(struct kvm_vcpu 
*vcpu,

}
break;

-   case 4: /* TYPER */
+   case 4: /* GICD_TYPER */
reg  = (atomic_read(vcpu-kvm-online_vcpus) - 1)  5;
reg |= (VGIC_NR_IRQS  5) - 1;
vgic_reg_access(mmio, reg, word_offset,
ACCESS_READ_VALUE | ACCESS_WRITE_IGNORED);
break;

-   case 8: /* IIDR */
-   reg = 0x4B00043B;
+   case 8: /* GICD_IIDR */
+   reg = (PRODUCT_ID_KVM  24) | (IMPLEMENTER_ARM  0);
vgic_reg_access(mmio, reg, word_offset,
ACCESS_READ_VALUE | ACCESS_WRITE_IGNORED);
break;
@@ -1703,9 +1707,70 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned
long type, u64 *addr, bool write)
 static bool handle_cpu_mmio_misc(struct kvm_vcpu *vcpu,
 struct kvm_exit_mmio *mmio, phys_addr_t offset)
 {
-   return true;
+   struct vgic_cpu *vgic_cpu = vcpu-arch.vgic_cpu;
+   u32 reg, mask = 0, shift = 0;
+   bool updated = false;
+
+   switch (offset  ~0x3) {
+   case GIC_CPU_CTRL:
+   mask = GICH_VMCR_CTRL_MASK;
+   shift = GICH_VMCR_CTRL_SHIFT;
+   break;
+   case GIC_CPU_PRIMASK:
+   mask = GICH_VMCR_PRIMASK_MASK;
+   shift = GICH_VMCR_PRIMASK_SHIFT;
+   break;
+   case GIC_CPU_BINPOINT:
+   mask = GICH_VMCR_BINPOINT_MASK;
+   shift = GICH_VMCR_BINPOINT_SHIFT;
+   break;
+   case GIC_CPU_ALIAS_BINPOINT:
+   mask = GICH_VMCR_ALIAS_BINPOINT_MASK;
+   shift = GICH_VMCR_ALIAS_BINPOINT_SHIFT;
+   break;
+   }
+
+   if (!mmio-is_write) {
+   reg = (vgic_cpu-vgic_vmcr  mask)  shift;
+   mmio_data_write(mmio, ~0, reg);
+   } else {
+   reg = mmio_data_read(mmio, ~0);
+   reg = (reg  shift)  mask;
+   if (reg != (vgic_cpu-vgic_vmcr  mask))
+   updated = true;
+   vgic_cpu-vgic_vmcr = ~mask;
+   vgic_cpu-vgic_vmcr |= reg;
+   }
+   return updated;
+}
+
+static bool handle_mmio_abpr(struct kvm_vcpu *vcpu,
+struct kvm_exit_mmio *mmio, phys_addr_t offset)
+{
+   return handle_cpu_mmio_misc(vcpu, mmio, GIC_CPU_ALIAS_BINPOINT);
 }

+static bool handle_cpu_mmio_ident(struct kvm_vcpu *vcpu,
+ struct kvm_exit_mmio *mmio,
+ phys_addr_t offset)
+{
+   u32 reg;
+
+   if (mmio-is_write)
+   return false;
+
+   /* GICC_IIDR */
+   reg = (PRODUCT_ID_KVM  20) |
+ (GICC_ARCH_VERSION_V2  16) |
+ (IMPLEMENTER_ARM  0);
+   mmio_data_write(mmio, ~0, reg);
+   return false;
+}
+
+/*
+ * CPU Interface Register accesses - these are not accessed by the
VM, but by
+ * user space for saving and restoring VGIC state.
+ */
 static const struct mmio_range vgic_cpu_ranges[] = {
{
.base   = GIC_CPU_CTRL,
@@ -1715,17 +1780,17 @@ static const struct mmio_range 
vgic_cpu_ranges[] = {

{
.base   = 

Re: [PATCH 1/2 v2] arm/arm64: KVM: arch_timer: Initialize cntvoff at kvm_init

[Marc Zyngier]

On 2013-11-17 03:12, Christoffer Dall wrote:
Initialize the cntvoff at kvm_init_vm time, not before running the 
VCPUs
at the first time because that will overwrite any potentially 
restored

values from user space.

Cc: Marc Zynger marc.zyng...@arm.com
Cc: Andre Przywara andre.przyw...@linaro.org
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org


Acked-by: Marc Zyngier marc.zyng...@arm.com


---

Changelog[v2]:
 - Call kvm_timer_init from kvm_arch_init_vm instead of moving the 
cntvoff to

   vcpu initialization, which would be redundant.

 arch/arm/kvm/arm.c  |2 ++
 virt/kvm/arm/vgic.c |1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index e312e4a..2bc2ec4 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -137,6 +137,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned 
long type)

if (ret)
goto out_free_stage2_pgd;

+   kvm_timer_init(kvm);
+
/* Mark the initial VMID generation invalid */
kvm-arch.vmid_gen = 0;

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 685fc72..81e9481 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1409,7 +1409,6 @@ int kvm_vgic_init(struct kvm *kvm)
for (i = VGIC_NR_PRIVATE_IRQS; i  VGIC_NR_IRQS; i += 4)
vgic_set_target_reg(kvm, 0, i);

-   kvm_timer_init(kvm);
kvm-arch.vgic.ready = true;
 out:
mutex_unlock(kvm-lock);


--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2 v3 RESEND] ARM/KVM: save and restore generic timer registers

[Marc Zyngier]

On 2013-11-17 03:12, Christoffer Dall wrote:

From: Andre Przywara andre.przyw...@linaro.org

For migration to work we need to save (and later restore) the state 
of

each cores virtual generic timer.
Since this is per VCPU, we can use the [gs]et_one_reg ioctl and 
export

the three needed registers (control, counter, compare value).
Though they live in cp15 space, we don't use the existing list, since
they need special accessor functions and the arch timer is optional.

Signed-off-by: Andre Przywara andre.przyw...@linaro.org
Signed-off-by: Christoffer Dall christoffer.d...@linaro.org
---

Changes from v1:
- move code out of coproc.c and into guest.c and arch_timer.c
- present the registers with their native CP15 addresses, but without
  using space in the VCPU's cp15 array
- do the user space copying in the accessor functions

Changes from v2:
- fix compilation without CONFIG_ARCH_TIMER
- fix compilation for arm64 by defining the appropriate registers 
there

- move userspace access out of arch_timer.c into coproc.c

  [ Removed whitespace in function declaration - Christoffer ]

 arch/arm/include/asm/kvm_host.h   |3 ++
 arch/arm/include/uapi/asm/kvm.h   |   16 +++
 arch/arm/kvm/guest.c  |   92
-
 arch/arm64/include/uapi/asm/kvm.h |   25 ++
 virt/kvm/arm/arch_timer.c |   34 ++
 5 files changed, 169 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_host.h
b/arch/arm/include/asm/kvm_host.h
index 8a6f6db..098f7dd 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -225,4 +225,7 @@ static inline int
kvm_arch_dev_ioctl_check_extension(long ext)
 int kvm_perf_init(void);
 int kvm_perf_teardown(void);

+u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
+int kvm_arm_timer_set_reg(struct kvm_vcpu *, u64 regid, u64 value);
+
 #endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/include/uapi/asm/kvm.h
b/arch/arm/include/uapi/asm/kvm.h
index c498b60..bd3b2f7 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -119,6 +119,22 @@ struct kvm_arch_memory_slot {
 #define KVM_REG_ARM_32_CRN_MASK0x7800
 #define KVM_REG_ARM_32_CRN_SHIFT   11

+#define KVM_REG_ARM_32_CP15		(KVM_REG_ARM | KVM_REG_SIZE_U32  | 
\

+   (15ULL  KVM_REG_ARM_COPROC_SHIFT))
+#define KVM_REG_ARM_64_CP15		(KVM_REG_ARM | KVM_REG_SIZE_U64  | 
\

+   (15ULL  KVM_REG_ARM_COPROC_SHIFT))
+#define KVM_REG_ARM_TIMER_CTL		(KVM_REG_ARM_32_CP15 
| \

+   ( 3ULL  KVM_REG_ARM_CRM_SHIFT) | \
+   (14ULL  KVM_REG_ARM_32_CRN_SHIFT)  | \
+   ( 0ULL  KVM_REG_ARM_OPC1_SHIFT)| \
+   ( 1ULL  KVM_REG_ARM_32_OPC2_SHIFT))
+#define KVM_REG_ARM_TIMER_CNT  (KVM_REG_ARM_64_CP15 | \
+   (14ULL  KVM_REG_ARM_CRM_SHIFT) | \
+   ( 1ULL  KVM_REG_ARM_OPC1_SHIFT))
+#define KVM_REG_ARM_TIMER_CVAL (KVM_REG_ARM_64_CP15 | \
+   (14ULL  KVM_REG_ARM_CRM_SHIFT) | \
+   ( 3ULL  KVM_REG_ARM_OPC1_SHIFT))


Surely we can build a nice set of macros for that. See:
http://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/commit/?h=kvmtool/armid=74797cf796b47dea98229568772f879a566d7259

and the way we construct accessors for MPIDR. And if you reuse those, 
we can delete them from kvmtool!



 /* Normal registers are mapped as coprocessor 16. */
 #define KVM_REG_ARM_CORE   (0x0010  KVM_REG_ARM_COPROC_SHIFT)
 #define KVM_REG_ARM_CORE_REG(name)	(offsetof(struct kvm_regs, name) 
/ 4)

diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 20f8d97..2786eae 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -109,6 +109,83 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu
*vcpu, struct kvm_regs *regs)
return -EINVAL;
 }

+#ifndef CONFIG_KVM_ARM_TIMER
+
+#define NUM_TIMER_REGS 0
+
+static int copy_timer_indices(struct kvm_vcpu *vcpu, u64 __user 
*uindices)

+{
+   return 0;
+}
+
+static bool is_timer_reg(u64 index)
+{
+   return false;
+}
+
+int kvm_arm_timer_set_reg(struct kvm_vcpu *vcpu, u64 regid, u64 
value)

+{
+   return 0;
+}
+
+u64 kvm_arm_timer_get_reg(struct kvm_vcpu *vcpu, u64 regid)
+{
+   return 0;
+}
+
+#else
+
+#define NUM_TIMER_REGS 3
+
+static bool is_timer_reg(u64 index)
+{
+   switch (index) {
+   case KVM_REG_ARM_TIMER_CTL:
+   case KVM_REG_ARM_TIMER_CNT:
+   case KVM_REG_ARM_TIMER_CVAL:
+   return true;
+   }
+   return false;
+}
+
+static int copy_timer_indices(struct kvm_vcpu *vcpu, u64 __user 
*uindices)

+{
+   if (put_user(KVM_REG_ARM_TIMER_CTL, uindices))
+ 

Re: [REPOST][PATCH 1/2] driver core: Add new device_driver flag to allow binding via sysfs only

[Kim Phillips]

On Thu, 5 Dec 2013 16:38:15 -0600
Scott Wood scottw...@freescale.com wrote:

 On Thu, 2013-12-05 at 17:45 +, Kim Phillips wrote:
  On Tue, 03 Dec 2013 16:34:33 +0100
  Jan Kiszka jan.kis...@siemens.com wrote:
  
   On 2013-12-03 13:34, Kim Phillips wrote:
VFIO supports pass-through of devices to user space - for sake
of illustration, say a PCI e1000 device:

- the e1000 is first unbound from the PCI e1000 driver via sysfs
- the vfio-pci driver is told via new_id that it now handles e1000 
devices
- the e1000 is explicitly bound to vfio-pci through sysfs

However, now we have two drivers in the system that both handle e1000
devices.  A hotplug event could then occur and it is ambiguous as to 
which
driver will claim the device.  The desired semantics is that vfio-pci is
only bound to devices by explicit request in sysfs.  This patch makes 
this
possible by introducing a sysfs_bind_only flag in struct device_driver.

Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
Signed-off-by: Kim Phillips kim.phill...@linaro.org
---
rebased onto 3.13-rc2, and reposted from first submission which
recieved no comments:

https://lkml.org/lkml/2013/10/11/53

 drivers/base/dd.c  | 5 -
 include/linux/device.h | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 0605176..b83b16d 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -389,7 +389,7 @@ static int __device_attach(struct device_driver 
*drv, void *data)
 {
struct device *dev = data;
 
-   if (!driver_match_device(drv, dev))
+   if (drv-sysfs_bind_only || !driver_match_device(drv, dev))
return 0;
 
return driver_probe_device(drv, dev);
@@ -476,6 +476,9 @@ static int __driver_attach(struct device *dev, void 
*data)
  */
 int driver_attach(struct device_driver *drv)
 {
+   if (drv-sysfs_bind_only)
+   return 0;
+
return bus_for_each_dev(drv-bus, NULL, drv, __driver_attach);
 }
 EXPORT_SYMBOL_GPL(driver_attach);
diff --git a/include/linux/device.h b/include/linux/device.h
index 952b010..ed441d1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -200,6 +200,7 @@ extern struct klist *bus_get_device_klist(struct 
bus_type *bus);
  * @owner: The module owner.
  * @mod_name:  Used for built-in modules.
  * @suppress_bind_attrs: Disables bind/unbind via sysfs.
+ * @sysfs_bind_only: Only allow bind/unbind via sysfs.
  * @of_match_table: The open firmware table.
  * @acpi_match_table: The ACPI match table.
  * @probe: Called to query the existence of a specific device,
@@ -233,6 +234,7 @@ struct device_driver {
const char  *mod_name;  /* used for built-in 
modules */
 
bool suppress_bind_attrs;   /* disables bind/unbind via 
sysfs */
+   bool sysfs_bind_only;   /* only allow bind/unbind via 
sysfs */
 
const struct of_device_id   *of_match_table;
const struct acpi_device_id *acpi_match_table;
   
   I think I only discussed this with Stuart in person at the KVM Forum:
   Why not deriving the property sysfs bind only from the fact that a
   device does wild-card binding? Are there use cases that benefit from
   decoupling both features?
  
  you mean merge the two new flags sysfs_bind_only and platform driver's
  match_any_dev into one new single driver flag, right?  good question.
 
 What would combining them solve, other than making it more likely that
 Greg complains about the wildcard because it would no longer be handled
 at the bus level where all the other matching goes on?
 
 They are logically separate things.  That doesn't change just because we
 currently plan to use them together.

Jan?  Given the above, what would be the advantage of merging
sysfs_bind_only and (PCI drivers' PCI_ANY_ID and platform drivers'
match_any_dev)?

Kim
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Performance counters in kvm?

[Binh Q. Pham]

Sorry for a late response as I was distracted by another task in the 
last few weeks. Today, I compiled and installed QEMU 1.7.0 from source, 
but no luck with this. Tested on a different machine with different 
kernel version: 3.2, I got the same results.


Btw, I found bug 798936 which describes similar problem here:
bugzilla.redhat.com/show_bug.cgi?id=798936

it seems like this problem has been detected and resolved in the past. 
Do you know what Linux distro/kernel that the bug was resolved on? Maybe 
I can try that instead of using ubuntu to see if it works.


Thanks,
Binh
On 11/14/2013 04:08 PM, Gleb Natapov wrote:

On Thu, Nov 14, 2013 at 03:31:01PM -0500, Binh Q. Pham wrote:

My host kernel version is 3.10.17


That one surely has PMU emulation, but your guest does not see it. I blame
QEMU. Can you compile QEMU from git?


Binh
On 11/14/2013 12:21 PM, Gleb Natapov wrote:

On Thu, Nov 14, 2013 at 12:04:50PM -0500, Binh Q. Pham wrote:

cpuid output is attached.

PMU support is not advertised to the guest which means that either
QEMU is broken or your host kernel does not have PMU kvm support. What is
your host kernel version?


I didn't know that the kernel was not compiled with virtualization
support as I was using a ready image from ubuntu website to install
the VM. In the long run, are you suggesting me to recompile the
kernel for the guest to make sure that it has virtualization
support?


I am surprised ubuntu kernel does not have virtualiztion support
compiled in. May be they have separate kernel for that, but I am not
ubuntu user so cannot tell.


--
Gleb.

--
Gleb.



--
-Binh

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REPOST][PATCH 1/2] driver core: Add new device_driver flag to allow binding via sysfs only

[Jan Kiszka]

On 2013-12-09 19:58, Kim Phillips wrote:
 On Thu, 5 Dec 2013 16:38:15 -0600
 Scott Wood scottw...@freescale.com wrote:
 
 On Thu, 2013-12-05 at 17:45 +, Kim Phillips wrote:
 On Tue, 03 Dec 2013 16:34:33 +0100
 Jan Kiszka jan.kis...@siemens.com wrote:

 On 2013-12-03 13:34, Kim Phillips wrote:
 VFIO supports pass-through of devices to user space - for sake
 of illustration, say a PCI e1000 device:

 - the e1000 is first unbound from the PCI e1000 driver via sysfs
 - the vfio-pci driver is told via new_id that it now handles e1000 devices
 - the e1000 is explicitly bound to vfio-pci through sysfs

 However, now we have two drivers in the system that both handle e1000
 devices.  A hotplug event could then occur and it is ambiguous as to which
 driver will claim the device.  The desired semantics is that vfio-pci is
 only bound to devices by explicit request in sysfs.  This patch makes this
 possible by introducing a sysfs_bind_only flag in struct device_driver.

 Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
 Signed-off-by: Kim Phillips kim.phill...@linaro.org
 ---
 rebased onto 3.13-rc2, and reposted from first submission which
 recieved no comments:

 https://lkml.org/lkml/2013/10/11/53

  drivers/base/dd.c  | 5 -
  include/linux/device.h | 2 ++
  2 files changed, 6 insertions(+), 1 deletion(-)

 diff --git a/drivers/base/dd.c b/drivers/base/dd.c
 index 0605176..b83b16d 100644
 --- a/drivers/base/dd.c
 +++ b/drivers/base/dd.c
 @@ -389,7 +389,7 @@ static int __device_attach(struct device_driver *drv, 
 void *data)
  {
   struct device *dev = data;
  
 - if (!driver_match_device(drv, dev))
 + if (drv-sysfs_bind_only || !driver_match_device(drv, dev))
   return 0;
  
   return driver_probe_device(drv, dev);
 @@ -476,6 +476,9 @@ static int __driver_attach(struct device *dev, void 
 *data)
   */
  int driver_attach(struct device_driver *drv)
  {
 + if (drv-sysfs_bind_only)
 + return 0;
 +
   return bus_for_each_dev(drv-bus, NULL, drv, __driver_attach);
  }
  EXPORT_SYMBOL_GPL(driver_attach);
 diff --git a/include/linux/device.h b/include/linux/device.h
 index 952b010..ed441d1 100644
 --- a/include/linux/device.h
 +++ b/include/linux/device.h
 @@ -200,6 +200,7 @@ extern struct klist *bus_get_device_klist(struct 
 bus_type *bus);
   * @owner:   The module owner.
   * @mod_name:Used for built-in modules.
   * @suppress_bind_attrs: Disables bind/unbind via sysfs.
 + * @sysfs_bind_only: Only allow bind/unbind via sysfs.
   * @of_match_table: The open firmware table.
   * @acpi_match_table: The ACPI match table.
   * @probe:   Called to query the existence of a specific device,
 @@ -233,6 +234,7 @@ struct device_driver {
   const char  *mod_name;  /* used for built-in modules */
  
   bool suppress_bind_attrs;   /* disables bind/unbind via sysfs */
 + bool sysfs_bind_only;   /* only allow bind/unbind via sysfs */
  
   const struct of_device_id   *of_match_table;
   const struct acpi_device_id *acpi_match_table;

 I think I only discussed this with Stuart in person at the KVM Forum:
 Why not deriving the property sysfs bind only from the fact that a
 device does wild-card binding? Are there use cases that benefit from
 decoupling both features?

 you mean merge the two new flags sysfs_bind_only and platform driver's
 match_any_dev into one new single driver flag, right?  good question.

 What would combining them solve, other than making it more likely that
 Greg complains about the wildcard because it would no longer be handled
 at the bus level where all the other matching goes on?

 They are logically separate things.  That doesn't change just because we
 currently plan to use them together.
 
 Jan?  Given the above, what would be the advantage of merging
 sysfs_bind_only and (PCI drivers' PCI_ANY_ID and platform drivers'
 match_any_dev)?

That you cannot configure (likely) meaningless or even harmful (bind-any
+ auto-bind) configurations.

I didn't follow if Greg expressed his opinion on this or a similar
scenario before. If he prefers separate knobs for a certain reason, he
likely wins.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem after update windows VirtIO drivers

[Cole Robinson]

On 12/09/2013 11:45 AM, Alon Levy wrote:
 On 12/09/2013 04:45 PM, Carlos Rodrigues wrote:
 Hello,

 After update the VirtIO drivers for Windows Server 2008 R2 64-bit, when
 i reboot virtual machine, the windows OS get stuck on loading bar.

 The VirtIO drivers is the latest stable that i made the download from
 http://alt.fedoraproject.org/pub/alt/virtio-win/stable/virtio-win-0.1-74.iso

 And i use version 1.2.1 of kvm and the OS of host is Centos 5.8.

 I try to install a fresh and clean version same Windows and same drivers
 and get the same problem. With virtio-win-0.1-52 version of drivers, the
 windows server works properly.

 I will use the oldest stable version of drivers, but anyone knows some
 issue with latest drivers?

 
 I have an issue that also existed with 0.65, on windows 7 64 bit: when I
 have qxl enabled as well I get a crash shortly after initialization of
 qxl (at the login screen) in a memory management function of the qxl
 driver, indicating something overwrote parts of the allocators
 accounting structures. When I disable the virtio driver (leaving the
 virtio device) the problem goes away.
 
 Vadim, is this a known problem? (sorry for hijacking the thread)
 

I'd also recommend filing a bug at Fedora-virtio-win component in
bugzilla.redhat.com where many of the windows guys keep watch.

- Cole
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] powerpc/kvm/booke: Fix build break due to stack frame size warning

[Scott Wood]

On Mon, 2013-11-25 at 04:26 -0600, Bharat Bhushan wrote:
 
  -Original Message-
  From: Wood Scott-B07421
  Sent: Saturday, November 23, 2013 3:22 AM
  To: Alexander Graf
  Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
  Bharat-R65777
  Subject: [PATCH] powerpc/kvm/booke: Fix build break due to stack frame size
  warning
 
  Commit ce11e48b7fdd256ec68b932a89b397a790566031 (KVM: PPC: E500: Add
  userspace debug stub support) added struct thread_struct to the
  stack of kvmppc_vcpu_run().  thread_struct is 1152 bytes on my build,
  compared to 48 bytes for the recently-introduced struct debug_reg.
  Use the latter instead.
 
  This fixes the following error:
 
  cc1: warnings being treated as errors
  arch/powerpc/kvm/booke.c: In function 'kvmppc_vcpu_run':
  arch/powerpc/kvm/booke.c:760:1: error: the frame size of 1424 bytes is 
  larger
  than 1024 bytes
  make[2]: *** [arch/powerpc/kvm/booke.o] Error 1
  make[1]: *** [arch/powerpc/kvm] Error 2
  make[1]: *** Waiting for unfinished jobs
 
  Signed-off-by: Scott Wood scottw...@freescale.com
  Cc: Bharat Bhushan r65...@freescale.com
  ---
  Build tested only.  Bharat, please test.
 
 Tested with qemu debug stub; It works fine
 
 -Bharat

Alex, are you going to take this through your tree?

-Scott



--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REPOST][PATCH 1/2] driver core: Add new device_driver flag to allow binding via sysfs only

[Scott Wood]

On Mon, 2013-12-09 at 20:12 +0100, Jan Kiszka wrote:
 On 2013-12-09 19:58, Kim Phillips wrote:
  On Thu, 5 Dec 2013 16:38:15 -0600
  Scott Wood scottw...@freescale.com wrote:
  
  What would combining them solve, other than making it more likely that
  Greg complains about the wildcard because it would no longer be handled
  at the bus level where all the other matching goes on?
 
  They are logically separate things.  That doesn't change just because we
  currently plan to use them together.
  
  Jan?  Given the above, what would be the advantage of merging
  sysfs_bind_only and (PCI drivers' PCI_ANY_ID and platform drivers'
  match_any_dev)?
 
 That you cannot configure (likely) meaningless or even harmful (bind-any
 + auto-bind) configurations.

If you want to put in a check that warns on bind-any plus auto-bind,
fine -- but that doesn't mean they should share a mechanism.  It's valid
to have no-auto-bind without a wildcard match.  And FWIW, PCI already
has wildcard matches without any no-auto-bind mechanism (it's presumably
not intended to specify PCI_ANY_ID for all fields, but it is allowed
AFAICT).

-Scott


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] powerpc/kvm/booke: Fix build break due to stack frame size warning

[Alexander Graf]

On 09.12.2013, at 22:18, Scott Wood scottw...@freescale.com wrote:

 On Mon, 2013-11-25 at 04:26 -0600, Bharat Bhushan wrote:
 
 -Original Message-
 From: Wood Scott-B07421
 Sent: Saturday, November 23, 2013 3:22 AM
 To: Alexander Graf
 Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
 Bharat-R65777
 Subject: [PATCH] powerpc/kvm/booke: Fix build break due to stack frame size
 warning
 
 Commit ce11e48b7fdd256ec68b932a89b397a790566031 (KVM: PPC: E500: Add
 userspace debug stub support) added struct thread_struct to the
 stack of kvmppc_vcpu_run().  thread_struct is 1152 bytes on my build,
 compared to 48 bytes for the recently-introduced struct debug_reg.
 Use the latter instead.
 
 This fixes the following error:
 
 cc1: warnings being treated as errors
 arch/powerpc/kvm/booke.c: In function 'kvmppc_vcpu_run':
 arch/powerpc/kvm/booke.c:760:1: error: the frame size of 1424 bytes is 
 larger
 than 1024 bytes
 make[2]: *** [arch/powerpc/kvm/booke.o] Error 1
 make[1]: *** [arch/powerpc/kvm] Error 2
 make[1]: *** Waiting for unfinished jobs
 
 Signed-off-by: Scott Wood scottw...@freescale.com
 Cc: Bharat Bhushan r65...@freescale.com
 ---
 Build tested only.  Bharat, please test.
 
 Tested with qemu debug stub; It works fine
 
 -Bharat
 
 Alex, are you going to take this through your tree?

Sure. Do you want this for 3.13 or 3.14? Since I don't see the breakage with my 
compilers I'd queue it for 3.14, but whatever works for you works for me.

Also Bharat, could you please make that a real Tested-by line?


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem after update windows VirtIO drivers

[Vadim Rozenfeld]

- Original Message -
From: Alon Levy al...@redhat.com
To: Carlos Rodrigues c...@eurotux.com, kvm@vger.kernel.org, Vadim 
Rozenfeld vroze...@redhat.com
Sent: Tuesday, December 10, 2013 3:45:32 AM
Subject: Re: Problem after update windows VirtIO drivers

On 12/09/2013 04:45 PM, Carlos Rodrigues wrote:
 Hello,
 
 After update the VirtIO drivers for Windows Server 2008 R2 64-bit, when
 i reboot virtual machine, the windows OS get stuck on loading bar.
 
 The VirtIO drivers is the latest stable that i made the download from
 http://alt.fedoraproject.org/pub/alt/virtio-win/stable/virtio-win-0.1-74.iso
 
 And i use version 1.2.1 of kvm and the OS of host is Centos 5.8.
 
 I try to install a fresh and clean version same Windows and same drivers
 and get the same problem. With virtio-win-0.1-52 version of drivers, the
 windows server works properly.
 
 I will use the oldest stable version of drivers, but anyone knows some
 issue with latest drivers?
 
[VR]
Hi Carlos,
Could you please post the QEMU command line as well as output
from 'info pci'

I have an issue that also existed with 0.65, on windows 7 64 bit: when I
have qxl enabled as well I get a crash shortly after initialization of
qxl (at the login screen) in a memory management function of the qxl
driver, indicating something overwrote parts of the allocators
accounting structures. When I disable the virtio driver (leaving the
virtio device) the problem goes away.

Vadim, is this a known problem? (sorry for hijacking the thread)

Does it crash into BSOD? Can you share the crash dump file?

Best regards,
Vadim.


 Regards,
 

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] KVM: PPC: Book3S HV: Fix physical address calculations

[Paul Mackerras]

On Fri, Dec 06, 2013 at 09:52:31PM +1100, Alexey Kardashevskiy wrote:
 This patch breaks VFIO with Intel E1000E on my p5ioc2 machine (vpl2) - the
 guest tries allocating MSI ibm,change_msi and pauses for a while (
 10minutes), then continues but the ethernet adapter does not work anyway.
 Disabling MSI in QEMU does not help though. I'll debug on Monday but quick
 ideas are welcome.

Looks like I'm losing some low-order address bits in kvmppc_do_h_enter
when the guest creates a 4k HPTE.

Alex, have you merged this patch in an immutable branch yet?  Do you
want an incremental patch on top, or a revised version of this patch?

Regards,
Paul.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: PPC: Add devname:kvm aliases for modules

[Michael Tokarev]

09.12.2013 19:01, Alexander Graf wrote:
[]
 +++ b/arch/powerpc/kvm/44x.c
 @@ -231,3 +231,6 @@ static void __exit kvmppc_44x_exit(void)
  
  module_init(kvmppc_44x_init);
  module_exit(kvmppc_44x_exit);
 +#include linux/miscdevice.h
 +MODULE_ALIAS_MISCDEV(KVM_MINOR);
 +MODULE_ALIAS(devname:kvm);

Usual thing is to add #includes into the beginning of a source file,
not at the end of it, here and in all other similar places.

Thanks,

/mjt
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 07/15] KVM: MMU: introduce nulls desc

[Xiao Guangrong]

On 12/06/2013 08:22 AM, Marcelo Tosatti wrote:
 On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
 In some cases, the lockless walker will do endless-walking on desc and
 without rewalk, consider this case:

 there are two descs: desc1 and desc2 who is pointed by desc1-next：
 desc1-next = desc2.

 CPU 0
 CPU 1

 lockless walk on desc1
  deleting 
 desc1 from the rmap
 lockless walk on desc2 (desc1-next)
 delete desc2 
 from the rmap
 add desc1
 add desc2, 
 then desc2-next = desc1

 lockless walk on desc1
delete desc2
delete desc1
add desc2
add desc1; 
 the desc1-next = desc2
 lockless walk on desc2

 ……

 Then, the walker is endlessly walking on desc1 and desc2 without any rewalk.
 
 The counter can be local to the walker. If its more than maximum rmap
 size, break.
 
 (but still, please consider carefully whether lockless list walking is
 really necessary or can be avoided).

Yep, Marcelo, you're right.

After thinking more, i do not have any idea to simplify this. Your approach
(lockless on the first level) seems a better solution. Will do it based on that
ways.

Thanks!


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: nVMX: Add support for activity state HLT

[Jan Kiszka]

On 2013-12-06 13:49, Jan Kiszka wrote:
 On 2013-12-05 10:52, Paolo Bonzini wrote:
 Il 04/12/2013 08:58, Jan Kiszka ha scritto:
 We can easily emulate the HLT activity state for L1: If it decides that
 L2 shall be halted on entry, just invoke the normal emulation of halt
 after switching to L2. We do not depend on specific host features to
 provide this, so we can expose the capability unconditionally.

 Signed-off-by: Jan Kiszka jan.kis...@siemens.com
 ---

 Jailhouse would like to use this. Experimental code works fine so far,
 both on patched KVM and real HW.

 Nice. :)

 Do you have a testcase for kvm-unit-tests?
 
 Not yet. Maybe I will find a little time these days.

Test are still ongoing, but it seems there are problems remaining with
halting in L2 in general, i.e. with unintercepted hlt. I'm currently
applying this to get beyond some hangups, but I'm still experiencing
some delayed IRQ delivery to L2:

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 31eb577..fad04ce 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4684,6 +4684,7 @@ static int vmx_interrupt_allowed(struct kvm_vcpu *vcpu)
vmcs12-vm_exit_reason =
EXIT_REASON_EXTERNAL_INTERRUPT;
vmcs12-vm_exit_intr_info = 0;
+   kvm_make_request(KVM_REQ_UNHALT, vcpu);
/*
 * fall through to normal code, but now in L1, not L2
 */
@@ -8057,8 +8058,6 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool 
launch)
 
enter_guest_mode(vcpu);
 
-   vmx-nested.nested_run_pending = 1;
-
vmx-nested.vmcs01_tsc_offset = vmcs_read64(TSC_OFFSET);
 
cpu = get_cpu();
@@ -8077,6 +8076,8 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool 
launch)
if (vmcs12-guest_activity_state == GUEST_ACTIVITY_HLT)
return kvm_emulate_halt(vcpu);
 
+   vmx-nested.nested_run_pending = 1;
+
/*
 * Note no nested_vmx_succeed or nested_vmx_fail here. At this point
 * we are no longer running L1, and VMLAUNCH/VMRESUME has not yet

Jan



signature.asc
Description: OpenPGP digital signature

[PATCH] KVM: PPC: Add devname:kvm aliases for modules

[Alexander Graf]

Systems that support automatic loading of kernel modules through
device aliases should try and automatically load kvm when /dev/kvm
gets opened.

Add code to support that magic for all PPC kvm targets, even the
ones that don't support modules yet.

Signed-off-by: Alexander Graf ag...@suse.de
---
 arch/powerpc/kvm/44x.c   | 3 +++
 arch/powerpc/kvm/book3s.c| 7 +++
 arch/powerpc/kvm/book3s_hv.c | 3 +++
 arch/powerpc/kvm/book3s_pr.c | 3 +++
 arch/powerpc/kvm/e500.c  | 3 +++
 arch/powerpc/kvm/e500mc.c| 3 +++
 6 files changed, 22 insertions(+)

diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 93221e8..fea2a11 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -231,3 +231,6 @@ static void __exit kvmppc_44x_exit(void)
 
 module_init(kvmppc_44x_init);
 module_exit(kvmppc_44x_exit);
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 8912608..5892599 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -879,3 +879,10 @@ static void kvmppc_book3s_exit(void)
 
 module_init(kvmppc_book3s_init);
 module_exit(kvmppc_book3s_exit);
+
+/* On 32bit this is our one and only kernel module */
+#ifdef CONFIG_KVM_BOOK3S_32
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
+#endif
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 93203bb..86d1f4d 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2215,4 +2215,7 @@ static void kvmppc_book3s_exit_hv(void)
 
 module_init(kvmppc_book3s_init_hv);
 module_exit(kvmppc_book3s_exit_hv);
+#include linux/miscdevice.h
 MODULE_LICENSE(GPL);
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index fe14ca3..b97e21e 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1583,5 +1583,8 @@ void kvmppc_book3s_exit_pr(void)
 module_init(kvmppc_book3s_init_pr);
 module_exit(kvmppc_book3s_exit_pr);
 
+#include linux/miscdevice.h
 MODULE_LICENSE(GPL);
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
 #endif
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index 497b142..080dbe0 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -573,3 +573,6 @@ static void __exit kvmppc_e500_exit(void)
 
 module_init(kvmppc_e500_init);
 module_exit(kvmppc_e500_exit);
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 4132cd2..352c629 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -391,3 +391,6 @@ static void __exit kvmppc_e500mc_exit(void)
 
 module_init(kvmppc_e500mc_init);
 module_exit(kvmppc_e500mc_exit);
+#include linux/miscdevice.h
+MODULE_ALIAS_MISCDEV(KVM_MINOR);
+MODULE_ALIAS(devname:kvm);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: PPC: fix couple of memory leaks in MPIC/XICS devices

[Alexander Graf]

On 04.09.2013, at 14:16, Paul Mackerras pau...@samba.org wrote:

 On Sun, Sep 01, 2013 at 03:53:46PM +0300, Gleb Natapov wrote:
 XICS failed to free xics structure on error path. MPIC destroy handler
 forgot to delete kvm_device structure.
 
 Signed-off-by: Gleb Natapov g...@redhat.com
 
 Acked-by: Paul Mackerras pau...@samba.org

Thanks, applied to kvm-ppc-queue.


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] KVM: PPC: Unify FP/VMX/VSX state handling between KVM and main kernel

[Alexander Graf]

On 15.10.2013, at 11:43, Paul Mackerras pau...@samba.org wrote:

 This series makes use of the new thread_fp_state and thread_vr_state
 structures to unify the way that floating-point and vector state is
 handled.  With both KVM and the main kernel using the same structures
 to store this state for various contexts, we can reduce the amount of
 code for loading and storing this state and also eliminate some extra
 copies.  Overall, this series removes a net 240 lines of code.
 
 This series also provides the foundation for implementing support for
 POWER8 transactional memory in KVM.
 
 These patches are against the merge of Ben Herrenschmidt's for-kvm
 branch and Alex Graf's kvm-ppc-queue branch.

Thanks, applied all to kvm-ppc-queue.


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] powerpc/kvm/booke: Fix build break due to stack frame size warning

[Scott Wood]

On Mon, 2013-11-25 at 04:26 -0600, Bharat Bhushan wrote:
 
  -Original Message-
  From: Wood Scott-B07421
  Sent: Saturday, November 23, 2013 3:22 AM
  To: Alexander Graf
  Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Wood Scott-B07421; 
  Bhushan
  Bharat-R65777
  Subject: [PATCH] powerpc/kvm/booke: Fix build break due to stack frame size
  warning
 
  Commit ce11e48b7fdd256ec68b932a89b397a790566031 (KVM: PPC: E500: Add
  userspace debug stub support) added struct thread_struct to the
  stack of kvmppc_vcpu_run().  thread_struct is 1152 bytes on my build,
  compared to 48 bytes for the recently-introduced struct debug_reg.
  Use the latter instead.
 
  This fixes the following error:
 
  cc1: warnings being treated as errors
  arch/powerpc/kvm/booke.c: In function 'kvmppc_vcpu_run':
  arch/powerpc/kvm/booke.c:760:1: error: the frame size of 1424 bytes is 
  larger
  than 1024 bytes
  make[2]: *** [arch/powerpc/kvm/booke.o] Error 1
  make[1]: *** [arch/powerpc/kvm] Error 2
  make[1]: *** Waiting for unfinished jobs
 
  Signed-off-by: Scott Wood scottw...@freescale.com
  Cc: Bharat Bhushan r65...@freescale.com
  ---
  Build tested only.  Bharat, please test.
 
 Tested with qemu debug stub; It works fine
 
 -Bharat

Alex, are you going to take this through your tree?

-Scott



--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html