Re: Installation of Windows 8 hangs with KVM

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 10:58:33PM +0100, Stefan Pietsch wrote:
 Hi all,
 
 when I run KVM with this command the Windows 8 installation stops with
 error code 0x005D:
 kvm -m 1024 -hda win8.img -cdrom windows_8_x86.iso
 
 After adding the option -cpu host the installation proceeds to a black
 screen and hangs.
 
 With Virtualbox the installation succeeds.
 The host CPU is an Intel Core Duo L2400.
  
 Do you have any suggestions?
 
 
What is your kernel/qemu version?

--
Gleb.
--
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 qom-cpu 01/11] target-i386: Don't set any KVM flag by default if KVM is disabled

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:02PM -0200, Eduardo Habkost wrote:
 This is a cleanup that tries to solve two small issues:
 
  - We don't need a separate kvm_pv_eoi_features variable just to keep a
constant calculated at compile-time, and this style would require
adding a separate variable (that's declared twice because of the
CONFIG_KVM ifdef) for each feature that's going to be enabled/disable
by machine-type compat code.
  - The pc-1.3 code is setting the kvm_pv_eoi flag on cpuid_kvm_features
even when KVM is disabled at runtime. This small incosistency in
the cpuid_kvm_features field isn't a problem today because
cpuid_kvm_features is ignored by the TCG code, but it may cause
unexpected problems later when refactoring the CPUID handling code.
 
 This patch eliminates the kvm_pv_eoi_features variable and simply uses
 CONFIG_KVM and kvm_enabled() inside the enable_kvm_pv_eoi() compat
 function, so it enables kvm_pv_eoi only if KVM is enabled. I believe
 this makes the behavior of enable_kvm_pv_eoi() clearer and easier to
 understand.
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
 ---
 Cc: kvm@vger.kernel.org
 Cc: Michael S. Tsirkin m...@redhat.com
 Cc: Gleb Natapov g...@redhat.com
 Cc: Marcelo Tosatti mtosa...@redhat.com
 
 Changes v2:
  - Coding style fix
 ---
  target-i386/cpu.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index 82685dc..e6435da 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -145,15 +145,17 @@ static uint32_t kvm_default_features = (1  
 KVM_FEATURE_CLOCKSOURCE) |
  (1  KVM_FEATURE_ASYNC_PF) |
  (1  KVM_FEATURE_STEAL_TIME) |
  (1  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
 -static const uint32_t kvm_pv_eoi_features = (0x1  KVM_FEATURE_PV_EOI);
  #else
  static uint32_t kvm_default_features = 0;
 -static const uint32_t kvm_pv_eoi_features = 0;
  #endif
  
  void enable_kvm_pv_eoi(void)
  {
 -kvm_default_features |= kvm_pv_eoi_features;
 +#ifdef CONFIG_KVM
You do not need ifdef here.

 +if (kvm_enabled()) {
 +kvm_default_features |= (1UL  KVM_FEATURE_PV_EOI);
 +}
 +#endif
  }
  
  void host_cpuid(uint32_t function, uint32_t count,
 -- 
 1.7.11.7

--
Gleb.
--
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: Book3S HV: Fix compilation without CONFIG_PPC_POWERNV

2013-01-06 Thread Alexander Graf

On 22.12.2012, at 15:09, Andreas Schwab wrote:

 Fixes this build breakage:
 
 arch/powerpc/kvm/book3s_hv_ras.c: In function ‘kvmppc_realmode_mc_power7’:
 arch/powerpc/kvm/book3s_hv_ras.c:126:23: error: ‘struct paca_struct’ has no 
 member named ‘opal_mc_evt’
 
 Signed-off-by: Andreas Schwab sch...@linux-m68k.org

Thanks, applied to kvm-ppc-3.8.

Paul, in the long run it might make sense to make HV KVM conditional on OPAL 
and just completely remove 970 support. At least if it significantly makes your 
life easier.


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/2] vhost: handle polling errors

2013-01-06 Thread Michael S. Tsirkin
On Sun, Jan 06, 2013 at 03:18:38PM +0800, Jason Wang wrote:
 Polling errors were ignored by vhost/vhost_net, this may lead to crash when
 trying to remove vhost from waitqueue when after the polling is failed. Solve
 this problem by:
 
 - checking the poll-wqh before trying to remove from waitqueue
 - report an error when poll() returns a POLLERR in vhost_start_poll()
 - report an error when vhost_start_poll() fails in
   vhost_vring_ioctl()/vhost_net_set_backend() which is used to notify the
   failure to userspace.
 - report an error in the data path in vhost_net when meet polling errors.
 
 After those changes, we can safely drop the tx polling state in vhost_net 
 since
 it was replaced by the checking of poll-wqh.
 
 Signed-off-by: Jason Wang jasow...@redhat.com
 ---
  drivers/vhost/net.c   |   74 
  drivers/vhost/vhost.c |   31 +++-
  drivers/vhost/vhost.h |2 +-
  3 files changed, 49 insertions(+), 58 deletions(-)
 
 diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
 index d10ad6f..125c1e5 100644
 --- a/drivers/vhost/net.c
 +++ b/drivers/vhost/net.c
 @@ -64,20 +64,10 @@ enum {
   VHOST_NET_VQ_MAX = 2,
  };
  
 -enum vhost_net_poll_state {
 - VHOST_NET_POLL_DISABLED = 0,
 - VHOST_NET_POLL_STARTED = 1,
 - VHOST_NET_POLL_STOPPED = 2,
 -};
 -
  struct vhost_net {
   struct vhost_dev dev;
   struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
   struct vhost_poll poll[VHOST_NET_VQ_MAX];
 - /* Tells us whether we are polling a socket for TX.
 -  * We only do this when socket buffer fills up.
 -  * Protected by tx vq lock. */
 - enum vhost_net_poll_state tx_poll_state;
   /* Number of TX recently submitted.
* Protected by tx vq lock. */
   unsigned tx_packets;
 @@ -155,24 +145,6 @@ static void copy_iovec_hdr(const struct iovec *from, 
 struct iovec *to,
   }
  }
  
 -/* Caller must have TX VQ lock */
 -static void tx_poll_stop(struct vhost_net *net)
 -{
 - if (likely(net-tx_poll_state != VHOST_NET_POLL_STARTED))
 - return;
 - vhost_poll_stop(net-poll + VHOST_NET_VQ_TX);
 - net-tx_poll_state = VHOST_NET_POLL_STOPPED;
 -}
 -
 -/* Caller must have TX VQ lock */
 -static void tx_poll_start(struct vhost_net *net, struct socket *sock)
 -{
 - if (unlikely(net-tx_poll_state != VHOST_NET_POLL_STOPPED))
 - return;
 - vhost_poll_start(net-poll + VHOST_NET_VQ_TX, sock-file);
 - net-tx_poll_state = VHOST_NET_POLL_STARTED;
 -}
 -
  /* In case of DMA done not in order in lower device driver for some reason.
   * upend_idx is used to track end of used idx, done_idx is used to track head
   * of used idx. Once lower device DMA done contiguously, we will signal KVM
 @@ -227,6 +199,7 @@ static void vhost_zerocopy_callback(struct ubuf_info 
 *ubuf, bool success)
  static void handle_tx(struct vhost_net *net)
  {
   struct vhost_virtqueue *vq = net-dev.vqs[VHOST_NET_VQ_TX];
 + struct vhost_poll *poll = net-poll + VHOST_NET_VQ_TX;
   unsigned out, in, s;
   int head;
   struct msghdr msg = {
 @@ -252,7 +225,8 @@ static void handle_tx(struct vhost_net *net)
   wmem = atomic_read(sock-sk-sk_wmem_alloc);
   if (wmem = sock-sk-sk_sndbuf) {
   mutex_lock(vq-mutex);
 - tx_poll_start(net, sock);
 + if (vhost_poll_start(poll, sock-file))
 + vq_err(vq, Fail to start TX polling\n);

s/Fail/Failed/

A question though: how can this happen? Could you clarify please?
Maybe we can find a way to prevent this error?

   mutex_unlock(vq-mutex);
   return;
   }
 @@ -261,7 +235,7 @@ static void handle_tx(struct vhost_net *net)
   vhost_disable_notify(net-dev, vq);
  
   if (wmem  sock-sk-sk_sndbuf / 2)
 - tx_poll_stop(net);
 + vhost_poll_stop(poll);
   hdr_size = vq-vhost_hlen;
   zcopy = vq-ubufs;
  
 @@ -283,8 +257,10 @@ static void handle_tx(struct vhost_net *net)
  
   wmem = atomic_read(sock-sk-sk_wmem_alloc);
   if (wmem = sock-sk-sk_sndbuf * 3 / 4) {
 - tx_poll_start(net, sock);
 - set_bit(SOCK_ASYNC_NOSPACE, sock-flags);
 + if (vhost_poll_start(poll, sock-file))
 + vq_err(vq, Fail to start TX 
 polling\n);
 + else
 + set_bit(SOCK_ASYNC_NOSPACE, 
 sock-flags);
   break;
   }
   /* If more outstanding DMAs, queue the work.
 @@ -294,8 +270,10 @@ static void handle_tx(struct vhost_net *net)
   (vq-upend_idx - vq-done_idx) :
   (vq-upend_idx + UIO_MAXIOV - vq-done_idx);
   if (unlikely(num_pends  VHOST_MAX_PEND)) {
 - 

[PULL 3.8 0/2] ppc patch queue 2013-01-06 for 3.8

2013-01-06 Thread Alexander Graf
Hi Marcelo / Gleb,

This is my current patch queue for ppc against 3.8.
It contains a compile fix for Book3S HV KVM.

Please pull.

Alex


The following changes since commit 18eb54cf4a9cd4b74f926209be208366415edfa8:
  Gleb Natapov (1):
Merge branch 'kvm-ppc-3.8' of https://github.com/agraf/linux-2.6 into 
master

are available in the git repository at:

  git://github.com/agraf/linux-2.6.git kvm-ppc-3.8

Alexander Graf (1):
  Merge commit 'origin/master' into kvm-ppc-3.8

Andreas Schwab (1):
  KVM: PPC: Book3S HV: Fix compilation without CONFIG_PPC_POWERNV

 arch/powerpc/kvm/book3s_hv_ras.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)
--
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 1/1] KVM: PPC: Book3S HV: Fix compilation without CONFIG_PPC_POWERNV

2013-01-06 Thread Alexander Graf
From: Andreas Schwab sch...@linux-m68k.org

Fixes this build breakage:

arch/powerpc/kvm/book3s_hv_ras.c: In function ‘kvmppc_realmode_mc_power7’:
arch/powerpc/kvm/book3s_hv_ras.c:126:23: error: ‘struct paca_struct’ has no 
member named ‘opal_mc_evt’

Signed-off-by: Andreas Schwab sch...@linux-m68k.org
Signed-off-by: Alexander Graf ag...@suse.de
---
 arch/powerpc/kvm/book3s_hv_ras.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_ras.c b/arch/powerpc/kvm/book3s_hv_ras.c
index 35f3cf0..a353c48 100644
--- a/arch/powerpc/kvm/book3s_hv_ras.c
+++ b/arch/powerpc/kvm/book3s_hv_ras.c
@@ -79,7 +79,9 @@ static void flush_tlb_power7(struct kvm_vcpu *vcpu)
 static long kvmppc_realmode_mc_power7(struct kvm_vcpu *vcpu)
 {
unsigned long srr1 = vcpu-arch.shregs.msr;
+#ifdef CONFIG_PPC_POWERNV
struct opal_machine_check_event *opal_evt;
+#endif
long handled = 1;
 
if (srr1  SRR1_MC_LDSTERR) {
@@ -117,6 +119,7 @@ static long kvmppc_realmode_mc_power7(struct kvm_vcpu *vcpu)
handled = 0;
}
 
+#ifdef CONFIG_PPC_POWERNV
/*
 * See if OPAL has already handled the condition.
 * We assume that if the condition is recovered then OPAL
@@ -131,6 +134,7 @@ static long kvmppc_realmode_mc_power7(struct kvm_vcpu *vcpu)
 
if (handled)
opal_evt-in_use = 0;
+#endif
 
return handled;
 }
-- 
1.6.0.2

--
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 qom-cpu 02/11] target-i386: Disable kvm_mmu_op by default on pc-1.4

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:03PM -0200, Eduardo Habkost wrote:
 The kvm_mmu_op feature was removed from the kernel since v3.3 (released
 in March 2012), it was marked for removal since January 2011 and it's
 slower than shadow or hardware assisted paging (see kernel commit
 fb92045843). It doesn't make sense to keep it enabled by default.
 
Actually it was effectively removed Oct 1 2009 by a68a6a7282373. After 3
and a half years of not having it I think we can safely drop it without
trying to preserve it in older machine types.

 Also, keeping it enabled by default would cause unnecessary hassle when
 libvirt start using the enforce option.
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
 ---
 Cc: kvm@vger.kernel.org
 Cc: Michael S. Tsirkin m...@redhat.com
 Cc: Gleb Natapov g...@redhat.com
 Cc: Marcelo Tosatti mtosa...@redhat.com
 Cc: libvir-l...@redhat.com
 Cc: Jiri Denemark jdene...@redhat.com
 
 I was planning to reverse the logic of the compat init functions and
 make pc_init_pci_1_3() enable kvm_mmu_op and then call pc_init_pci_1_4()
 instead. But that would require changing pc_init_pci_no_kvmclock() and
 pc_init_isa() as well. So to keep the changes simple, I am keeping the
 pattern used when pc_init_pci_1_3() was introduced, making
 pc_init_pci_1_4() disable kvm_mmu_op and then call pc_init_pci_1_3().
 
 Changes v2:
  - Coding style fix
  - Removed redundant comments above machine init functions
 ---
  hw/pc_piix.c  | 9 -
  target-i386/cpu.c | 9 +
  target-i386/cpu.h | 1 +
  3 files changed, 18 insertions(+), 1 deletion(-)
 
 diff --git a/hw/pc_piix.c b/hw/pc_piix.c
 index 99747a7..a32af6a 100644
 --- a/hw/pc_piix.c
 +++ b/hw/pc_piix.c
 @@ -217,6 +217,7 @@ static void pc_init1(MemoryRegion *system_memory,
  }
  }
  
 +/* machine init function for pc-0.14 - pc-1.2 */
  static void pc_init_pci(QEMUMachineInitArgs *args)
  {
  ram_addr_t ram_size = args-ram_size;
 @@ -238,6 +239,12 @@ static void pc_init_pci_1_3(QEMUMachineInitArgs *args)
  pc_init_pci(args);
  }
  
 +static void pc_init_pci_1_4(QEMUMachineInitArgs *args)
 +{
 +disable_kvm_mmu_op();
 +pc_init_pci_1_3(args);
 +}
 +
  static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
  {
  ram_addr_t ram_size = args-ram_size;
 @@ -285,7 +292,7 @@ static QEMUMachine pc_machine_v1_4 = {
  .name = pc-1.4,
  .alias = pc,
  .desc = Standard PC,
 -.init = pc_init_pci_1_3,
 +.init = pc_init_pci_1_4,
  .max_cpus = 255,
  .is_default = 1,
  };
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index e6435da..c83a566 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -158,6 +158,15 @@ void enable_kvm_pv_eoi(void)
  #endif
  }
  
 +void disable_kvm_mmu_op(void)
 +{
 +#ifdef CONFIG_KVM
No need for ifdef here too.

 +if (kvm_enabled()) {
 +kvm_default_features = ~(1UL  KVM_FEATURE_MMU_OP);
clear_bit()

 +}
 +#endif
 +}
 +
  void host_cpuid(uint32_t function, uint32_t count,
  uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
  {
 diff --git a/target-i386/cpu.h b/target-i386/cpu.h
 index 1283537..27c8d0c 100644
 --- a/target-i386/cpu.h
 +++ b/target-i386/cpu.h
 @@ -1219,5 +1219,6 @@ void do_smm_enter(CPUX86State *env1);
  void cpu_report_tpr_access(CPUX86State *env, TPRAccess access);
  
  void enable_kvm_pv_eoi(void);
 +void disable_kvm_mmu_op(void);
  
  #endif /* CPU_I386_H */
 -- 
 1.7.11.7

--
Gleb.
--
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 qom-cpu 03/11] target-i386: kvm: -cpu host: Use GET_SUPPORTED_CPUID for SVM features

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:04PM -0200, Eduardo Habkost wrote:
 The existing -cpu host code simply set every bit inside svm_features
 (initializing it to -1), and that makes it impossible to make the
 enforce/check options work properly when the user asks for SVM features
 explicitly in the command-line.
 
 So, instead of initializing svm_features to -1, use GET_SUPPORTED_CPUID
 to fill only the bits that are supported by the host (just like we do
 for all other CPUID feature words inside kvm_cpu_fill_host()).
 
 This will keep the existing behavior (as filter_features_for_kvm()
 already uses GET_SUPPORTED_CPUID to filter svm_features), but will allow
 us to properly check for KVM features inside
 kvm_check_features_against_host() later.
 
 For example, we will be able to make this:
 
   $ qemu-system-x86_64 -cpu ...,+pfthreshold,enforce
 
 refuse to start if the SVM pfthreshold feature is not supported by the
 host (after we fix kvm_check_features_against_host() to check SVM flags
 as well).
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com

 ---
 Changes v2:
  - Coding style (indentation) fix
 
 Cc: Gleb Natapov g...@redhat.com
 Cc: Marcelo Tosatti mtosa...@redhat.com
 Cc: Joerg Roedel j...@8bytes.org
 Cc: kvm@vger.kernel.org
 ---
  target-i386/cpu.c | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index c83a566..c49a97c 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -908,13 +908,10 @@ static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def)
  }
  }
  
 -/*
 - * Every SVM feature requires emulation support in KVM - so we can't just
 - * read the host features here. KVM might even support SVM features not
 - * available on the host hardware. Just set all bits and mask out the
 - * unsupported ones later.
 - */
 -x86_cpu_def-svm_features = -1;
 +/* Other KVM-specific feature fields: */
 +x86_cpu_def-svm_features =
 +kvm_arch_get_supported_cpuid(s, 0x800A, 0, R_EDX);
 +
  #endif /* CONFIG_KVM */
  }
  
 -- 
 1.7.11.7

--
Gleb.
--
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 qom-cpu 04/11] target-i386: kvm: Enable all supported KVM features for -cpu host

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:05PM -0200, Eduardo Habkost wrote:
 When using -cpu host, we don't need to use the kvm_default_features
 variable, as the user is explicitly asking QEMU to enable all feature
 supported by the host.
 
 This changes the kvm_cpu_fill_host() code to use GET_SUPPORTED_CPUID to
 initialize the kvm_features field, so we get all host KVM features
 enabled.
 
 This will also allow use to properly check/enforce KVM features inside
 kvm_check_features_against_host() later. For example, we will be able to
 make this:
 
   $ qemu-system-x86_64 -cpu ...,+kvm_pv_eoi,enforce
 
 refuse to start if kvm_pv_eoi is not supported by the host (after we fix
 kvm_check_features_against_host() to check KVM flags as well).
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com

 ---
 Changes v2:
  - Coding style (indentation) fix
 
 Cc: Gleb Natapov g...@redhat.com
 Cc: Michael S. Tsirkin m...@redhat.com
 Cc: Marcelo Tosatti mtosa...@redhat.com
 Cc: kvm@vger.kernel.org
 ---
  target-i386/cpu.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index c49a97c..e916ae0 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -911,6 +911,8 @@ static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def)
  /* Other KVM-specific feature fields: */
  x86_cpu_def-svm_features =
  kvm_arch_get_supported_cpuid(s, 0x800A, 0, R_EDX);
 +x86_cpu_def-kvm_features =
 +kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
  
  #endif /* CONFIG_KVM */
  }
 -- 
 1.7.11.7

--
Gleb.
--
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 qom-cpu 05/11] target-i386: check/enforce: Fix CPUID leaf numbers on error messages

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:06PM -0200, Eduardo Habkost wrote:
 The -cpu check/enforce warnings are printing incorrect information about the
 missing flags. There are no feature flags on CPUID leaves 0 and 0x8000, 
 but
 there were references to 0 and 0x8000 in the table at
 kvm_check_features_against_host().
 
 This changes the model_features_t struct to contain the register number as
 well, so the error messages print the correct CPUID leaf+register information,
 instead of wrong CPUID leaf numbers.
 
 This also changes the format of the error messages, so they follow the
 CPUID.leaf.register.name [bit offset] convention used on Intel
 documentation. Example output:
 
 $ qemu-system-x86_64 -machine pc-1.0,accel=kvm -cpu 
 Opteron_G4,+ia64,enforce
 warning: host doesn't support requested feature: CPUID.01H:EDX.ia64 [bit 
 30]
 warning: host doesn't support requested feature: CPUID.01H:ECX.xsave [bit 
 26]
 warning: host doesn't support requested feature: CPUID.01H:ECX.avx [bit 
 28]
 warning: host doesn't support requested feature: CPUID.8001H:ECX.abm 
 [bit 5]
 warning: host doesn't support requested feature: 
 CPUID.8001H:ECX.sse4a [bit 6]
 warning: host doesn't support requested feature: 
 CPUID.8001H:ECX.misalignsse [bit 7]
 warning: host doesn't support requested feature: 
 CPUID.8001H:ECX.3dnowprefetch [bit 8]
 warning: host doesn't support requested feature: CPUID.8001H:ECX.xop 
 [bit 11]
 warning: host doesn't support requested feature: CPUID.8001H:ECX.fma4 
 [bit 16]
 Unable to find x86 CPU definition
 $
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com
But see the question below.

 ---
 Cc: Gleb Natapov g...@redhat.com
 Cc: Marcelo Tosatti mtosa...@redhat.com
 Cc: kvm@vger.kernel.org
 
 Changes v2:
  - Coding style fixes
  - Add assert() for invalid register numbers on
unavailable_host_feature()
 ---
  target-i386/cpu.c | 42 +-
  target-i386/cpu.h |  3 +++
  2 files changed, 36 insertions(+), 9 deletions(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index e916ae0..c3e5db8 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -124,6 +124,25 @@ static const char *cpuid_7_0_ebx_feature_name[] = {
  NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
  };
  
 +const char *get_register_name_32(unsigned int reg)
 +{
 +static const char *reg_names[CPU_NB_REGS32] = {
 +[R_EAX] = EAX,
 +[R_ECX] = ECX,
 +[R_EDX] = EDX,
 +[R_EBX] = EBX,
 +[R_ESP] = ESP,
 +[R_EBP] = EBP,
 +[R_ESI] = ESI,
 +[R_EDI] = EDI,
 +};
 +
 +if (reg  CPU_NB_REGS32) {
 +return NULL;
 +}
 +return reg_names[reg];
 +}
 +
  /* collects per-function cpuid data
   */
  typedef struct model_features_t {
 @@ -132,7 +151,8 @@ typedef struct model_features_t {
  uint32_t check_feat;
  const char **flag_names;
  uint32_t cpuid;
 -} model_features_t;
 +int reg;
 +} model_features_t;
  
  int check_cpuid = 0;
  int enforce_cpuid = 0;
 @@ -923,10 +943,13 @@ static int unavailable_host_feature(struct 
 model_features_t *f, uint32_t mask)
  
  for (i = 0; i  32; ++i)
  if (1  i  mask) {
 -fprintf(stderr, warning: host cpuid %04x_%04x lacks requested
 - flag '%s' [0x%08x]\n,
 -f-cpuid  16, f-cpuid  0x,
 -f-flag_names[i] ? f-flag_names[i] : [reserved], mask);
 +const char *reg = get_register_name_32(f-reg);
 +assert(reg);
 +fprintf(stderr, warning: host doesn't support requested 
 feature: 
 +CPUID.%02XH:%s%s%s [bit %d]\n,
 +f-cpuid, reg,
 +f-flag_names[i] ? . : ,
 +f-flag_names[i] ? f-flag_names[i] : , i);
  break;
  }
  return 0;
 @@ -945,13 +968,14 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  int rv, i;
  struct model_features_t ft[] = {
  {guest_def-features, host_def.features,
 -~0, feature_name, 0x},
 +~0, feature_name, 0x0001, R_EDX},
  {guest_def-ext_features, host_def.ext_features,
 -~CPUID_EXT_HYPERVISOR, ext_feature_name, 0x0001},
 +~CPUID_EXT_HYPERVISOR, ext_feature_name, 0x0001, R_ECX},
  {guest_def-ext2_features, host_def.ext2_features,
 -~PPRO_FEATURES, ext2_feature_name, 0x8000},
 +~PPRO_FEATURES, ext2_feature_name, 0x8001, R_EDX},
  {guest_def-ext3_features, host_def.ext3_features,
 -~CPUID_EXT3_SVM, ext3_feature_name, 0x8001}};
 +~CPUID_EXT3_SVM, ext3_feature_name, 0x8001, R_ECX}
Why do we exclude PPRO_FEATURES/CPUID_EXT3_SVM from been checked?

 +};
  
  assert(kvm_enabled());
  
 diff --git a/target-i386/cpu.h b/target-i386/cpu.h
 index 

Re: [Qemu-devel] [PATCH qom-cpu 05/11] target-i386: check/enforce: Fix CPUID leaf numbers on error messages

2013-01-06 Thread Gleb Natapov
On Sun, Jan 06, 2013 at 04:12:54PM +0200, Gleb Natapov wrote:
 On Fri, Jan 04, 2013 at 08:01:06PM -0200, Eduardo Habkost wrote:
  The -cpu check/enforce warnings are printing incorrect information about the
  missing flags. There are no feature flags on CPUID leaves 0 and 0x8000, 
  but
  there were references to 0 and 0x8000 in the table at
  kvm_check_features_against_host().
  
  This changes the model_features_t struct to contain the register number as
  well, so the error messages print the correct CPUID leaf+register 
  information,
  instead of wrong CPUID leaf numbers.
  
  This also changes the format of the error messages, so they follow the
  CPUID.leaf.register.name [bit offset] convention used on Intel
  documentation. Example output:
  
  $ qemu-system-x86_64 -machine pc-1.0,accel=kvm -cpu 
  Opteron_G4,+ia64,enforce
  warning: host doesn't support requested feature: CPUID.01H:EDX.ia64 
  [bit 30]
  warning: host doesn't support requested feature: CPUID.01H:ECX.xsave 
  [bit 26]
  warning: host doesn't support requested feature: CPUID.01H:ECX.avx [bit 
  28]
  warning: host doesn't support requested feature: 
  CPUID.8001H:ECX.abm [bit 5]
  warning: host doesn't support requested feature: 
  CPUID.8001H:ECX.sse4a [bit 6]
  warning: host doesn't support requested feature: 
  CPUID.8001H:ECX.misalignsse [bit 7]
  warning: host doesn't support requested feature: 
  CPUID.8001H:ECX.3dnowprefetch [bit 8]
  warning: host doesn't support requested feature: 
  CPUID.8001H:ECX.xop [bit 11]
  warning: host doesn't support requested feature: 
  CPUID.8001H:ECX.fma4 [bit 16]
  Unable to find x86 CPU definition
  $
  
  Signed-off-by: Eduardo Habkost ehabk...@redhat.com
 Reviewed-by: Gleb Natapov g...@redhat.com
 But see the question below.
Never mind. I found the answer in the following patches :)

 
  ---
  Cc: Gleb Natapov g...@redhat.com
  Cc: Marcelo Tosatti mtosa...@redhat.com
  Cc: kvm@vger.kernel.org
  
  Changes v2:
   - Coding style fixes
   - Add assert() for invalid register numbers on
 unavailable_host_feature()
  ---
   target-i386/cpu.c | 42 +-
   target-i386/cpu.h |  3 +++
   2 files changed, 36 insertions(+), 9 deletions(-)
  
  diff --git a/target-i386/cpu.c b/target-i386/cpu.c
  index e916ae0..c3e5db8 100644
  --- a/target-i386/cpu.c
  +++ b/target-i386/cpu.c
  @@ -124,6 +124,25 @@ static const char *cpuid_7_0_ebx_feature_name[] = {
   NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
   };
   
  +const char *get_register_name_32(unsigned int reg)
  +{
  +static const char *reg_names[CPU_NB_REGS32] = {
  +[R_EAX] = EAX,
  +[R_ECX] = ECX,
  +[R_EDX] = EDX,
  +[R_EBX] = EBX,
  +[R_ESP] = ESP,
  +[R_EBP] = EBP,
  +[R_ESI] = ESI,
  +[R_EDI] = EDI,
  +};
  +
  +if (reg  CPU_NB_REGS32) {
  +return NULL;
  +}
  +return reg_names[reg];
  +}
  +
   /* collects per-function cpuid data
*/
   typedef struct model_features_t {
  @@ -132,7 +151,8 @@ typedef struct model_features_t {
   uint32_t check_feat;
   const char **flag_names;
   uint32_t cpuid;
  -} model_features_t;
  +int reg;
  +} model_features_t;
   
   int check_cpuid = 0;
   int enforce_cpuid = 0;
  @@ -923,10 +943,13 @@ static int unavailable_host_feature(struct 
  model_features_t *f, uint32_t mask)
   
   for (i = 0; i  32; ++i)
   if (1  i  mask) {
  -fprintf(stderr, warning: host cpuid %04x_%04x lacks requested
  - flag '%s' [0x%08x]\n,
  -f-cpuid  16, f-cpuid  0x,
  -f-flag_names[i] ? f-flag_names[i] : [reserved], mask);
  +const char *reg = get_register_name_32(f-reg);
  +assert(reg);
  +fprintf(stderr, warning: host doesn't support requested 
  feature: 
  +CPUID.%02XH:%s%s%s [bit %d]\n,
  +f-cpuid, reg,
  +f-flag_names[i] ? . : ,
  +f-flag_names[i] ? f-flag_names[i] : , i);
   break;
   }
   return 0;
  @@ -945,13 +968,14 @@ static int kvm_check_features_against_host(x86_def_t 
  *guest_def)
   int rv, i;
   struct model_features_t ft[] = {
   {guest_def-features, host_def.features,
  -~0, feature_name, 0x},
  +~0, feature_name, 0x0001, R_EDX},
   {guest_def-ext_features, host_def.ext_features,
  -~CPUID_EXT_HYPERVISOR, ext_feature_name, 0x0001},
  +~CPUID_EXT_HYPERVISOR, ext_feature_name, 0x0001, R_ECX},
   {guest_def-ext2_features, host_def.ext2_features,
  -~PPRO_FEATURES, ext2_feature_name, 0x8000},
  +~PPRO_FEATURES, ext2_feature_name, 0x8001, R_EDX},
   {guest_def-ext3_features, host_def.ext3_features,
  -~CPUID_EXT3_SVM, 

Re: [PATCH qom-cpu 06/11] target-i386: check/enforce: Do not ignore hypervisor flag

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:07PM -0200, Eduardo Habkost wrote:
 We don't need any hack to ignore CPUID_EXT_HYPERVISOR anymore, because
 kvm_arch_get_supported_cpuid() now set CPUID_EXT_HYPERVISOR properly.
 So, this shouldn't introduce any behavior change, but it makes the code
 simpler.
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com

 ---
 My goal is to eliminate the check_feat field completely, as
 kvm_arch_get_supported_cpuid() should now really return all the bits we
 can set on all CPUID leaves.
 ---
  target-i386/cpu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index c3e5db8..42c4c99 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -970,7 +970,7 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  {guest_def-features, host_def.features,
  ~0, feature_name, 0x0001, R_EDX},
  {guest_def-ext_features, host_def.ext_features,
 -~CPUID_EXT_HYPERVISOR, ext_feature_name, 0x0001, R_ECX},
 +~0, ext_feature_name, 0x0001, R_ECX},
  {guest_def-ext2_features, host_def.ext2_features,
  ~PPRO_FEATURES, ext2_feature_name, 0x8001, R_EDX},
  {guest_def-ext3_features, host_def.ext3_features,
 -- 
 1.7.11.7
 
 --
 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

--
Gleb.
--
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: [Qemu-devel] [PATCH qom-cpu 08/11] target-i386: check/enforce: Check SVM flag support as well

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:09PM -0200, Eduardo Habkost wrote:
 When nested SVM is supported, the kernel returns the SVM flag on
 GET_SUPPORTED_CPUID[1], so we can check the SVM flag safely on
 kvm_check_features_against_host().
 
 I don't know why the original code ignored the SVM flag. Maybe it was
 because kvm_cpu_fill_host() used the CPUID instruction directly instead
 of GET_SUPPORTED_CPUID
 
 [1] Older kernels (before v2.6.37) returned the SVM flag even if nested
 SVM was _not_ supported. So the only cases where this patch should
 change behavior is when SVM is being requested by the user or the
 CPU model, but not supported by the host. And on these cases we
 really want QEMU to abort if the enforce option is set.
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com

 ---
 Cc: Joerg Roedel j...@8bytes.org
 Cc: kvm@vger.kernel.org
 Cc: libvir-l...@redhat.com
 Cc: Jiri Denemark jdene...@redhat.com
 
 I'm CCing libvirt people in case having SVM enabled by default may cause
 trouble when libvirt starts using the enforce flag. I don't know if
 libvirt expects most of the QEMU CPU models to have nested SVM enabled.
 
 Changes v2:
  - Coding style fix
 ---
  target-i386/cpu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index ce64b98..a9dd959 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -974,7 +974,7 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  {guest_def-ext2_features, host_def.ext2_features,
  ~0, ext2_feature_name, 0x8001, R_EDX},
  {guest_def-ext3_features, host_def.ext3_features,
 -~CPUID_EXT3_SVM, ext3_feature_name, 0x8001, R_ECX}
 +~0, ext3_feature_name, 0x8001, R_ECX}
  };
  
  assert(kvm_enabled());
 -- 
 1.7.11.7
 

--
Gleb.
--
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: [Qemu-devel] [PATCH qom-cpu 09/11] target-i386: check/enforce: Eliminate check_feat field

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:10PM -0200, Eduardo Habkost wrote:
 Now that all entries have check_feat=~0 on
 kvm_check_features_against_host(), we can eliminate check_feat entirely
 and make the code check all bits.
 
 This patch shouldn't introduce any behavior change, as check_feat is set
 to ~0 on all entries.
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com

 ---
 Changes v2:
  - Coding style fix
 ---
  target-i386/cpu.c | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index a9dd959..1c3c7e1 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -148,7 +148,6 @@ const char *get_register_name_32(unsigned int reg)
  typedef struct model_features_t {
  uint32_t *guest_feat;
  uint32_t *host_feat;
 -uint32_t check_feat;
  const char **flag_names;
  uint32_t cpuid;
  int reg;
 @@ -956,8 +955,7 @@ static int unavailable_host_feature(struct 
 model_features_t *f, uint32_t mask)
  }
  
  /* best effort attempt to inform user requested cpu flags aren't making
 - * their way to the guest.  Note: ft[].check_feat ideally should be
 - * specified via a guest_def field to suppress report of extraneous flags.
 + * their way to the guest.
   *
   * This function may be called only if KVM is enabled.
   */
 @@ -968,13 +966,13 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  int rv, i;
  struct model_features_t ft[] = {
  {guest_def-features, host_def.features,
 -~0, feature_name, 0x0001, R_EDX},
 +feature_name, 0x0001, R_EDX},
  {guest_def-ext_features, host_def.ext_features,
 -~0, ext_feature_name, 0x0001, R_ECX},
 +ext_feature_name, 0x0001, R_ECX},
  {guest_def-ext2_features, host_def.ext2_features,
 -~0, ext2_feature_name, 0x8001, R_EDX},
 +ext2_feature_name, 0x8001, R_EDX},
  {guest_def-ext3_features, host_def.ext3_features,
 -~0, ext3_feature_name, 0x8001, R_ECX}
 +ext3_feature_name, 0x8001, R_ECX}
  };
  
  assert(kvm_enabled());
 @@ -982,7 +980,7 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  kvm_cpu_fill_host(host_def);
  for (rv = 0, i = 0; i  ARRAY_SIZE(ft); ++i)
  for (mask = 1; mask; mask = 1)
 -if (ft[i].check_feat  mask  *ft[i].guest_feat  mask 
 +if (*ft[i].guest_feat  mask 
  !(*ft[i].host_feat  mask)) {
  unavailable_host_feature(ft[i], mask);
  rv = 1;
 -- 
 1.7.11.7
 

--
Gleb.
--
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: [Qemu-devel] [PATCH qom-cpu 10/11] target-i386: Call kvm_check_features_against_host() only if CONFIG_KVM is set

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:11PM -0200, Eduardo Habkost wrote:
 This will be necessary once kvm_check_features_against_host() starts
 using KVM-specific definitions (so it won't compile anymore if
 CONFIG_KVM is not set).
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
 ---
  target-i386/cpu.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index 1c3c7e1..876b0f6 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -936,6 +936,7 @@ static void kvm_cpu_fill_host(x86_def_t *x86_cpu_def)
  #endif /* CONFIG_KVM */
  }
  
 +#ifdef CONFIG_KVM
  static int unavailable_host_feature(struct model_features_t *f, uint32_t 
 mask)
  {
  int i;
 @@ -987,6 +988,7 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  }
  return rv;
  }
 +#endif
  
  static void x86_cpuid_version_get_family(Object *obj, Visitor *v, void 
 *opaque,
   const char *name, Error **errp)
 @@ -1410,10 +1412,12 @@ static int cpu_x86_parse_featurestr(x86_def_t 
 *x86_cpu_def, char *features)
  x86_cpu_def-kvm_features = ~minus_kvm_features;
  x86_cpu_def-svm_features = ~minus_svm_features;
  x86_cpu_def-cpuid_7_0_ebx_features = ~minus_7_0_ebx_features;
 +#ifdef CONFIG_KVM
  if (check_cpuid  kvm_enabled()) {
  if (kvm_check_features_against_host(x86_cpu_def)  enforce_cpuid)
  goto error;
  }
 +#endif
Provide kvm_check_features_against_host() stub if !CONFIG_KVM and drop
ifdef here.

  return 0;
  
  error:
 -- 
 1.7.11.7
 

--
Gleb.
--
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 qom-cpu 11/11] target-i386: check/enforce: Check all feature words

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:12PM -0200, Eduardo Habkost wrote:
 This adds the following feature words to the list of flags to be checked
 by kvm_check_features_against_host():
 
  - cpuid_7_0_ebx_features
  - ext4_features
  - kvm_features
  - svm_features
 
 This will ensure the enforce flag works as it should: it won't allow
 QEMU to be started unless every flag that was requested by the user or
 defined in the CPU model is supported by the host.
 
 This patch may cause existing configurations where enforce wasn't
 preventing QEMU from being started to abort QEMU. But that's exactly the
 point of this patch: if a flag was not supported by the host and QEMU
 wasn't aborting, it was a bug in the enforce code.
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
 ---
 Cc: Gleb Natapov g...@redhat.com
 Cc: Marcelo Tosatti mtosa...@redhat.com
 Cc: kvm@vger.kernel.org
 Cc: libvir-l...@redhat.com
 Cc: Jiri Denemark jdene...@redhat.com
 
 CCing libvirt people, as this is directly related to the planned usage
 of the enforce flag by libvirt.
 
 The libvirt team probably has a problem in their hands: libvirt should
 use enforce to make sure all requested flags are making their way into
 the guest (so the resulting CPU is always the same, on any host), but
 users may have existing working configurations where a flag is not
 supported by the guest and the user really doesn't care about it. Those
 configurations will necessarily break when libvirt starts using
 enforce.
 
 One example where it may cause trouble for common setups: pc-1.3 wants
 the kvm_pv_eoi flag enabled by default (so enforce will make sure it
 is enabled), but the user may have an existing VM running on a host
 without pv_eoi support. That setup is unsafe today because
 live-migration between different host kernel versions may enable/disable
 pv_eoi silently (that's why we need the enforce flag to be used by
 libvirt), but the user probably would like to be able to live-migrate
 that VM anyway (and have libvirt to just do the right thing).
 
 One possible solution to libvirt is to use enforce only on newer
 machine-types, so existing machines with older machine-types will keep
 the unsafe host-dependent-ABI behavior, but at least would keep
 live-migration working in case the user is careful.
 
 I really don't know what the libvirt team prefers, but that's the
 situation today. The longer we take to make enforce strict as it
 should and make libvirt finally use it, more users will have VMs with
 migration-unsafe unpredictable guest ABIs.
 
 Changes v2:
  - Coding style fix
 ---
  target-i386/cpu.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index 876b0f6..52727ad 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -955,8 +955,9 @@ static int unavailable_host_feature(struct 
 model_features_t *f, uint32_t mask)
  return 0;
  }
  
 -/* best effort attempt to inform user requested cpu flags aren't making
 - * their way to the guest.
 +/* Check if all requested cpu flags are making their way to the guest
 + *
 + * Returns 0 if all flags are supported by the host, non-zero otherwise.
   *
   * This function may be called only if KVM is enabled.
   */
 @@ -973,7 +974,15 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  {guest_def-ext2_features, host_def.ext2_features,
  ext2_feature_name, 0x8001, R_EDX},
  {guest_def-ext3_features, host_def.ext3_features,
 -ext3_feature_name, 0x8001, R_ECX}
 +ext3_feature_name, 0x8001, R_ECX},
 +{guest_def-ext4_features, host_def.ext4_features,
 +NULL, 0xC001, R_EDX},
Since there is not name array for ext4_features they cannot be added or
removed on the command line hence no need to check them, no?

 +{guest_def-cpuid_7_0_ebx_features, 
 host_def.cpuid_7_0_ebx_features,
 +cpuid_7_0_ebx_feature_name, 7, R_EBX},
 +{guest_def-svm_features, host_def.svm_features,
 +svm_feature_name, 0x800A, R_EDX},
 +{guest_def-kvm_features, host_def.kvm_features,
 +kvm_feature_name, KVM_CPUID_FEATURES, R_EAX},
  };
  
  assert(kvm_enabled());
 -- 
 1.7.11.7

--
Gleb.
--
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: [Qemu-devel] [PATCH qom-cpu 07/11] target-i386: check/enforce: Check all CPUID.80000001H.EDX bits

2013-01-06 Thread Gleb Natapov
On Fri, Jan 04, 2013 at 08:01:08PM -0200, Eduardo Habkost wrote:
 I have no idea why PPRO_FEATURES was being ignored on the check of the
 CPUID.8001H.EDX bits. I believe it was a mistake, and it was
 supposed to be ~(PPRO_FEATURES  CPUID_EXT2_AMD_ALIASES) or just
 ~CPUID_EXT2_AMD_ALIASES, because some time ago kvm_cpu_fill_host() used
 the CPUID instruction directly (instead of
 kvm_arch_get_supported_cpuid()).
 
 But now kvm_cpu_fill_host() use kvm_arch_get_supported_cpuid(), and
 kvm_arch_get_supported_cpuid() returns all supported bits for
 CPUID.8001H.EDX, even the AMD aliases (that are explicitly copied
 from CPUID.01H.EDX), so we can make the code check/enforce all the
 CPUID.8001H.EDX bits.
 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Gleb Natapov g...@redhat.com

 ---
  target-i386/cpu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index 42c4c99..ce64b98 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -972,7 +972,7 @@ static int kvm_check_features_against_host(x86_def_t 
 *guest_def)
  {guest_def-ext_features, host_def.ext_features,
  ~0, ext_feature_name, 0x0001, R_ECX},
  {guest_def-ext2_features, host_def.ext2_features,
 -~PPRO_FEATURES, ext2_feature_name, 0x8001, R_EDX},
 +~0, ext2_feature_name, 0x8001, R_EDX},
  {guest_def-ext3_features, host_def.ext3_features,
  ~CPUID_EXT3_SVM, ext3_feature_name, 0x8001, R_ECX}
  };
 -- 
 1.7.11.7
 

--
Gleb.
--
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 v2 0/4] fix KVM i8259 IRQ trailing-edge logic

2013-01-06 Thread Gleb Natapov
On Wed, Dec 26, 2012 at 10:39:52PM -0700, Matthew Ogilvie wrote:
 Changes since version 1 (from Sep 9):
* Split off patch 1; this is the critical prerequisite to
  make the i8254 work with the fixed i8259.
* Add patch 2, to make additional changes to the i8254
  to make it consistent with the spec and with proposed changes
  to qemu's i8254 model.
 
 Background:
 
 According to the spec, the i8259 will cancel an interrupt if
 the line goes low before it starts servicing it, even when
 it is considered edge-triggered.  This is a problem
 with an old Microport UNIX guest (ca 1987), where the
 guest masks off IRQ14 in the slave i8259, but the host's
 master i8259 model will still try to deliver an interrupt even after
 IRQ2 has been brought low, resulting in a spurious interrupt (IRQ15).
 
 Before the i8259 can be fixed, the i8254 model needs to be fixed
 so it doesn't depend on the broken i8259.
 
 Alternative: This could be narrowly fixed for IRQ2 only with no
 risk at all (and no need to touch the i8254), but if possible it
 seems reasonable to fix it for all lines at the same time.
 
 But there may be some risk:
 
 First, I think I've convinced myself that between the i8254 and i8259,
 the only substantial migration breakage should be when a
 whole series of conditions are met, and the combination
 should be rare enough not to worry about it.  See writeup
 in my qemu patch series (version 8; Dec 16).
 
 Second, there is also the possibility that other devices are relying
 on the broken model.  I'm especially concerned with various users
 of a function called
 
 qemu_irq_pulse()
 
 in the qemu source tree, which immediately lowers IRQ line after
 raising it.  If any of those calls are routed straight into
 the i8259 (as opposed to an APIC or some other chip), then it
 probably won't behave as desired.
 
 I'll probably dig into qemu_irq_pulse() callers more carefully
 eventually, but there are lot of them, and any high-level incite
 anyone can provide into them would be helpful.
 
$ git grep qemu_irq_pulse | wc -l
34

Files are:
hw/bonito.c
hw/dma.c
hw/grlib_apbuart.c
hw/grlib_gptimer.c
hw/hpet.c
hw/irq.h
hw/milkymist-ac97.c
hw/milkymist-minimac2.c
hw/milkymist-pfpu.c
hw/milkymist-softusb.c
hw/milkymist-sysctl.c
hw/milkymist-tmu2.c
hw/omap1.c
hw/omap_gptimer.c
hw/onenand.c
hw/spapr_events.c
hw/spapr_llan.c
hw/spapr_pci.c
hw/spapr_vio.c
hw/spapr_vty.c
hw/stellaris.c
hw/xilinx_ethlite.c

Looks like only two of those are relevant to PC platform hw/dma.c and
hw/hpet.c. In hw/dma.c it is used for internal qemu communication, not
real device. In hw/hpet.c from a quick glance it looks like _pulse is
only used when HPET in not in legacy emulation mode which means that
pulse should be directed to APIC.

 See the Dec 16 patch series I sent to the qemu mailing list for
 more information.
 http://search.gmane.org/?query=ogilviegroup=gmane.comp.emulators.qemu
 
 Matthew Ogilvie (4):
   KVM: fix i8254 IRQ0 to be normally high
   KVM: additional i8254 output fixes
   KVM: fix i8259 interrupt high to low transition logic
   KVM: i8259: refactor pic_set_irq level logic
 
  arch/x86/kvm/i8254.c | 50 +++---
  arch/x86/kvm/i8259.c | 36 ++--
  2 files changed, 53 insertions(+), 33 deletions(-)
 
 -- 
 1.7.10.2.484.gcd07cc5

--
Gleb.
--
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: Installation of Windows 8 hangs with KVM

2013-01-06 Thread Stefan Pietsch
* Gleb Natapov g...@redhat.com [2013-01-06 11:11]:
 On Fri, Jan 04, 2013 at 10:58:33PM +0100, Stefan Pietsch wrote:
  Hi all,
  
  when I run KVM with this command the Windows 8 installation stops with
  error code 0x005D:
  kvm -m 1024 -hda win8.img -cdrom windows_8_x86.iso
  
  After adding the option -cpu host the installation proceeds to a black
  screen and hangs.
  
  With Virtualbox the installation succeeds.
  The host CPU is an Intel Core Duo L2400.
   
  Do you have any suggestions?
  
  
 What is your kernel/qemu version?

I'm using Debian unstable.

qemu-kvm 1.1.2+dfsg-3
Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc
version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2


Regards,
Stefan

--
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 ppc-next v2 1/2] target-ppc: Slim conversion of model definitions to QOM subclasses

2013-01-06 Thread Andreas Färber
Since the model list is highly macrofied, keep ppc_def_t for now and
save a pointer to it in PowerPCCPUClass. This results in a flat list of
subclasses including aliases, to be refined later.

Move cpu_ppc_init() to translate_init.c and drop helper.c.
Long-term the idea is to turn translate_init.c into a standalone cpu.c.

Inline cpu_ppc_usable() into type registration.

Split cpu_ppc_register() in two by code movement into the initfn and
by turning the remaining part into a realizefn.
Move qemu_init_vcpu() call into the new realizefn and adapt
create_ppc_opcodes() to return an Error.

Change ppc_find_by_pvr() - ppc_cpu_class_by_pvr().
Change ppc_find_by_name() - ppc_cpu_class_by_name().

Turn -cpu host into its own subclass. This requires to move the
kvm_enabled() check in ppc_cpu_class_by_name() to avoid the class being
found via the normal name lookup in the !kvm_enabled() case.
Turn kvmppc_host_cpu_def() into the class_init and add an initfn that
asserts KVM is in fact enabled.

Implement -cpu ? and the QMP equivalent in terms of subclasses.
This newly exposes -cpu host to the user, ordered last for -cpu ?.

Signed-off-by: Andreas Färber afaer...@suse.de
---
 target-ppc/Makefile.objs|3 +-
 target-ppc/cpu-qom.h|5 +
 target-ppc/cpu.h|4 -
 target-ppc/helper.c |   50 ---
 target-ppc/kvm.c|   37 -
 target-ppc/kvm_ppc.h|8 +-
 target-ppc/translate_init.c |  345 +--
 7 Dateien geändert, 276 Zeilen hinzugefügt(+), 176 Zeilen entfernt(-)
 delete mode 100644 target-ppc/helper.c

diff --git a/target-ppc/Makefile.objs b/target-ppc/Makefile.objs
index 237a0ed..15d2a3c 100644
--- a/target-ppc/Makefile.objs
+++ b/target-ppc/Makefile.objs
@@ -1,7 +1,6 @@
-obj-y += translate.o helper.o
+obj-y += translate.o
 obj-$(CONFIG_SOFTMMU) += machine.o
 obj-$(CONFIG_KVM) += kvm.o kvm_ppc.o
-obj-y += helper.o
 obj-y += excp_helper.o
 obj-y += fpu_helper.o
 obj-y += int_helper.o
diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
index fb6b5a4..b338f8f 100644
--- a/target-ppc/cpu-qom.h
+++ b/target-ppc/cpu-qom.h
@@ -50,6 +50,9 @@ typedef struct PowerPCCPUClass {
 /* public */
 
 void (*parent_reset)(CPUState *cpu);
+
+/* TODO inline fields here */
+ppc_def_t *info;
 } PowerPCCPUClass;
 
 /**
@@ -73,5 +76,7 @@ static inline PowerPCCPU *ppc_env_get_cpu(CPUPPCState *env)
 
 #define ENV_GET_CPU(e) CPU(ppc_env_get_cpu(e))
 
+PowerPCCPUClass *ppc_cpu_class_by_pvr(uint32_t pvr);
+
 
 #endif
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index e88ebe0..443f90c 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1156,10 +1156,6 @@ void ppc_store_msr (CPUPPCState *env, target_ulong 
value);
 
 void ppc_cpu_list (FILE *f, fprintf_function cpu_fprintf);
 
-const ppc_def_t *ppc_find_by_pvr(uint32_t pvr);
-const ppc_def_t *cpu_ppc_find_by_name (const char *name);
-int cpu_ppc_register_internal (CPUPPCState *env, const ppc_def_t *def);
-
 /* Time-base and decrementer management */
 #ifndef NO_CPU_IO_DEFS
 uint64_t cpu_ppc_load_tbl (CPUPPCState *env);
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
deleted file mode 100644
index 103855a..000
--- a/target-ppc/helper.c
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- *  PowerPC emulation helpers for QEMU.
- *
- *  Copyright (c) 2003-2007 Jocelyn Mayer
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see http://www.gnu.org/licenses/.
- */
-
-#include cpu.h
-#include helper_regs.h
-#include sysemu/kvm.h
-#include kvm_ppc.h
-#include sysemu/cpus.h
-
-PowerPCCPU *cpu_ppc_init(const char *cpu_model)
-{
-PowerPCCPU *cpu;
-CPUPPCState *env;
-const ppc_def_t *def;
-
-def = cpu_ppc_find_by_name(cpu_model);
-if (!def) {
-return NULL;
-}
-
-cpu = POWERPC_CPU(object_new(TYPE_POWERPC_CPU));
-env = cpu-env;
-
-if (tcg_enabled()) {
-ppc_translate_init();
-}
-
-env-cpu_model_str = cpu_model;
-cpu_ppc_register_internal(env, def);
-
-qemu_init_vcpu(env);
-
-return cpu;
-}
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 436ca47..a589575 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1210,18 +1210,29 @@ static void alter_insns(uint64_t *word, uint64_t flags, 
bool on)
 }
 }
 
-const ppc_def_t *kvmppc_host_cpu_def(void)
+static void kvmppc_host_cpu_initfn(Object *obj)
 {
+assert(kvm_enabled());
+}

[PATCH ppc-next v2 2/2] target-ppc: Error out for -cpu host on unknown PVR

2013-01-06 Thread Andreas Färber
Previously we silently exited, with subclasses we got an opcode warning.
Instead, explicitly tell the user what's wrong.

An indication for this is -cpu ? showing host with an all-zero PVR.

Signed-off-by: Andreas Färber afaer...@suse.de
---
 target-ppc/kvm.c |8 
 1 Datei geändert, 8 Zeilen hinzugefügt(+)

diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index a589575..b6b5a6a 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1212,7 +1212,15 @@ static void alter_insns(uint64_t *word, uint64_t flags, 
bool on)
 
 static void kvmppc_host_cpu_initfn(Object *obj)
 {
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(obj);
+
 assert(kvm_enabled());
+
+if (pcc-info-pvr != mfpvr()) {
+fprintf(stderr, Your host CPU is unsupported.\n
+Please choose a supported model instead, see -cpu ?.\n);
+exit(1);
+}
 }
 
 static void kvmppc_host_cpu_class_init(ObjectClass *oc, void *data)
-- 
1.7.10.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 v2 1/5] virtio: add functions for piecewise addition of buffers

2013-01-06 Thread Rusty Russell
Wanlong Gao gaowanl...@cn.fujitsu.com writes:
 On 01/02/2013 01:03 PM, Rusty Russell wrote:
 Paolo Bonzini pbonz...@redhat.com writes:
 The virtqueue_add_buf function has two limitations:

 1) it requires the caller to provide all the buffers in a single call;

 2) it does not support chained scatterlists: the buffers must be
 provided as an array of struct scatterlist;
 
 Chained scatterlists are a horrible interface, but that doesn't mean we
 shouldn't support them if there's a need.
 
 I think I once even had a patch which passed two chained sgs, rather
 than a combo sg and two length numbers.  It's very old, but I've pasted
 it below.
 
 Duplicating the implementation by having another interface is pretty
 nasty; I think I'd prefer the chained scatterlists, if that's optimal
 for you.

 I rebased against virtio-next and use it in virtio-scsi, and tested it with 4 
 targets
 virtio-scsi devices and host cpu idle=poll. Saw a little performance 
 regression here.

Sure, but now you should be able to eliminate virtscsi_map_sgl(), right?
You should be able to use scsi_out(sc) and scsi_in(sc) directly, which
is what Paulo wanted to do...

Right Paulo?

Thanks,
Rusty.
--
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 v2 1/5] virtio: add functions for piecewise addition of buffers

2013-01-06 Thread Rusty Russell
Paolo Bonzini pbonz...@redhat.com writes:
 Il 02/01/2013 06:03, Rusty Russell ha scritto:
 Paolo Bonzini pbonz...@redhat.com writes:
 The virtqueue_add_buf function has two limitations:

 1) it requires the caller to provide all the buffers in a single call;

 2) it does not support chained scatterlists: the buffers must be
 provided as an array of struct scatterlist;
 
 Chained scatterlists are a horrible interface, but that doesn't mean we
 shouldn't support them if there's a need.
 
 I think I once even had a patch which passed two chained sgs, rather
 than a combo sg and two length numbers.  It's very old, but I've pasted
 it below.
 
 Duplicating the implementation by having another interface is pretty
 nasty; I think I'd prefer the chained scatterlists, if that's optimal
 for you.

 Unfortunately, that cannot work because not all architectures support
 chained scatterlists.

WHAT?  I can't figure out what an arch needs to do to support this?  Why
is it an option for archs?  Why is sg_chain() even defined for
non-ARCH_HAS_SG_CHAIN?

Jens, help!!

All archs we care about support them, though, so I think we can ignore
this issue for now.

 (Also, as you mention chained scatterlists are horrible.  They'd happen
 to work for virtio-scsi, but not for virtio-blk where the response
 status is part of the footer, not the header).

We lost that debate 5 years ago, so we hack around it as needed.  We can
add helpers to append if we need.

Thanks,
Rusty.
--
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 v8 1/3] x86, apicv: add APICv register virtualization support

2013-01-06 Thread Yang Zhang
- APIC read doesn't cause VM-Exit
- APIC write becomes trap-like

Signed-off-by: Kevin Tian kevin.t...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
 arch/x86/include/asm/vmx.h |2 ++
 arch/x86/kvm/lapic.c   |   15 +++
 arch/x86/kvm/lapic.h   |2 ++
 arch/x86/kvm/vmx.c |   33 -
 4 files changed, 51 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index e385df9..44c3f7e 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -66,6 +66,7 @@
 #define EXIT_REASON_EPT_MISCONFIG   49
 #define EXIT_REASON_WBINVD  54
 #define EXIT_REASON_XSETBV  55
+#define EXIT_REASON_APIC_WRITE  56
 #define EXIT_REASON_INVPCID 58
 
 #define VMX_EXIT_REASONS \
@@ -141,6 +142,7 @@
 #define SECONDARY_EXEC_ENABLE_VPID  0x0020
 #define SECONDARY_EXEC_WBINVD_EXITING  0x0040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST  0x0080
+#define SECONDARY_EXEC_APIC_REGISTER_VIRT   0x0100
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING  0x0400
 #define SECONDARY_EXEC_ENABLE_INVPCID  0x1000
 
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 9392f52..0664c13 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1212,6 +1212,21 @@ void kvm_lapic_set_eoi(struct kvm_vcpu *vcpu)
 }
 EXPORT_SYMBOL_GPL(kvm_lapic_set_eoi);
 
+/* emulate APIC access in a trap manner */
+void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset)
+{
+   u32 val = 0;
+
+   /* hw has done the conditional check and inst decode */
+   offset = 0xff0;
+
+   apic_reg_read(vcpu-arch.apic, offset, 4, val);
+
+   /* TODO: optimize to just emulate side effect w/o one more write */
+   apic_reg_write(vcpu-arch.apic, offset, val);
+}
+EXPORT_SYMBOL_GPL(kvm_apic_write_nodecode);
+
 void kvm_free_lapic(struct kvm_vcpu *vcpu)
 {
struct kvm_lapic *apic = vcpu-arch.apic;
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index e5ebf9f..9a8ee22 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -64,6 +64,8 @@ int kvm_lapic_find_highest_irr(struct kvm_vcpu *vcpu);
 u64 kvm_get_lapic_tscdeadline_msr(struct kvm_vcpu *vcpu);
 void kvm_set_lapic_tscdeadline_msr(struct kvm_vcpu *vcpu, u64 data);
 
+void kvm_apic_write_nodecode(struct kvm_vcpu *vcpu, u32 offset);
+
 void kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr);
 void kvm_lapic_sync_from_vapic(struct kvm_vcpu *vcpu);
 void kvm_lapic_sync_to_vapic(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 23d5aec..730dc13 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -84,6 +84,9 @@ module_param(vmm_exclusive, bool, S_IRUGO);
 static bool __read_mostly fasteoi = 1;
 module_param(fasteoi, bool, S_IRUGO);
 
+static bool __read_mostly enable_apicv_reg_vid = 1;
+module_param(enable_apicv_reg_vid, bool, S_IRUGO);
+
 /*
  * If nested=1, nested virtualization is supported, i.e., guests may use
  * VMX and be a hypervisor for its own guests. If nested=0, guests may not
@@ -762,6 +765,12 @@ static inline bool 
cpu_has_vmx_virtualize_apic_accesses(void)
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
 }
 
+static inline bool cpu_has_vmx_apic_register_virt(void)
+{
+   return vmcs_config.cpu_based_2nd_exec_ctrl 
+   SECONDARY_EXEC_APIC_REGISTER_VIRT;
+}
+
 static inline bool cpu_has_vmx_flexpriority(void)
 {
return cpu_has_vmx_tpr_shadow() 
@@ -2539,7 +2548,8 @@ static __init int setup_vmcs_config(struct vmcs_config 
*vmcs_conf)
SECONDARY_EXEC_UNRESTRICTED_GUEST |
SECONDARY_EXEC_PAUSE_LOOP_EXITING |
SECONDARY_EXEC_RDTSCP |
-   SECONDARY_EXEC_ENABLE_INVPCID;
+   SECONDARY_EXEC_ENABLE_INVPCID |
+   SECONDARY_EXEC_APIC_REGISTER_VIRT;
if (adjust_vmx_controls(min2, opt2,
MSR_IA32_VMX_PROCBASED_CTLS2,
_cpu_based_2nd_exec_control)  0)
@@ -2550,6 +2560,11 @@ static __init int setup_vmcs_config(struct vmcs_config 
*vmcs_conf)
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES))
_cpu_based_exec_control = ~CPU_BASED_TPR_SHADOW;
 #endif
+
+   if (!(_cpu_based_exec_control  CPU_BASED_TPR_SHADOW))
+   _cpu_based_2nd_exec_control = ~(
+   SECONDARY_EXEC_APIC_REGISTER_VIRT);
+
if (_cpu_based_2nd_exec_control  SECONDARY_EXEC_ENABLE_EPT) {
/* CR3 accesses and invlpg don't need to cause VM Exits when EPT
   enabled */
@@ -2747,6 +2762,9 @@ static __init int hardware_setup(void)
if (!cpu_has_vmx_ple())
ple_gap = 0;
 
+   if (!cpu_has_vmx_apic_register_virt())
+   

[PATCH v8 3/3] x86, apicv: add virtual x2apic support

2013-01-06 Thread Yang Zhang
From: Yang Zhang yang.z.zh...@intel.com

basically to benefit from apicv, we need clear MSR bitmap for
corresponding x2apic MSRs when guest enabled x2apic:
0x800 - 0x8ff: no read intercept for apicv register virtualization
TPR,EOI,SELF-IPI: no write intercept for virtual interrupt delivery

Signed-off-by: Yang Zhang yang.z.zh...@intel.com
Signed-off-by: Kevin Tian kevin.t...@intel.com
---
 arch/x86/include/asm/kvm_host.h |1 +
 arch/x86/include/asm/vmx.h  |1 +
 arch/x86/kvm/lapic.c|2 +
 arch/x86/kvm/svm.c  |6 +++
 arch/x86/kvm/vmx.c  |   80 +++---
 5 files changed, 83 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 135603f..af9a8c3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -704,6 +704,7 @@ struct kvm_x86_ops {
void (*update_exitmap_end)(struct kvm_vcpu *vcpu);
void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu);
void (*restore_rvi)(struct kvm_vcpu *vcpu);
+   void (*enable_virtual_x2apic_mode)(struct kvm_vcpu *vcpu);
int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
int (*get_tdp_level)(void);
u64 (*get_mt_mask)(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio);
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index d1ab331..694586c 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -140,6 +140,7 @@
 #define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x0001
 #define SECONDARY_EXEC_ENABLE_EPT   0x0002
 #define SECONDARY_EXEC_RDTSCP  0x0008
+#define SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x0010
 #define SECONDARY_EXEC_ENABLE_VPID  0x0020
 #define SECONDARY_EXEC_WBINVD_EXITING  0x0040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST  0x0080
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index e1baf37..dba5300 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1349,6 +1349,8 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 value)
u32 id = kvm_apic_id(apic);
u32 ldr = ((id  4)  16) | (1  (id  0xf));
kvm_apic_set_ldr(apic, ldr);
+   kvm_x86_ops-enable_virtual_x2apic_mode(vcpu);
+
}
apic-base_address = apic-vcpu-arch.apic_base 
 MSR_IA32_APICBASE_BASE;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index a8a8a4e..3e34e19 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3601,6 +3601,11 @@ static void svm_restore_rvi(struct kvm_vcpu *vcpu)
return;
 }
 
+static void svm_enable_virtual_x2apic_mode(struct kvm_vcpu *vcpu)
+{
+   return;
+}
+
 static int svm_nmi_allowed(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
@@ -4326,6 +4331,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.update_exitmap_end = svm_update_exitmap_end,
.load_eoi_exitmap = svm_load_eoi_exitmap,
.restore_rvi = svm_restore_rvi,
+   .enable_virtual_x2apic_mode = svm_enable_virtual_x2apic_mode,
 
.set_tss_addr = svm_set_tss_addr,
.get_tdp_level = get_npt_level,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 0c85c7e..466b05d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2551,6 +2551,7 @@ static __init int setup_vmcs_config(struct vmcs_config 
*vmcs_conf)
if (_cpu_based_exec_control  CPU_BASED_ACTIVATE_SECONDARY_CONTROLS) {
min2 = 0;
opt2 = SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
+   SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
SECONDARY_EXEC_WBINVD_EXITING |
SECONDARY_EXEC_ENABLE_VPID |
SECONDARY_EXEC_ENABLE_EPT |
@@ -3739,7 +3740,10 @@ static void free_vpid(struct vcpu_vmx *vmx)
spin_unlock(vmx_vpid_lock);
 }
 
-static void __vmx_disable_intercept_for_msr(unsigned long *msr_bitmap, u32 msr)
+#define MSR_TYPE_R 1
+#define MSR_TYPE_W 2
+static void __vmx_disable_intercept_for_msr(unsigned long *msr_bitmap,
+   u32 msr, int type)
 {
int f = sizeof(unsigned long);
 
@@ -3752,20 +3756,52 @@ static void __vmx_disable_intercept_for_msr(unsigned 
long *msr_bitmap, u32 msr)
 * We can control MSRs 0x-0x1fff and 0xc000-0xc0001fff.
 */
if (msr = 0x1fff) {
-   __clear_bit(msr, msr_bitmap + 0x000 / f); /* read-low */
-   __clear_bit(msr, msr_bitmap + 0x800 / f); /* write-low */
+   if (type  MSR_TYPE_R)
+   /* read-low */
+   __clear_bit(msr, msr_bitmap + 0x000 / f);
+
+   if (type  MSR_TYPE_W)
+   /* write-low */
+   __clear_bit(msr, msr_bitmap + 0x800 / f);
+
} else if ((msr 

[PATCH v8 0/3] x86, apicv: Add APIC virtualization support

2013-01-06 Thread Yang Zhang
From: Yang Zhang yang.z.zh...@intel.com

APIC virtualization is a new feature which can eliminate most of VM exit
when vcpu handle a interrupt:

APIC register virtualization:
APIC read access doesn't cause APIC-access VM exits.
APIC write becomes trap-like.

Virtual interrupt delivery:
Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
manually, which is fully taken care of by the hardware.

Please refer to Intel SDM volume 3, chapter 29 for more details.
Changes v7 to v8:
 * According Marcelo's suggestion, add comments for irr_pending and isr_count,
   since the two valiables have different meaning when using apicv.
 * Set highest bit in vISR to SVI after migation.
 * Use spinlock to access eoi exit bitmap synchronously.
 * Enable virtualize x2apic mode when guest is using x2apic
 * Rebased on top of KVM upstream.

Changes v6 to v7:
 * fix a bug when set exit bitmap.
 * Rebased on top of KVM upstream.

Changes v5 to v6:
 * minor adjustments according gleb's comments
 * Rebased on top of KVM upstream.

Changes v4 to v5:
 * Set eoi exit bitmap when an interrupt has notifier registered.
 * Use request to track ioapic entry's modification.
 * Rebased on top of KVM upstream.

Changes v3 to v4:
 * use one option to control both register virtualization and virtual interrupt
   delivery.
 * Update eoi exit bitmap when programing ioapic or programing apic's 
id/dfr/ldr.
 * Rebased on top of KVM upstream.

Changes v2 to v3:
 * Drop Posted Interrupt patch from v3.
   According Gleb's suggestion, we will use global vector for all VCPUs as 
notification
   event vector. So we will rewrite the Posted Interrupt patch. And resend it 
later.
 * Use TMR to set the eoi exiting bitmap. We only want to set eoi exiting 
bitmap for
   those interrupt which is level trigger or has notifier in EOI write path. So 
TMR is
   enough to distinguish the interrupt trigger mode.
 * Simplify some code according Gleb's comments.
 * rebased on top of KVM upstream.

Changes v1 to v2:
 * Add Posted Interrupt support in this series patch.
 * Since there is a notifer hook in vAPIC EOI for PIT interrupt. So always Set 
PIT
   interrupt in eoi exit bitmap to force vmexit when EOI to interrupt.
 * Rebased on top of KVM upstream

Yang Zhang (3):
  x86, apicv: add APICv register virtualization support
  x86, apicv: add virtual interrupt delivery support
  x86, apicv: add virtual x2apic support

 arch/ia64/kvm/lapic.h   |6 +
 arch/x86/include/asm/kvm_host.h |9 ++
 arch/x86/include/asm/vmx.h  |   14 ++
 arch/x86/kvm/irq.c  |   56 +++-
 arch/x86/kvm/lapic.c|  104 ++-
 arch/x86/kvm/lapic.h|   31 -
 arch/x86/kvm/svm.c  |   42 ++
 arch/x86/kvm/vmx.c  |  295 +-
 arch/x86/kvm/x86.c  |   11 ++-
 include/linux/kvm_host.h|2 +
 virt/kvm/ioapic.c   |   41 ++
 virt/kvm/ioapic.h   |1 +
 virt/kvm/irq_comm.c |   20 +++
 13 files changed, 581 insertions(+), 51 deletions(-)

--
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 v8 2/3] x86, apicv: add virtual interrupt delivery support

2013-01-06 Thread Yang Zhang
From: Yang Zhang yang.z.zh...@intel.com

Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
manually, which is fully taken care of by the hardware. This needs
some special awareness into existing interrupr injection path:

- for pending interrupt, instead of direct injection, we may need
  update architecture specific indicators before resuming to guest.

- A pending interrupt, which is masked by ISR, should be also
  considered in above update action, since hardware will decide
  when to inject it at right time. Current has_interrupt and
  get_interrupt only returns a valid vector from injection p.o.v.

Signed-off-by: Kevin Tian kevin.t...@intel.com
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
 arch/ia64/kvm/lapic.h   |6 ++
 arch/x86/include/asm/kvm_host.h |8 ++
 arch/x86/include/asm/vmx.h  |   11 +++
 arch/x86/kvm/irq.c  |   56 +++-
 arch/x86/kvm/lapic.c|   87 +++---
 arch/x86/kvm/lapic.h|   29 +-
 arch/x86/kvm/svm.c  |   36 
 arch/x86/kvm/vmx.c  |  190 ++-
 arch/x86/kvm/x86.c  |   11 ++-
 include/linux/kvm_host.h|2 +
 virt/kvm/ioapic.c   |   41 +
 virt/kvm/ioapic.h   |1 +
 virt/kvm/irq_comm.c |   20 
 13 files changed, 451 insertions(+), 47 deletions(-)

diff --git a/arch/ia64/kvm/lapic.h b/arch/ia64/kvm/lapic.h
index c5f92a9..cb59eb4 100644
--- a/arch/ia64/kvm/lapic.h
+++ b/arch/ia64/kvm/lapic.h
@@ -27,4 +27,10 @@ int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct 
kvm_lapic_irq *irq);
 #define kvm_apic_present(x) (true)
 #define kvm_lapic_enabled(x) (true)
 
+static inline void kvm_update_eoi_exitmap(struct kvm *kvm,
+   struct kvm_lapic_irq *irq)
+{
+   /* IA64 has no apicv supporting, do nothing here */
+}
+
 #endif
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c431b33..135603f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -697,6 +697,13 @@ struct kvm_x86_ops {
void (*enable_nmi_window)(struct kvm_vcpu *vcpu);
void (*enable_irq_window)(struct kvm_vcpu *vcpu);
void (*update_cr8_intercept)(struct kvm_vcpu *vcpu, int tpr, int irr);
+   int (*has_virtual_interrupt_delivery)(struct kvm_vcpu *vcpu);
+   void (*update_apic_irq)(struct kvm_vcpu *vcpu, int max_irr);
+   void (*update_eoi_exitmap)(struct kvm *kvm, struct kvm_lapic_irq *irq);
+   void (*update_exitmap_start)(struct kvm_vcpu *vcpu);
+   void (*update_exitmap_end)(struct kvm_vcpu *vcpu);
+   void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu);
+   void (*restore_rvi)(struct kvm_vcpu *vcpu);
int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
int (*get_tdp_level)(void);
u64 (*get_mt_mask)(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio);
@@ -991,6 +998,7 @@ int kvm_age_hva(struct kvm *kvm, unsigned long hva);
 int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
 void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 int cpuid_maxphyaddr(struct kvm_vcpu *vcpu);
+int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
 int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
 int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
 int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 44c3f7e..d1ab331 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -62,6 +62,7 @@
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS 44
+#define EXIT_REASON_EOI_INDUCED 45
 #define EXIT_REASON_EPT_VIOLATION   48
 #define EXIT_REASON_EPT_MISCONFIG   49
 #define EXIT_REASON_WBINVD  54
@@ -143,6 +144,7 @@
 #define SECONDARY_EXEC_WBINVD_EXITING  0x0040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST  0x0080
 #define SECONDARY_EXEC_APIC_REGISTER_VIRT   0x0100
+#define SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY0x0200
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING  0x0400
 #define SECONDARY_EXEC_ENABLE_INVPCID  0x1000
 
@@ -180,6 +182,7 @@ enum vmcs_field {
GUEST_GS_SELECTOR   = 0x080a,
GUEST_LDTR_SELECTOR = 0x080c,
GUEST_TR_SELECTOR   = 0x080e,
+   GUEST_INTR_STATUS   = 0x0810,
HOST_ES_SELECTOR= 0x0c00,
HOST_CS_SELECTOR= 0x0c02,
HOST_SS_SELECTOR= 0x0c04,
@@ -207,6 +210,14 @@ enum vmcs_field {
APIC_ACCESS_ADDR_HIGH   = 0x2015,
EPT_POINTER = 0x201a,
EPT_POINTER_HIGH= 0x201b,
+   EOI_EXIT_BITMAP0= 0x201c,
+   

[RESEND PATCH] pci-assign: Enable MSIX on device to match guest

2013-01-06 Thread Alex Williamson
When a guest enables MSIX on a device we evaluate the MSIX vector
table, typically find no unmasked vectors and don't switch the device
to MSIX mode.  This generally works fine and the device will be
switched once the guest enables and therefore unmasks a vector.
Unfortunately some drivers enable MSIX, then use interfaces to send
commands between VF  PF or PF  firmware that act based on the host
state of the device.  These therefore may break when MSIX is managed
lazily.  This change re-enables the previous test used to enable MSIX
(see qemu-kvm a6b402c9), which basically guesses whether a vector
will be used based on the data field of the vector table.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Alex Williamson alex.william...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
---

Michael has now ack'd this patch as the correct initial first step,
so I'm resending with that included.  I'm actually not sure what the
expected upstream path is for this file now that it's part of qemu.
There's no entry for hw/kvm/* in MAINTAINERS nor anything specifically
for this file.  Is kvm still upstream for this, through the uq branch
or is it qemu for anything not specifically part of a kvm interface?
Anthony, Gleb, Marcelo, Michael, feel free to add this to your tree,
any path is fine by me.  Thanks,

Alex

 hw/kvm/pci-assign.c |   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 8ee9428..896cfe8 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -1031,6 +1031,19 @@ static bool assigned_dev_msix_masked(MSIXTableEntry 
*entry)
 return (entry-ctrl  cpu_to_le32(0x1)) != 0;
 }
 
+/*
+ * When MSI-X is first enabled the vector table typically has all the
+ * vectors masked, so we can't use that as the obvious test to figure out
+ * how many vectors to initially enable.  Instead we look at the data field
+ * because this is what worked for pci-assign for a long time.  This makes
+ * sure the physical MSI-X state tracks the guest's view, which is important
+ * for some VF/PF and PF/fw communication channels.
+ */
+static bool assigned_dev_msix_skipped(MSIXTableEntry *entry)
+{
+return !entry-data;
+}
+
 static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
 {
 AssignedDevice *adev = DO_UPCAST(AssignedDevice, dev, pci_dev);
@@ -1041,7 +1054,7 @@ static int assigned_dev_update_msix_mmio(PCIDevice 
*pci_dev)
 
 /* Get the usable entry number for allocating */
 for (i = 0; i  adev-msix_max; i++, entry++) {
-if (assigned_dev_msix_masked(entry)) {
+if (assigned_dev_msix_skipped(entry)) {
 continue;
 }
 entries_nr++;
@@ -1070,7 +1083,7 @@ static int assigned_dev_update_msix_mmio(PCIDevice 
*pci_dev)
 for (i = 0; i  adev-msix_max; i++, entry++) {
 adev-msi_virq[i] = -1;
 
-if (assigned_dev_msix_masked(entry)) {
+if (assigned_dev_msix_skipped(entry)) {
 continue;
 }
 

--
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/2] vhost: handle polling errors

2013-01-06 Thread Jason Wang
On 01/06/2013 09:22 PM, Michael S. Tsirkin wrote:
 On Sun, Jan 06, 2013 at 03:18:38PM +0800, Jason Wang wrote:
 Polling errors were ignored by vhost/vhost_net, this may lead to crash when
 trying to remove vhost from waitqueue when after the polling is failed. Solve
 this problem by:

 - checking the poll-wqh before trying to remove from waitqueue
 - report an error when poll() returns a POLLERR in vhost_start_poll()
 - report an error when vhost_start_poll() fails in
   vhost_vring_ioctl()/vhost_net_set_backend() which is used to notify the
   failure to userspace.
 - report an error in the data path in vhost_net when meet polling errors.

 After those changes, we can safely drop the tx polling state in vhost_net 
 since
 it was replaced by the checking of poll-wqh.

 Signed-off-by: Jason Wang jasow...@redhat.com
 ---
  drivers/vhost/net.c   |   74 
 
  drivers/vhost/vhost.c |   31 +++-
  drivers/vhost/vhost.h |2 +-
  3 files changed, 49 insertions(+), 58 deletions(-)

 diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
 index d10ad6f..125c1e5 100644
 --- a/drivers/vhost/net.c
 +++ b/drivers/vhost/net.c
 @@ -64,20 +64,10 @@ enum {
  VHOST_NET_VQ_MAX = 2,
  };
  
 -enum vhost_net_poll_state {
 -VHOST_NET_POLL_DISABLED = 0,
 -VHOST_NET_POLL_STARTED = 1,
 -VHOST_NET_POLL_STOPPED = 2,
 -};
 -
  struct vhost_net {
  struct vhost_dev dev;
  struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
  struct vhost_poll poll[VHOST_NET_VQ_MAX];
 -/* Tells us whether we are polling a socket for TX.
 - * We only do this when socket buffer fills up.
 - * Protected by tx vq lock. */
 -enum vhost_net_poll_state tx_poll_state;
  /* Number of TX recently submitted.
   * Protected by tx vq lock. */
  unsigned tx_packets;
 @@ -155,24 +145,6 @@ static void copy_iovec_hdr(const struct iovec *from, 
 struct iovec *to,
  }
  }
  
 -/* Caller must have TX VQ lock */
 -static void tx_poll_stop(struct vhost_net *net)
 -{
 -if (likely(net-tx_poll_state != VHOST_NET_POLL_STARTED))
 -return;
 -vhost_poll_stop(net-poll + VHOST_NET_VQ_TX);
 -net-tx_poll_state = VHOST_NET_POLL_STOPPED;
 -}
 -
 -/* Caller must have TX VQ lock */
 -static void tx_poll_start(struct vhost_net *net, struct socket *sock)
 -{
 -if (unlikely(net-tx_poll_state != VHOST_NET_POLL_STOPPED))
 -return;
 -vhost_poll_start(net-poll + VHOST_NET_VQ_TX, sock-file);
 -net-tx_poll_state = VHOST_NET_POLL_STARTED;
 -}
 -
  /* In case of DMA done not in order in lower device driver for some reason.
   * upend_idx is used to track end of used idx, done_idx is used to track 
 head
   * of used idx. Once lower device DMA done contiguously, we will signal KVM
 @@ -227,6 +199,7 @@ static void vhost_zerocopy_callback(struct ubuf_info 
 *ubuf, bool success)
  static void handle_tx(struct vhost_net *net)
  {
  struct vhost_virtqueue *vq = net-dev.vqs[VHOST_NET_VQ_TX];
 +struct vhost_poll *poll = net-poll + VHOST_NET_VQ_TX;
  unsigned out, in, s;
  int head;
  struct msghdr msg = {
 @@ -252,7 +225,8 @@ static void handle_tx(struct vhost_net *net)
  wmem = atomic_read(sock-sk-sk_wmem_alloc);
  if (wmem = sock-sk-sk_sndbuf) {
  mutex_lock(vq-mutex);
 -tx_poll_start(net, sock);
 +if (vhost_poll_start(poll, sock-file))
 +vq_err(vq, Fail to start TX polling\n);
 s/Fail/Failed/

 A question though: how can this happen? Could you clarify please?
 Maybe we can find a way to prevent this error?

Two conditions I think this can happen:

1) a buggy userspace disable a queue through TUNSETQUEUE
2) the net device were gone

For 1, looks like we can delay the disabling until the refcnt goes to
zero. For 2 may needs more changes. Not sure it's worth to do this work,
maybe a warning is enough just like other failure.

  mutex_unlock(vq-mutex);
  return;
  }
 @@ -261,7 +235,7 @@ static void handle_tx(struct vhost_net *net)
  vhost_disable_notify(net-dev, vq);
  
  if (wmem  sock-sk-sk_sndbuf / 2)
 -tx_poll_stop(net);
 +vhost_poll_stop(poll);
  hdr_size = vq-vhost_hlen;
  zcopy = vq-ubufs;
  
 @@ -283,8 +257,10 @@ static void handle_tx(struct vhost_net *net)
  
  wmem = atomic_read(sock-sk-sk_wmem_alloc);
  if (wmem = sock-sk-sk_sndbuf * 3 / 4) {
 -tx_poll_start(net, sock);
 -set_bit(SOCK_ASYNC_NOSPACE, sock-flags);
 +if (vhost_poll_start(poll, sock-file))
 +vq_err(vq, Fail to start TX 
 polling\n);
 +else
 +set_bit(SOCK_ASYNC_NOSPACE, 
 sock-flags);
  break;
  }
  /* If more outstanding DMAs, queue 

Re: [PATCH v8 3/3] x86, apicv: add virtual x2apic support

2013-01-06 Thread Gleb Natapov
On Mon, Jan 07, 2013 at 10:02:37AM +0800, Yang Zhang wrote:
 From: Yang Zhang yang.z.zh...@intel.com
 
 basically to benefit from apicv, we need clear MSR bitmap for
 corresponding x2apic MSRs when guest enabled x2apic:
 0x800 - 0x8ff: no read intercept for apicv register virtualization
 TPR,EOI,SELF-IPI: no write intercept for virtual interrupt delivery
 
 Signed-off-by: Yang Zhang yang.z.zh...@intel.com
 Signed-off-by: Kevin Tian kevin.t...@intel.com
 ---
  arch/x86/include/asm/kvm_host.h |1 +
  arch/x86/include/asm/vmx.h  |1 +
  arch/x86/kvm/lapic.c|2 +
  arch/x86/kvm/svm.c  |6 +++
  arch/x86/kvm/vmx.c  |   80 +++---
  5 files changed, 83 insertions(+), 7 deletions(-)
 
 diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
 index 135603f..af9a8c3 100644
 --- a/arch/x86/include/asm/kvm_host.h
 +++ b/arch/x86/include/asm/kvm_host.h
 @@ -704,6 +704,7 @@ struct kvm_x86_ops {
   void (*update_exitmap_end)(struct kvm_vcpu *vcpu);
   void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu);
   void (*restore_rvi)(struct kvm_vcpu *vcpu);
 + void (*enable_virtual_x2apic_mode)(struct kvm_vcpu *vcpu);
   int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
   int (*get_tdp_level)(void);
   u64 (*get_mt_mask)(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio);
 diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
 index d1ab331..694586c 100644
 --- a/arch/x86/include/asm/vmx.h
 +++ b/arch/x86/include/asm/vmx.h
 @@ -140,6 +140,7 @@
  #define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x0001
  #define SECONDARY_EXEC_ENABLE_EPT   0x0002
  #define SECONDARY_EXEC_RDTSCP0x0008
 +#define SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x0010
  #define SECONDARY_EXEC_ENABLE_VPID  0x0020
  #define SECONDARY_EXEC_WBINVD_EXITING0x0040
  #define SECONDARY_EXEC_UNRESTRICTED_GUEST0x0080
 diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
 index e1baf37..dba5300 100644
 --- a/arch/x86/kvm/lapic.c
 +++ b/arch/x86/kvm/lapic.c
 @@ -1349,6 +1349,8 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 
 value)
   u32 id = kvm_apic_id(apic);
   u32 ldr = ((id  4)  16) | (1  (id  0xf));
   kvm_apic_set_ldr(apic, ldr);
 + kvm_x86_ops-enable_virtual_x2apic_mode(vcpu);
And where do you disable it?

 +
   }
   apic-base_address = apic-vcpu-arch.apic_base 
MSR_IA32_APICBASE_BASE;
 diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
 index a8a8a4e..3e34e19 100644
 --- a/arch/x86/kvm/svm.c
 +++ b/arch/x86/kvm/svm.c
 @@ -3601,6 +3601,11 @@ static void svm_restore_rvi(struct kvm_vcpu *vcpu)
   return;
  }
  
 +static void svm_enable_virtual_x2apic_mode(struct kvm_vcpu *vcpu)
 +{
 + return;
 +}
 +
  static int svm_nmi_allowed(struct kvm_vcpu *vcpu)
  {
   struct vcpu_svm *svm = to_svm(vcpu);
 @@ -4326,6 +4331,7 @@ static struct kvm_x86_ops svm_x86_ops = {
   .update_exitmap_end = svm_update_exitmap_end,
   .load_eoi_exitmap = svm_load_eoi_exitmap,
   .restore_rvi = svm_restore_rvi,
 + .enable_virtual_x2apic_mode = svm_enable_virtual_x2apic_mode,
  
   .set_tss_addr = svm_set_tss_addr,
   .get_tdp_level = get_npt_level,
 diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
 index 0c85c7e..466b05d 100644
 --- a/arch/x86/kvm/vmx.c
 +++ b/arch/x86/kvm/vmx.c
 @@ -2551,6 +2551,7 @@ static __init int setup_vmcs_config(struct vmcs_config 
 *vmcs_conf)
   if (_cpu_based_exec_control  CPU_BASED_ACTIVATE_SECONDARY_CONTROLS) {
   min2 = 0;
   opt2 = SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
 + SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
   SECONDARY_EXEC_WBINVD_EXITING |
   SECONDARY_EXEC_ENABLE_VPID |
   SECONDARY_EXEC_ENABLE_EPT |
 @@ -3739,7 +3740,10 @@ static void free_vpid(struct vcpu_vmx *vmx)
   spin_unlock(vmx_vpid_lock);
  }
  
 -static void __vmx_disable_intercept_for_msr(unsigned long *msr_bitmap, u32 
 msr)
 +#define MSR_TYPE_R   1
 +#define MSR_TYPE_W   2
 +static void __vmx_disable_intercept_for_msr(unsigned long *msr_bitmap,
 + u32 msr, int type)
  {
   int f = sizeof(unsigned long);
  
 @@ -3752,20 +3756,52 @@ static void __vmx_disable_intercept_for_msr(unsigned 
 long *msr_bitmap, u32 msr)
* We can control MSRs 0x-0x1fff and 0xc000-0xc0001fff.
*/
   if (msr = 0x1fff) {
 - __clear_bit(msr, msr_bitmap + 0x000 / f); /* read-low */
 - __clear_bit(msr, msr_bitmap + 0x800 / f); /* write-low */
 + if (type  MSR_TYPE_R)
 + /* read-low */
 + __clear_bit(msr, msr_bitmap + 0x000 / f);
 +
 + if (type  MSR_TYPE_W)
 

RE: [PATCH v8 3/3] x86, apicv: add virtual x2apic support

2013-01-06 Thread Zhang, Yang Z
Gleb Natapov wrote on 2013-01-07:
 On Mon, Jan 07, 2013 at 10:02:37AM +0800, Yang Zhang wrote:
 From: Yang Zhang yang.z.zh...@intel.com
 
 basically to benefit from apicv, we need clear MSR bitmap for
 corresponding x2apic MSRs when guest enabled x2apic:
 0x800 - 0x8ff: no read intercept for apicv register virtualization
 TPR,EOI,SELF-IPI: no write intercept for virtual interrupt delivery
 Signed-off-by: Yang Zhang yang.z.zh...@intel.com
 Signed-off-by: Kevin Tian kevin.t...@intel.com
 ---
  arch/x86/include/asm/kvm_host.h |1 + arch/x86/include/asm/vmx.h   
|1 + arch/x86/kvm/lapic.c|2 + arch/x86/kvm/svm.c
   |6 +++ arch/x86/kvm/vmx.c  |   80
  +++--- 5 files changed, 83
  insertions(+), 7 deletions(-)
 diff --git a/arch/x86/include/asm/kvm_host.h
 b/arch/x86/include/asm/kvm_host.h index 135603f..af9a8c3 100644 ---
 a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h
 @@ -704,6 +704,7 @@ struct kvm_x86_ops {
  void (*update_exitmap_end)(struct kvm_vcpu *vcpu);  void
  (*load_eoi_exitmap)(struct kvm_vcpu *vcpu); void
  (*restore_rvi)(struct kvm_vcpu *vcpu); +void
  (*enable_virtual_x2apic_mode)(struct kvm_vcpu *vcpu);   int
  (*set_tss_addr)(struct kvm *kvm, unsigned int addr);int
  (*get_tdp_level)(void); u64 (*get_mt_mask)(struct kvm_vcpu *vcpu,
  gfn_t gfn, bool is_mmio);
 diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
 index d1ab331..694586c 100644
 --- a/arch/x86/include/asm/vmx.h
 +++ b/arch/x86/include/asm/vmx.h
 @@ -140,6 +140,7 @@
  #define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x0001 #define
  SECONDARY_EXEC_ENABLE_EPT   0x0002 #define
  SECONDARY_EXEC_RDTSCP   0x0008 +#define
  SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x0010 #define
  SECONDARY_EXEC_ENABLE_VPID  0x0020 #define
  SECONDARY_EXEC_WBINVD_EXITING   0x0040 #define
  SECONDARY_EXEC_UNRESTRICTED_GUEST   0x0080
 diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
 index e1baf37..dba5300 100644
 --- a/arch/x86/kvm/lapic.c
 +++ b/arch/x86/kvm/lapic.c
 @@ -1349,6 +1349,8 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64
 value)
  u32 id = kvm_apic_id(apic);
  u32 ldr = ((id  4)  16) | (1  (id  0xf));
  kvm_apic_set_ldr(apic, ldr);
 +kvm_x86_ops-enable_virtual_x2apic_mode(vcpu);
 And where do you disable it?
Yes, need to disable it when guest rolls back to xapic mode. Will add it in 
next patch.

 +
  }
  apic-base_address = apic-vcpu-arch.apic_base 
   MSR_IA32_APICBASE_BASE;
 diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
 index a8a8a4e..3e34e19 100644
 --- a/arch/x86/kvm/svm.c
 +++ b/arch/x86/kvm/svm.c
 @@ -3601,6 +3601,11 @@ static void svm_restore_rvi(struct kvm_vcpu *vcpu)
  return;
  }
 +static void svm_enable_virtual_x2apic_mode(struct kvm_vcpu *vcpu)
 +{
 +return;
 +}
 +
  static int svm_nmi_allowed(struct kvm_vcpu *vcpu) { struct vcpu_svm
  *svm = to_svm(vcpu); @@ -4326,6 +4331,7 @@ static struct kvm_x86_ops
  svm_x86_ops = { .update_exitmap_end = svm_update_exitmap_end,
  .load_eoi_exitmap = svm_load_eoi_exitmap,   .restore_rvi =
  svm_restore_rvi,
 +.enable_virtual_x2apic_mode = svm_enable_virtual_x2apic_mode,
 
  .set_tss_addr = svm_set_tss_addr,
  .get_tdp_level = get_npt_level,
 diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
 index 0c85c7e..466b05d 100644
 --- a/arch/x86/kvm/vmx.c
 +++ b/arch/x86/kvm/vmx.c
 @@ -2551,6 +2551,7 @@ static __init int setup_vmcs_config(struct
 vmcs_config *vmcs_conf)
  if (_cpu_based_exec_control  CPU_BASED_ACTIVATE_SECONDARY_CONTROLS)
  {   min2 = 0;   opt2 = 
 SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
  +   SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE |
  SECONDARY_EXEC_WBINVD_EXITING | 
 SECONDARY_EXEC_ENABLE_VPID |
  SECONDARY_EXEC_ENABLE_EPT | @@ -3739,7 +3740,10 @@ 
 static void
  free_vpid(struct vcpu_vmx *vmx) spin_unlock(vmx_vpid_lock); }
 -static void __vmx_disable_intercept_for_msr(unsigned long *msr_bitmap,
 u32 msr) +#define MSR_TYPE_R 1 +#define MSR_TYPE_W   2 +static void
 __vmx_disable_intercept_for_msr(unsigned long *msr_bitmap, + 
 u32
 msr, int type)
  {
  int f = sizeof(unsigned long);
 @@ -3752,20 +3756,52 @@ static void
 __vmx_disable_intercept_for_msr(unsigned long *msr_bitmap, u32 msr)
   * We can control MSRs 0x-0x1fff and 0xc000-0xc0001fff.
   */
  if (msr = 0x1fff) {
 -__clear_bit(msr, msr_bitmap + 0x000 / f); /* read-low */
 -__clear_bit(msr, msr_bitmap + 0x800 / f); /* write-low */
 +if (type  MSR_TYPE_R)
 +/* read-low */
 +

Re: [PATCH v8 3/3] x86, apicv: add virtual x2apic support

2013-01-06 Thread Gleb Natapov
On Mon, Jan 07, 2013 at 06:58:15AM +, Zhang, Yang Z wrote:
 Gleb Natapov wrote on 2013-01-07:
  On Mon, Jan 07, 2013 at 10:02:37AM +0800, Yang Zhang wrote:
  From: Yang Zhang yang.z.zh...@intel.com
  
  basically to benefit from apicv, we need clear MSR bitmap for
  corresponding x2apic MSRs when guest enabled x2apic:
  0x800 - 0x8ff: no read intercept for apicv register virtualization
  TPR,EOI,SELF-IPI: no write intercept for virtual interrupt delivery
  Signed-off-by: Yang Zhang yang.z.zh...@intel.com
  Signed-off-by: Kevin Tian kevin.t...@intel.com
  ---
   arch/x86/include/asm/kvm_host.h |1 + arch/x86/include/asm/vmx.h   
 |1 + arch/x86/kvm/lapic.c|2 + arch/x86/kvm/svm.c
|6 +++ arch/x86/kvm/vmx.c  |   80
   +++--- 5 files changed, 83
   insertions(+), 7 deletions(-)
  diff --git a/arch/x86/include/asm/kvm_host.h
  b/arch/x86/include/asm/kvm_host.h index 135603f..af9a8c3 100644 ---
  a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h
  @@ -704,6 +704,7 @@ struct kvm_x86_ops {
 void (*update_exitmap_end)(struct kvm_vcpu *vcpu);  void
   (*load_eoi_exitmap)(struct kvm_vcpu *vcpu);   void
   (*restore_rvi)(struct kvm_vcpu *vcpu); +  void
   (*enable_virtual_x2apic_mode)(struct kvm_vcpu *vcpu); int
   (*set_tss_addr)(struct kvm *kvm, unsigned int addr);  int
   (*get_tdp_level)(void);   u64 (*get_mt_mask)(struct kvm_vcpu *vcpu,
   gfn_t gfn, bool is_mmio);
  diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
  index d1ab331..694586c 100644
  --- a/arch/x86/include/asm/vmx.h
  +++ b/arch/x86/include/asm/vmx.h
  @@ -140,6 +140,7 @@
   #define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x0001 #define
   SECONDARY_EXEC_ENABLE_EPT   0x0002 #define
   SECONDARY_EXEC_RDTSCP 0x0008 +#define
   SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE   0x0010 #define
   SECONDARY_EXEC_ENABLE_VPID  0x0020 #define
   SECONDARY_EXEC_WBINVD_EXITING 0x0040 #define
   SECONDARY_EXEC_UNRESTRICTED_GUEST 0x0080
  diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
  index e1baf37..dba5300 100644
  --- a/arch/x86/kvm/lapic.c
  +++ b/arch/x86/kvm/lapic.c
  @@ -1349,6 +1349,8 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64
  value)
 u32 id = kvm_apic_id(apic);
 u32 ldr = ((id  4)  16) | (1  (id  0xf));
 kvm_apic_set_ldr(apic, ldr);
  +  kvm_x86_ops-enable_virtual_x2apic_mode(vcpu);
  And where do you disable it?
 Yes, need to disable it when guest rolls back to xapic mode. Will add it in 
 next patch.
 
You also need to reorder patches 2 and 3. Otherwise x2apic will be
broken after patch 2.

--
Gleb.
--
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 v8 2/3] x86, apicv: add virtual interrupt delivery support

2013-01-06 Thread Gleb Natapov
On Mon, Jan 07, 2013 at 10:02:36AM +0800, Yang Zhang wrote:
 From: Yang Zhang yang.z.zh...@intel.com
 
 Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
 manually, which is fully taken care of by the hardware. This needs
 some special awareness into existing interrupr injection path:
 
 - for pending interrupt, instead of direct injection, we may need
   update architecture specific indicators before resuming to guest.
 
 - A pending interrupt, which is masked by ISR, should be also
   considered in above update action, since hardware will decide
   when to inject it at right time. Current has_interrupt and
   get_interrupt only returns a valid vector from injection p.o.v.
 
 Signed-off-by: Kevin Tian kevin.t...@intel.com
 Signed-off-by: Yang Zhang yang.z.zh...@intel.com
 ---
  arch/ia64/kvm/lapic.h   |6 ++
  arch/x86/include/asm/kvm_host.h |8 ++
  arch/x86/include/asm/vmx.h  |   11 +++
  arch/x86/kvm/irq.c  |   56 +++-
  arch/x86/kvm/lapic.c|   87 +++---
  arch/x86/kvm/lapic.h|   29 +-
  arch/x86/kvm/svm.c  |   36 
  arch/x86/kvm/vmx.c  |  190 
 ++-
  arch/x86/kvm/x86.c  |   11 ++-
  include/linux/kvm_host.h|2 +
  virt/kvm/ioapic.c   |   41 +
  virt/kvm/ioapic.h   |1 +
  virt/kvm/irq_comm.c |   20 
  13 files changed, 451 insertions(+), 47 deletions(-)
 
 diff --git a/arch/ia64/kvm/lapic.h b/arch/ia64/kvm/lapic.h
 index c5f92a9..cb59eb4 100644
 --- a/arch/ia64/kvm/lapic.h
 +++ b/arch/ia64/kvm/lapic.h
 @@ -27,4 +27,10 @@ int kvm_apic_set_irq(struct kvm_vcpu *vcpu, struct 
 kvm_lapic_irq *irq);
  #define kvm_apic_present(x) (true)
  #define kvm_lapic_enabled(x) (true)
  
 +static inline void kvm_update_eoi_exitmap(struct kvm *kvm,
 + struct kvm_lapic_irq *irq)
 +{
 + /* IA64 has no apicv supporting, do nothing here */
 +}
 +
  #endif
 diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
 index c431b33..135603f 100644
 --- a/arch/x86/include/asm/kvm_host.h
 +++ b/arch/x86/include/asm/kvm_host.h
 @@ -697,6 +697,13 @@ struct kvm_x86_ops {
   void (*enable_nmi_window)(struct kvm_vcpu *vcpu);
   void (*enable_irq_window)(struct kvm_vcpu *vcpu);
   void (*update_cr8_intercept)(struct kvm_vcpu *vcpu, int tpr, int irr);
 + int (*has_virtual_interrupt_delivery)(struct kvm_vcpu *vcpu);
 + void (*update_apic_irq)(struct kvm_vcpu *vcpu, int max_irr);
 + void (*update_eoi_exitmap)(struct kvm *kvm, struct kvm_lapic_irq *irq);
 + void (*update_exitmap_start)(struct kvm_vcpu *vcpu);
 + void (*update_exitmap_end)(struct kvm_vcpu *vcpu);
 + void (*load_eoi_exitmap)(struct kvm_vcpu *vcpu);
The amount of callbacks to update exit bitmap start to become insane.

 + void (*restore_rvi)(struct kvm_vcpu *vcpu);
rvi? Call it set_svi() and make it do just that - set svi.

   int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
   int (*get_tdp_level)(void);
   u64 (*get_mt_mask)(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio);
 @@ -991,6 +998,7 @@ int kvm_age_hva(struct kvm *kvm, unsigned long hva);
  int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
  void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
  int cpuid_maxphyaddr(struct kvm_vcpu *vcpu);
 +int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
  int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
  int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
  int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
 diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
 index 44c3f7e..d1ab331 100644
 --- a/arch/x86/include/asm/vmx.h
 +++ b/arch/x86/include/asm/vmx.h
 @@ -62,6 +62,7 @@
  #define EXIT_REASON_MCE_DURING_VMENTRY  41
  #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
  #define EXIT_REASON_APIC_ACCESS 44
 +#define EXIT_REASON_EOI_INDUCED 45
  #define EXIT_REASON_EPT_VIOLATION   48
  #define EXIT_REASON_EPT_MISCONFIG   49
  #define EXIT_REASON_WBINVD  54
 @@ -143,6 +144,7 @@
  #define SECONDARY_EXEC_WBINVD_EXITING0x0040
  #define SECONDARY_EXEC_UNRESTRICTED_GUEST0x0080
  #define SECONDARY_EXEC_APIC_REGISTER_VIRT   0x0100
 +#define SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY0x0200
  #define SECONDARY_EXEC_PAUSE_LOOP_EXITING0x0400
  #define SECONDARY_EXEC_ENABLE_INVPCID0x1000
  
 @@ -180,6 +182,7 @@ enum vmcs_field {
   GUEST_GS_SELECTOR   = 0x080a,
   GUEST_LDTR_SELECTOR = 0x080c,
   GUEST_TR_SELECTOR   = 0x080e,
 + GUEST_INTR_STATUS   = 0x0810,
   HOST_ES_SELECTOR= 0x0c00,
   HOST_CS_SELECTOR= 0x0c02,
   HOST_SS_SELECTOR= 0x0c04,
 @@ -207,6 

Re: [PATCH] KVM: PPC: Book3S HV: Fix compilation without CONFIG_PPC_POWERNV

2013-01-06 Thread Alexander Graf

On 22.12.2012, at 15:09, Andreas Schwab wrote:

 Fixes this build breakage:
 
 arch/powerpc/kvm/book3s_hv_ras.c: In function ‘kvmppc_realmode_mc_power7’:
 arch/powerpc/kvm/book3s_hv_ras.c:126:23: error: ‘struct paca_struct’ has no 
 member named ‘opal_mc_evt’
 
 Signed-off-by: Andreas Schwab sch...@linux-m68k.org

Thanks, applied to kvm-ppc-3.8.

Paul, in the long run it might make sense to make HV KVM conditional on OPAL 
and just completely remove 970 support. At least if it significantly makes your 
life easier.


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