date:20140806

Re: [PATCH] virtio-rng: complete have_data completion in removing device

2014-08-06 Thread Amos Kong

On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote:
> When we try to hot-remove a busy virtio-rng device from QEMU monitor,
> the device can't be hot-removed. Because virtio-rng driver hangs at
> wait_for_completion_killable().
> 
> This patch fixed the hang by completing have_data completion before
> unregistering a virtio-rng device.

Hi Amit,

Before applying this patch, it's blocking insider 
wait_for_completion_killable() 
Applied this patch, wait_for_completion_killable() returns 0,
and vi->data_avail becomes 0, then rng_get_date() will return 0.

Is it expected result?

 
> Signed-off-by: Amos Kong 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/char/hw_random/virtio-rng.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/char/hw_random/virtio-rng.c 
> b/drivers/char/hw_random/virtio-rng.c
> index 0027137..416b15c 100644
> --- a/drivers/char/hw_random/virtio-rng.c
> +++ b/drivers/char/hw_random/virtio-rng.c
> @@ -137,6 +137,7 @@ static void remove_common(struct virtio_device *vdev)
>   struct virtrng_info *vi = vdev->priv;
>  
>   vdev->config->reset(vdev);
> + complete(&vi->have_data);
>   vi->busy = false;
>   if (vi->hwrng_register_done)
>   hwrng_unregister(&vi->hwrng);
> -- 
> 1.9.3
> 
> ___
> Virtualization mailing list
> virtualizat...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization

-- 
Amos.
--
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] virtio-rng: complete have_data completion in removing device

2014-08-06 Thread Amit Shah

On (Wed) 06 Aug 2014 [16:05:41], Amos Kong wrote:
> On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote:
> > When we try to hot-remove a busy virtio-rng device from QEMU monitor,
> > the device can't be hot-removed. Because virtio-rng driver hangs at
> > wait_for_completion_killable().
> > 
> > This patch fixed the hang by completing have_data completion before
> > unregistering a virtio-rng device.
> 
> Hi Amit,
> 
> Before applying this patch, it's blocking insider 
> wait_for_completion_killable() 
> Applied this patch, wait_for_completion_killable() returns 0,
> and vi->data_avail becomes 0, then rng_get_date() will return 0.

Thanks for checking this.

> Is it expected result?

I think what will happen is vi->data_avail will be set to whatever it
was set last.  In case of a previous successful read request, the
data_avail will be set to whatever number of bytes the host gave.  On
doing a hot-unplug on the succeeding wait, the value in data_avail
will be re-used, and the hwrng core will wrongly take some bytes in
the buffer as input from the host.

So, I think we need to set vi->data_avail = 0; before calling
wait_event_completion_killable().

Amit
--
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 v3 3/4] drivers/vfio: Allow EEH to be built as module

2014-08-06 Thread Gavin Shan

From: Alexey Kardashevskiy 

This adds necessary declarations to the SPAPR VFIO EEH module,
otherwise multiple dynamic linker errors reported:

vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
 drivers/vfio/vfio_spapr_eeh.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 949f98e..4779cac 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -9,10 +9,15 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
 
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR  "Gavin Shan, IBM Corporation"
+#define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
+
 /* We might build address mapping here for "fast" path later */
 int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
@@ -88,3 +93,8 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
return ret;
 }
 EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
-- 
1.8.3.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

[PATCH v3 0/4] drivers/vfio: EEH Compile and compatibility

2014-08-06 Thread Gavin Shan

The patchset is mainly for fixing errors from building VFIO compoments
as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
to initialize for VFIO PCI devices.

Alexey Kardashevskiy (2):
  drivers/vfio: Allow EEH to be built as module
  drivers/vfio: Enable VFIO if EEH is not supported

Gavin Shan (2):
  powerpc/eeh: Export eeh_iommu_group_to_pe()
  drivers/vfio: Fix EEH build error

 arch/powerpc/kernel/eeh.c |  1 +
 drivers/vfio/Kconfig  |  6 ++
 drivers/vfio/Makefile |  2 +-
 drivers/vfio/pci/vfio_pci.c   |  6 +-
 drivers/vfio/vfio_spapr_eeh.c | 17 +++--
 include/linux/vfio.h  |  6 +++---
 6 files changed, 27 insertions(+), 11 deletions(-)

-- 
1.8.3.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

[PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan

From: Alexey Kardashevskiy 

The existing vfio_pci_open() fails upon error returned from
vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
support which this patch brings back.

The patch fixes the issue by dropping the return value of
vfio_spapr_pci_eeh_open().

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
v3: Drop return value of vfio_spapr_pci_eeh_open()
---
 drivers/vfio/pci/vfio_pci.c   | 6 +-
 drivers/vfio/vfio_spapr_eeh.c | 4 ++--
 include/linux/vfio.h  | 5 ++---
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index e2ee80f..32d69c8 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
if (ret)
goto error;
 
-   ret = vfio_spapr_pci_eeh_open(vdev->pdev);
-   if (ret) {
-   vfio_pci_disable(vdev);
-   goto error;
-   }
+   vfio_spapr_pci_eeh_open(vdev->pdev);
}
 
return 0;
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 4779cac..86dfceb 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -19,9 +19,9 @@
 #define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
 
 /* We might build address mapping here for "fast" path later */
-int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return eeh_dev_open(pdev);
+   eeh_dev_open(pdev);
 }
 EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 224128a..d320411 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
vfio_group *group,
 
 struct pci_dev;
 #ifdef CONFIG_EEH
-extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
+extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
 extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
   unsigned int cmd,
   unsigned long arg);
 #else
-static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return 0;
 }
 
 static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
-- 
1.8.3.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

[PATCH v3 2/4] drivers/vfio: Fix EEH build error

2014-08-06 Thread Gavin Shan

The VFIO related components could be built as dynamic modules.
Unfortunately, CONFIG_EEH can't be configured to "m". The patch
fixes the build errors when configuring VFIO related components
as dynamic modules as follows:

  CC [M]  drivers/vfio/vfio_iommu_spapr_tce.o
In file included from drivers/vfio/vfio.c:33:0:
include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
inside parameter list [enabled by default]
   :
  WRAParch/powerpc/boot/zImage.pseries
  WRAParch/powerpc/boot/zImage.maple
  WRAParch/powerpc/boot/zImage.pmac
  WRAParch/powerpc/boot/zImage.epapr
  MODPOST 1818 modules
ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
Signed-off-by: Alexey Kardashevskiy 
---
v3: Introduce CONFIG_VFIO_SPAPR_EEH and add "struct pci_dev" in vfio.h
v2: remove #include  from vfio.c
---
 drivers/vfio/Kconfig  | 6 ++
 drivers/vfio/Makefile | 2 +-
 drivers/vfio/vfio_spapr_eeh.c | 3 +++
 include/linux/vfio.h  | 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index af7b204..d8c5763 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -8,11 +8,17 @@ config VFIO_IOMMU_SPAPR_TCE
depends on VFIO && SPAPR_TCE_IOMMU
default n
 
+config VFIO_SPAPR_EEH
+   tristate
+   depends on EEH && VFIO_IOMMU_SPAPR_TCE
+   default n
+
 menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if X86
select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
+   select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES)
select ANON_INODES
help
  VFIO provides a framework for secure userspace device drivers.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 50e30bc..0b035b1 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
 obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
-obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
+obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index f834b4c..949f98e 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -18,11 +18,13 @@ int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
return eeh_dev_open(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
 void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
 {
eeh_dev_release(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
 
 long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
unsigned int cmd, unsigned long arg)
@@ -85,3 +87,4 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
 
return ret;
 }
+EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 25a0fbd..224128a 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -98,6 +98,7 @@ extern int vfio_external_user_iommu_id(struct vfio_group 
*group);
 extern long vfio_external_check_extension(struct vfio_group *group,
  unsigned long arg);
 
+struct pci_dev;
 #ifdef CONFIG_EEH
 extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
-- 
1.8.3.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

[PATCH v3 1/4] powerpc/eeh: Export eeh_iommu_group_to_pe()

2014-08-06 Thread Gavin Shan

The function is used by VFIO driver, which might be built as a
dynamic module. So it should be exported.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1254,6 +1254,7 @@ struct eeh_pe *eeh_iommu_group_to_pe(struct iommu_group 
*group)
 
return edev->pe;
 }
+EXPORT_SYMBOL_GPL(eeh_iommu_group_to_pe);
 
 #endif /* CONFIG_IOMMU_API */
 
-- 
1.8.3.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: [Qemu-devel] [questions] about KVM asaMicrosoft-compatiblehypervisor

2014-08-06 Thread Vadim Rozenfeld

On Mon, 2014-08-04 at 14:29 +0800, Zhang Haoyu wrote:
> >Hi Zhang,
> >
> >No I haven't seen such problem
> >Which kernel version are you running?
> Host kernel: RHEL7-RC1(linux-3.10.0).
> 
> >Does it include the latest lazy eli changes?
> >
> lazy eli or lazy eoi?
EOI
> How to confirm whether lazy eli has been included?
> 
not in linux-3.10.0
> >Btw, hv_spinlocks=0xfff is a pretty huge value.
> >
> which value do you advise to use?
MS seems to be using 0x as a default.
best regards,
Vadim.
> 
> Thanks,
> Zhang Haoyu
> >Best regards,
> >Vadim.
> 
> 


--
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

QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo

2014-08-06 Thread Erik Rull

Hi all,

I did already several tests and I'm not completely sure what's going wrong, but
here my scenario:

When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel
3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any error.
When I dump the CPU registers via "info registers", nothing changes, that means
the system really stalled. Same happens with QEMU 2.0.0.

But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 on
the host side it works on the Core2Duo. Also the system above but just with an
i3 or i5 CPU it works, too.

I already disabled networking and USB for the guest and changed the graphics
card - no effect. I assume that some mean bits and bytes have to be set up
properly to get the thing running.

Any hint what to change / test would be really appreciated.

Thanks in advance,

Best regards,

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

Re: [PATCH 0/6] IRQFD without IRQ routing, enabled for XICS

2014-08-06 Thread Paolo Bonzini

Il 05/08/2014 14:27, Paolo Bonzini ha scritto:
> Il 30/06/2014 12:51, Paul Mackerras ha scritto:
>> This series of patches provides a way to implement IRQFD support
>> without having to implement IRQ routing, and adds IRQFD support for
>> the XICS interrupt controller emulation.  (XICS is the interrupt
>> controller defined for the pSeries machine type, used on IBM POWER
>> servers).
>>
>> The basic approach is to make it easy for code other than irqchip.c to
>> provide a mapping from a global interrupt number (GSI) to an irq
>> routing entry (struct kvm_kernel_irq_routing_entry).  To make the
>> lifetime of this routing entry easier to manage, we change the IRQFD
>> code to keep a copy of the routing entry (for the MSI fast-path case)
>> rather than a pointer to the routing entry.  Since the copy can't be
>> updated atomically, we add a seqcount_t to make sure that when reading
>> it we get a copy that hasn't been half-way updated.
>>
>> Next we replace the hard-coded accesses outside irqchip.c to the
>> fields of the kvm_irq_routing_table struct with calls to accessor
>> functions in irqchip.c, namely kvm_irq_map_gsi() and
>> kvm_irq_map_chip_pin().  That enables us to move all references to the
>> kvm_irq_routing_table struct, and the definition of that struct, into
>> irqchip.c.
>>
>> Then we move the irq notifier implementation from irqchip.c into
>> eventfd.c and add a separate Kconfig option to enable IRQFD.  With
>> that we can enable IRQFD without irq routing, which we achieve by
>> compiling in eventfd.c but not irqchip.c, and providing an alternative
>> implementation of kvm_irq_map_gsi() and kvm_irq_map_chip_pin().
>>
>> The last patch does that for XICS.  With this series I can use
>> vhost-net with KVM guests, and I see the TCP bandwidth between guest
>> and host on a POWER8 machine go from around 700MB/s to over 2GB/s.
>>
>> I would like to see this go into 3.17.
>>
>>  arch/ia64/kvm/Kconfig|   1 +
>>  arch/powerpc/kvm/Kconfig |   3 +
>>  arch/powerpc/kvm/book3s_hv_rm_xics.c |   5 ++
>>  arch/powerpc/kvm/book3s_xics.c   |  55 +++---
>>  arch/powerpc/kvm/book3s_xics.h   |   2 +
>>  arch/powerpc/kvm/mpic.c  |   4 +-
>>  arch/s390/kvm/Kconfig|   1 +
>>  arch/s390/kvm/interrupt.c|   3 +-
>>  arch/x86/kvm/Kconfig |   1 +
>>  include/linux/kvm_host.h |  43 ---
>>  virt/kvm/Kconfig |   3 +
>>  virt/kvm/eventfd.c   | 134 
>> ++-
>>  virt/kvm/irq_comm.c  |  24 +++
>>  virt/kvm/irqchip.c   |  98 ++---
>>  virt/kvm/kvm_main.c  |   2 +-
>>  15 files changed, 227 insertions(+), 152 deletions(-)
>>
> 
> Applied for 3.17, thanks Eric and Cornelia for testing.
> 
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

This doesn't build without CONFIG_KVM_XICS, so I had to apply a fixup
patch to move some code from being under CONFIG_HAVE_KVM_IRQCHIP or
unconditional, to being conditional on CONFIG_HAVE_KVM_IRQFD.  I'll send
the patch shortly.

Also, please look into adding a trace_kvm_set_irq call to kvm_set_irq in
arch/powerpc/kvm/book3s_xics.c.

I would have preferred these snags to be fixed before (especially since
the breakage is simply with "make ppc64_defconfig"), but it's partly my
fault for delaying the review for so long.  And the series is good work
and a very nice cleanup of the irqfd architecture.

Assuming that the linux-next merge from tomorrow is fine, I'll send the
second pull request to Linus.

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

[PATCH] KVM: Move more code under CONFIG_HAVE_KVM_IRQFD

2014-08-06 Thread Paolo Bonzini

Commits e4d57e1ee1ab (KVM: Move irq notifier implementation into
eventfd.c, 2014-06-30) included the irq notifier code unconditionally
in eventfd.c, while it was under CONFIG_HAVE_KVM_IRQCHIP before.

Similarly, commit 297e21053a52 (KVM: Give IRQFD its own separate enabling
Kconfig option, 2014-06-30) moved code from CONFIG_HAVE_IRQ_ROUTING
to CONFIG_HAVE_KVM_IRQFD but forgot to move the pieces that used to be
under CONFIG_HAVE_KVM_IRQCHIP.

Together, this broke compilation without CONFIG_KVM_XICS.  Fix by adding
or changing the #ifdefs so that they point at CONFIG_HAVE_KVM_IRQFD.

Signed-off-by: Paolo Bonzini 
---
 include/linux/kvm_host.h   |   2 +
 include/trace/events/kvm.h |   8 +--
 virt/kvm/eventfd.c | 122 ++---
 virt/kvm/kvm_main.c|   2 +
 4 files changed, 69 insertions(+), 65 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 8593d2e61cbf..a4c33b34fe3f 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -388,6 +388,8 @@ struct kvm {
 */
struct kvm_irq_routing_table __rcu *irq_routing;
struct hlist_head mask_notifier_list;
+#endif
+#ifdef CONFIG_HAVE_KVM_IRQFD
struct hlist_head irq_ack_notifier_list;
 #endif
 
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index 131a0bda7aec..908925ace776 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -37,7 +37,7 @@ TRACE_EVENT(kvm_userspace_exit,
  __entry->errno < 0 ? -__entry->errno : __entry->reason)
 );
 
-#if defined(CONFIG_HAVE_KVM_IRQCHIP)
+#if defined(CONFIG_HAVE_KVM_IRQFD)
 TRACE_EVENT(kvm_set_irq,
TP_PROTO(unsigned int gsi, int level, int irq_source_id),
TP_ARGS(gsi, level, irq_source_id),
@@ -57,7 +57,7 @@ TRACE_EVENT(kvm_set_irq,
TP_printk("gsi %u level %d source %d",
  __entry->gsi, __entry->level, __entry->irq_source_id)
 );
-#endif
+#endif /* defined(CONFIG_HAVE_KVM_IRQFD) */
 
 #if defined(__KVM_HAVE_IOAPIC)
 #define kvm_deliver_mode   \
@@ -124,7 +124,7 @@ TRACE_EVENT(kvm_msi_set_irq,
 
 #endif /* defined(__KVM_HAVE_IOAPIC) */
 
-#if defined(CONFIG_HAVE_KVM_IRQCHIP)
+#if defined(CONFIG_HAVE_KVM_IRQFD)
 
 TRACE_EVENT(kvm_ack_irq,
TP_PROTO(unsigned int irqchip, unsigned int pin),
@@ -149,7 +149,7 @@ TRACE_EVENT(kvm_ack_irq,
 #endif
 );
 
-#endif /* defined(CONFIG_HAVE_KVM_IRQCHIP) */
+#endif /* defined(CONFIG_HAVE_KVM_IRQFD) */
 
 
 
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index f5f61548f60d..3c5981c87c3f 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -445,6 +445,67 @@ out:
kfree(irqfd);
return ret;
 }
+
+bool kvm_irq_has_notifier(struct kvm *kvm, unsigned irqchip, unsigned pin)
+{
+   struct kvm_irq_ack_notifier *kian;
+   int gsi, idx;
+
+   idx = srcu_read_lock(&kvm->irq_srcu);
+   gsi = kvm_irq_map_chip_pin(kvm, irqchip, pin);
+   if (gsi != -1)
+   hlist_for_each_entry_rcu(kian, &kvm->irq_ack_notifier_list,
+link)
+   if (kian->gsi == gsi) {
+   srcu_read_unlock(&kvm->irq_srcu, idx);
+   return true;
+   }
+
+   srcu_read_unlock(&kvm->irq_srcu, idx);
+
+   return false;
+}
+EXPORT_SYMBOL_GPL(kvm_irq_has_notifier);
+
+void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
+{
+   struct kvm_irq_ack_notifier *kian;
+   int gsi, idx;
+
+   trace_kvm_ack_irq(irqchip, pin);
+
+   idx = srcu_read_lock(&kvm->irq_srcu);
+   gsi = kvm_irq_map_chip_pin(kvm, irqchip, pin);
+   if (gsi != -1)
+   hlist_for_each_entry_rcu(kian, &kvm->irq_ack_notifier_list,
+link)
+   if (kian->gsi == gsi)
+   kian->irq_acked(kian);
+   srcu_read_unlock(&kvm->irq_srcu, idx);
+}
+
+void kvm_register_irq_ack_notifier(struct kvm *kvm,
+  struct kvm_irq_ack_notifier *kian)
+{
+   mutex_lock(&kvm->irq_lock);
+   hlist_add_head_rcu(&kian->link, &kvm->irq_ack_notifier_list);
+   mutex_unlock(&kvm->irq_lock);
+#ifdef __KVM_HAVE_IOAPIC
+   kvm_vcpu_request_scan_ioapic(kvm);
+#endif
+}
+
+void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
+   struct kvm_irq_ack_notifier *kian)
+{
+   mutex_lock(&kvm->irq_lock);
+   hlist_del_init_rcu(&kian->link);
+   mutex_unlock(&kvm->irq_lock);
+   synchronize_srcu(&kvm->irq_srcu);
+#ifdef __KVM_HAVE_IOAPIC
+   kvm_vcpu_request_scan_ioapic(kvm);
+#endif
+}
 #endif
 
 void
@@ -867,64 +928,3 @@ kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
 
return kvm_assign_ioeventfd(kvm, args);
 }
-
-bool kvm_irq_has_notifier(struct kvm *kvm, unsigned irqchip, unsigned pin)
-{
-   struct kvm_irq_ack_notifier *kian;
-

Re: [PATCH 1/5] kvmtool: ARM: Use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target cpu

2014-08-06 Thread Will Deacon

On Tue, Aug 05, 2014 at 09:49:55AM +0100, Anup Patel wrote:
> Instead, of trying out each and every target type we should use
> KVM_ARM_PREFERRED_TARGET vm ioctl to determine target type
> for KVM ARM/ARM64.
> 
> We bail-out target type returned by KVM_ARM_PREFERRED_TARGET vm ioctl
> is not known to kvmtool.

-ENOPARSE

> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  tools/kvm/arm/kvm-cpu.c |   21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/kvm/arm/kvm-cpu.c b/tools/kvm/arm/kvm-cpu.c
> index aeaa4cf..7478f8f 100644
> --- a/tools/kvm/arm/kvm-cpu.c
> +++ b/tools/kvm/arm/kvm-cpu.c
> @@ -34,6 +34,7 @@ struct kvm_cpu *kvm_cpu__arch_init(struct kvm *kvm, 
> unsigned long cpu_id)
>   struct kvm_cpu *vcpu;
>   int coalesced_offset, mmap_size, err = -1;
>   unsigned int i;
> + struct kvm_vcpu_init preferred_init;
>   struct kvm_vcpu_init vcpu_init = {
>   .features = ARM_VCPU_FEATURE_FLAGS(kvm, cpu_id)
>   };
> @@ -46,6 +47,10 @@ struct kvm_cpu *kvm_cpu__arch_init(struct kvm *kvm, 
> unsigned long cpu_id)
>   if (vcpu->vcpu_fd < 0)
>   die_perror("KVM_CREATE_VCPU ioctl");
>  
> + err = ioctl(kvm->vm_fd, KVM_ARM_PREFERRED_TARGET, &preferred_init);
> + if (err < 0)
> + die_perror("KVM_ARM_PREFERRED_TARGET ioctl");

Is this ioctl always available? If not, I don't like dying here as that
could cause a regression under older hosts.

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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Alex Williamson

On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
> From: Alexey Kardashevskiy 
> 
> The existing vfio_pci_open() fails upon error returned from
> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
> support which this patch brings back.
> 
> The patch fixes the issue by dropping the return value of
> vfio_spapr_pci_eeh_open().
> 
> Signed-off-by: Alexey Kardashevskiy 
> Signed-off-by: Gavin Shan 
> ---
> v3: Drop return value of vfio_spapr_pci_eeh_open()
> ---
>  drivers/vfio/pci/vfio_pci.c   | 6 +-
>  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
>  include/linux/vfio.h  | 5 ++---
>  3 files changed, 5 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index e2ee80f..32d69c8 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
>   if (ret)
>   goto error;
>  
> - ret = vfio_spapr_pci_eeh_open(vdev->pdev);
> - if (ret) {
> - vfio_pci_disable(vdev);
> - goto error;
> - }
> + vfio_spapr_pci_eeh_open(vdev->pdev);
>   }
>  
>   return 0;
> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> index 4779cac..86dfceb 100644
> --- a/drivers/vfio/vfio_spapr_eeh.c
> +++ b/drivers/vfio/vfio_spapr_eeh.c
> @@ -19,9 +19,9 @@
>  #define DRIVER_DESC  "VFIO IOMMU SPAPR EEH"
>  
>  /* We might build address mapping here for "fast" path later */
> -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>  {
> - return eeh_dev_open(pdev);
> + eeh_dev_open(pdev);

Wasn't there some intent to provide a warning message, that would now be
done here?  Has that idea been dropped?

>  }
>  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>  
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 224128a..d320411 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
> vfio_group *group,
>  
>  struct pci_dev;
>  #ifdef CONFIG_EEH
> -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
> +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
>  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>  unsigned int cmd,
>  unsigned long arg);
>  #else
> -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>  {
> - return 0;
>  }
>  
>  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)



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

Re: [PATCH 2/5] kvmtool: ARM64: Fix compile error for aarch64

2014-08-06 Thread Will Deacon

On Tue, Aug 05, 2014 at 09:49:56AM +0100, Anup Patel wrote:
> The __ARM64_SYS_REG() macro is already defined in uapi/asm/kvm.h
> of Linux-3.16-rcX hence remove it from arm/aarch64/kvm-cpu.c

I've been carrying a similar patch in my kvmtool/arm branch, but upstream
kvmtool is still based on 3.13, so this isn't needed at the moment.

Do you have a need for Pekka to merge in the latest kernel sources?

Will
--
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 3/5] kvmtool: ARM64: Add target type potenza for aarch64

2014-08-06 Thread Will Deacon

On Tue, Aug 05, 2014 at 09:49:57AM +0100, Anup Patel wrote:
> The VCPU target type KVM_ARM_TARGET_XGENE_POTENZA is available
> in latest Linux-3.16-rcX or higher hence register aarch64 target
> type for it.
> 
> This patch enables us to run KVMTOOL on X-Gene Potenza host.
> 
> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  tools/kvm/arm/aarch64/arm-cpu.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/kvm/arm/aarch64/arm-cpu.c b/tools/kvm/arm/aarch64/arm-cpu.c
> index ce5ea2f..ce526e3 100644
> --- a/tools/kvm/arm/aarch64/arm-cpu.c
> +++ b/tools/kvm/arm/aarch64/arm-cpu.c
> @@ -41,10 +41,17 @@ static struct kvm_arm_target target_cortex_a57 = {
>   .init   = arm_cpu__vcpu_init,
>  };
>  
> +static struct kvm_arm_target target_potenza = {
> + .id = KVM_ARM_TARGET_XGENE_POTENZA,
> + .compatible = "arm,arm-v8",
> + .init   = arm_cpu__vcpu_init,
> +};

This implies you have the same PPIs for the arch-timer as the Cortex-A CPUs.
Is that right?

Will
--
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 4/5] kvmtool: Handle exit reason KVM_EXIT_SYSTEM_EVENT

2014-08-06 Thread Will Deacon

On Tue, Aug 05, 2014 at 09:49:58AM +0100, Anup Patel wrote:
> The KVM_EXIT_SYSTEM_EVENT exit reason was added to define
> architecture independent system-wide events for a Guest.
> 
> Currently, it is used by in-kernel PSCI-0.2 emulation of
> KVM ARM/ARM64 to inform user space about PSCI SYSTEM_OFF
> or PSCI SYSTEM_RESET request.
> 
> For now, we simply treat all system-wide guest events as
> same and shutdown the guest upon KVM_EXIT_SYSTEM_EVENT.
> 
> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  tools/kvm/kvm-cpu.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/kvm/kvm-cpu.c b/tools/kvm/kvm-cpu.c
> index ee0a8ec..e20ee4b 100644
> --- a/tools/kvm/kvm-cpu.c
> +++ b/tools/kvm/kvm-cpu.c
> @@ -160,6 +160,12 @@ int kvm_cpu__start(struct kvm_cpu *cpu)
>   goto exit_kvm;
>   case KVM_EXIT_SHUTDOWN:
>   goto exit_kvm;
> + case KVM_EXIT_SYSTEM_EVENT:
> + /*
> +  * Treat both SHUTDOWN & RESET system events
> +  * as shutdown request.
> +  */
> + goto exit_kvm;

Can we figure out whether this was a SHUTDOWN or RESET request? If so,
printing a message for the latter "RESET request received -- exiting KVM"
might be informative.

Will
--
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 5/5] kvmtool: ARM/ARM64: Provide PSCI-0.2 guest when in-kernel KVM supports it

2014-08-06 Thread Will Deacon

On Tue, Aug 05, 2014 at 09:49:59AM +0100, Anup Patel wrote:
> If in-kernel KVM support PSCI-0.2 emulation then we should set
> KVM_ARM_VCPU_PSCI_0_2 feature for each guest VCPU and also
> provide "arm,psci-0.2","arm,psci" as PSCI compatible string.
> 
> This patch updates kvm_cpu__arch_init() and setup_fdt() as
> per above.
> 
> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  tools/kvm/arm/fdt.c |   39 +--
>  tools/kvm/arm/kvm-cpu.c |5 +
>  2 files changed, 38 insertions(+), 6 deletions(-)

[...]

> diff --git a/tools/kvm/arm/kvm-cpu.c b/tools/kvm/arm/kvm-cpu.c
> index 7478f8f..76c28a0 100644
> --- a/tools/kvm/arm/kvm-cpu.c
> +++ b/tools/kvm/arm/kvm-cpu.c
> @@ -74,6 +74,11 @@ struct kvm_cpu *kvm_cpu__arch_init(struct kvm *kvm, 
> unsigned long cpu_id)
>   die("preferred target not available\n");
>   }
>  
> + /* Set KVM_ARM_VCPU_PSCI_0_2 if available */
> + if (kvm__supports_extension(kvm, KVM_CAP_ARM_PSCI_0_2)) {
> + vcpu_init.features[0] |= (1UL << KVM_ARM_VCPU_PSCI_0_2);
> + }

Where is this used?

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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Alexey Kardashevskiy

On 08/06/2014 10:50 PM, Alex Williamson wrote:
> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
>> From: Alexey Kardashevskiy 
>>
>> The existing vfio_pci_open() fails upon error returned from
>> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
>> support which this patch brings back.
>>
>> The patch fixes the issue by dropping the return value of
>> vfio_spapr_pci_eeh_open().
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> Signed-off-by: Gavin Shan 
>> ---
>> v3: Drop return value of vfio_spapr_pci_eeh_open()
>> ---
>>  drivers/vfio/pci/vfio_pci.c   | 6 +-
>>  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
>>  include/linux/vfio.h  | 5 ++---
>>  3 files changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
>> index e2ee80f..32d69c8 100644
>> --- a/drivers/vfio/pci/vfio_pci.c
>> +++ b/drivers/vfio/pci/vfio_pci.c
>> @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
>>  if (ret)
>>  goto error;
>>  
>> -ret = vfio_spapr_pci_eeh_open(vdev->pdev);
>> -if (ret) {
>> -vfio_pci_disable(vdev);
>> -goto error;
>> -}
>> +vfio_spapr_pci_eeh_open(vdev->pdev);
>>  }
>>  
>>  return 0;
>> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
>> index 4779cac..86dfceb 100644
>> --- a/drivers/vfio/vfio_spapr_eeh.c
>> +++ b/drivers/vfio/vfio_spapr_eeh.c
>> @@ -19,9 +19,9 @@
>>  #define DRIVER_DESC "VFIO IOMMU SPAPR EEH"
>>  
>>  /* We might build address mapping here for "fast" path later */
>> -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>> +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>  {
>> -return eeh_dev_open(pdev);
>> +eeh_dev_open(pdev);
> 
> Wasn't there some intent to provide a warning message, that would now be
> done here?  Has that idea been dropped?


Comrade Gavin just forgot it :)

Gavin, please add it. Thanks!



> 
>>  }
>>  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>>  
>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>> index 224128a..d320411 100644
>> --- a/include/linux/vfio.h
>> +++ b/include/linux/vfio.h
>> @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
>> vfio_group *group,
>>  
>>  struct pci_dev;
>>  #ifdef CONFIG_EEH
>> -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>> +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>>  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
>>  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>> unsigned int cmd,
>> unsigned long arg);
>>  #else
>> -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>> +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>  {
>> -return 0;
>>  }
>>  
>>  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
> 
> 
> 


-- 
Alexey
--
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: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table

2014-08-06 Thread Zhang, Yang Z

Paolo Bonzini wrote on 2014-07-31:
> Currently, the EOI exit bitmap (used for APICv) does not include
> interrupts that are masked.  However, this can cause a bug that manifests
> as an interrupt storm inside the guest.  Alex Williamson reported the
> bug and is the one who really debugged this; I only wrote the patch. :)
> 
> The scenario involves a multi-function PCI device with OHCI and EHCI
> USB functions and an audio function, all assigned to the guest, where
> both USB functions use legacy INTx interrupts.
> 
> As soon as the guest boots, interrupts for these devices turn into an
> interrupt storm in the guest; the host does not see the interrupt storm.
> Basically the EOI path does not work, and the guest continues to see the
> interrupt over and over, even after it attempts to mask it at the APIC.
> The bug is only visible with older kernels (RHEL6.5, based on 2.6.32
> with not many changes in the area of APIC/IOAPIC handling).
> 
> Alex then tried forcing bit 59 (corresponding to the USB functions' IRQ)
> on in the eoi_exit_bitmap and TMR, and things then work.  What happens
> is that VFIO asserts IRQ11, then KVM recomputes the EOI exit bitmap.
> It does not have set bit 59 because the RTE was masked, so the IOAPIC
> never sees the EOI and the interrupt continues to fire in the guest.
> 
> Probably, the guest is masking the interrupt in the redirection table in
> the interrupt routine, i.e. while the interrupt is set in a LAPIC's ISR.
> The simplest fix is to ignore the masking state, we would rather have
> an unnecessary exit rather than a missed IRQ ACK and anyway IOAPIC
> interrupts are not as performance-sensitive as for example MSIs.

I feel this fixing may hurt performance in some cases. If the mask bit is set, 
this means the vector in this entry may be used by other devices(like a 
assigned device). But here you set it in eoi exit bitmap and this will cause 
vmexit on each EOI which should not happen.

> 
> [Thanks to Alex for his precise description of the problem
>  and initial debugging effort.  A lot of the text above is
>  based on emails exchanged with him.]
> 
> Reported-by: Alex Williamson 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paolo Bonzini 
> ---
>  virt/kvm/ioapic.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index 2458a1dc2ba9..e8ce34c9db32 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -254,10 +254,9 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu,
> u64 *eoi_exit_bitmap,
>   spin_lock(&ioapic->lock);
>   for (index = 0; index < IOAPIC_NUM_PINS; index++) {
>   e = &ioapic->redirtbl[index];
> - if (!e->fields.mask &&
> - (e->fields.trig_mode == IOAPIC_LEVEL_TRIG ||
> -  kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC,
> -  index) || index == RTC_GSI)) {
> + if (e->fields.trig_mode == IOAPIC_LEVEL_TRIG ||
> + kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC, index)
> ||
> + index == RTC_GSI) {
>   if (kvm_apic_match_dest(vcpu, NULL, 0,
>   e->fields.dest_id, e->fields.dest_mode)) {
>   __set_bit(e->fields.vector,

Best regards,
Yang


--
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: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table

2014-08-06 Thread Paolo Bonzini

Il 06/08/2014 16:03, Zhang, Yang Z ha scritto:
> Paolo Bonzini wrote on 2014-07-31:
>> Probably, the guest is masking the interrupt in the redirection table in
>> the interrupt routine, i.e. while the interrupt is set in a LAPIC's ISR.
>> The simplest fix is to ignore the masking state, we would rather have
>> an unnecessary exit rather than a missed IRQ ACK and anyway IOAPIC
>> interrupts are not as performance-sensitive as for example MSIs.
> 
> I feel this fixing may hurt performance in some cases. If the mask
> bit is set, this means the vector in this entry may be used by other
> devices(like a assigned device). But here you set it in eoi exit bitmap
> and this will cause vmexit on each EOI which should not happen.

Note that this *was* reported on an assigned device.

IOAPIC should not be a performance-sensitive path.  High-performance
assigned devices should be using MSIs.

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

Re: [RFC PATCH 2/6] ARM64: perf: Re-enable overflow interrupt from interrupt handler

2014-08-06 Thread Will Deacon

On Tue, Aug 05, 2014 at 10:24:11AM +0100, Anup Patel wrote:
> A hypervisor will typically mask the overflow interrupt before
> forwarding it to Guest Linux hence we need to re-enable the overflow
> interrupt after clearing it in Guest Linux. Also, this re-enabling
> of overflow interrupt does not harm in non-virtualized scenarios.
> 
> Signed-off-by: Pranavkumar Sawargaonkar 
> Signed-off-by: Anup Patel 
> ---
>  arch/arm64/kernel/perf_event.c |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 47dfb8b..19fb140 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -1076,6 +1076,14 @@ static irqreturn_t armv8pmu_handle_irq(int irq_num, 
> void *dev)
>   if (!armv8pmu_counter_has_overflowed(pmovsr, idx))
>   continue;
>  
> + /*
> +  * If we are running under a hypervisor such as KVM then
> +  * hypervisor will mask the interrupt before forwarding
> +  * it to Guest Linux hence re-enable interrupt for the
> +  * overflowed counter.
> +  */
> + armv8pmu_enable_intens(idx);
> +

Really? This is a giant bodge in the guest to work around short-comings in
the hypervisor. Why can't we fix this properly using something like Marc's
irq forwarding code?

Will
--
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

High performance with Virtio - librte_pmd_virtio

2014-08-06 Thread Emerson Barea

Hi there.

I'm trying to use librte_pmd_virtio and I got success in the test indicated
in README file. But now, I want to know how I create a vm using this dpdk
tunned virtio.

Somebody knows how can I create this vm?

qemu-system-x86_64 -hda image.img (what more???)

Thank you.

Emerson Barea
--
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: High performance with Virtio - librte_pmd_virtio

2014-08-06 Thread Vincent JARDIN


Check on dev DPDK mailing list.

It should help:
  http://dpdk.org/doc/virtio-net-pmd


On 06/08/2014 16:47, Emerson Barea wrote:

Hi there.

I'm trying to use librte_pmd_virtio and I got success in the test indicated
in README file. But now, I want to know how I create a vm using this dpdk
tunned virtio.

Somebody knows how can I create this vm?

qemu-system-x86_64 -hda image.img (what more???)

Thank you.

Emerson Barea
--
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



--
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: High performance with Virtio - librte_pmd_virtio

2014-08-06 Thread Emerson Barea

Thank you for your response, but, how I said previously, I already did
this test and its was ok. My question is how can I call virtio using
this librte_pmd_virtio dpdk library.

Somebody knows?


2014-08-06 11:56 GMT-03:00 Vincent JARDIN :
> Check on dev DPDK mailing list.
>
> It should help:
>   http://dpdk.org/doc/virtio-net-pmd
>
>
>
> On 06/08/2014 16:47, Emerson Barea wrote:
>>
>> Hi there.
>>
>> I'm trying to use librte_pmd_virtio and I got success in the test
>> indicated
>> in README file. But now, I want to know how I create a vm using this dpdk
>> tunned virtio.
>>
>> Somebody knows how can I create this vm?
>>
>> qemu-system-x86_64 -hda image.img (what more???)
>>
>> Thank you.
>>
>> Emerson Barea
>> --
>> 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
>>
>
--
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: High performance with Virtio - librte_pmd_virtio

2014-08-06 Thread Vincent JARDIN

you should never need to call it. We did design this PMD to be a plugin 
of DPDK applications. It is not a KVM talk! -> DPDK.


On 06/08/2014 17:02, Emerson Barea wrote:

Thank you for your response, but, how I said previously, I already did
this test and its was ok. My question is how can I call virtio using
this librte_pmd_virtio dpdk library.

Somebody knows?


2014-08-06 11:56 GMT-03:00 Vincent JARDIN :

Check on dev DPDK mailing list.

It should help:
   http://dpdk.org/doc/virtio-net-pmd



On 06/08/2014 16:47, Emerson Barea wrote:


Hi there.

I'm trying to use librte_pmd_virtio and I got success in the test
indicated
in README file. But now, I want to know how I create a vm using this dpdk
tunned virtio.

Somebody knows how can I create this vm?

qemu-system-x86_64 -hda image.img (what more???)

Thank you.

Emerson Barea
--
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





--
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: KVM on ARM64

2014-08-06 Thread Christoffer Dall

On Tue, Aug 5, 2014 at 4:18 PM, Joel Schopp  wrote:
>
> On 08/04/2014 07:35 PM, Mathew Li wrote:
>> Hi,
>>
>> I have a quick question. How do we add a hard disk to the qemu ARM VM?
>>
>> I tried:
>>
>> qemu-system-aarch64 -machine virt -hda disk.img -kernel image -initrd 
>> initrd.img
>>
>> qemu-system-aarch64 -machine virt -sd disk.img -kernel image -initrd 
>> initrd.img
>>
>> qemu-system-aarch64 -machine virt -mtdblock disk.img -kernel image
>> -initrd initrd.img
>>
>> Nothing seems to work. I am not able to see any disk (i.e. dev/sdX)
>> inside guest OS.
> I've been running something like this:
>
> qemu-system-aarch64 -smp 1 --enable-kvm -nographic -netdev 
> tap,id=t0,ifname=tap0,script=no,downscript=no,vhost=on -device 
> virtio-net-device,netdev=t0,id=nic0 \
> -kernel /extra/rootfs/boot/Image -drive file=/extra/rootfs.img,id=fs -device 
> virtio-blk-device,drive=fs -m 512 -M virt -cpu host -append "console=ttyAMA0 
> console=ttyS0 root=/dev/vda"
>
>
> On my system -smp 2 or higher hangs in the guest kernel.

The -smp 2 hang issue is probably due to a missing PSCI v0.2 follow-up
patch to QEMU, you can try:
https://git.linaro.org/people/christoffer.dall/qemu-arm.git/shortlog/refs/heads/psci2-smp-fix

[disclaimer: there may be a better fix somewhere on the qemu list, I
haven't kept track the last couple of days]

-Christoffer
--
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: High performance with Virtio - librte_pmd_virtio

2014-08-06 Thread Emerson Barea

Great.

Thank you Vincent.



2014-08-06 13:15 GMT-03:00 Vincent JARDIN :
> you should never need to call it. We did design this PMD to be a plugin of
> DPDK applications. It is not a KVM talk! -> DPDK.
>
>
> On 06/08/2014 17:02, Emerson Barea wrote:
>>
>> Thank you for your response, but, how I said previously, I already did
>> this test and its was ok. My question is how can I call virtio using
>> this librte_pmd_virtio dpdk library.
>>
>> Somebody knows?
>>
>>
>> 2014-08-06 11:56 GMT-03:00 Vincent JARDIN :
>>>
>>> Check on dev DPDK mailing list.
>>>
>>> It should help:
>>>http://dpdk.org/doc/virtio-net-pmd
>>>
>>>
>>>
>>> On 06/08/2014 16:47, Emerson Barea wrote:


 Hi there.

 I'm trying to use librte_pmd_virtio and I got success in the test
 indicated
 in README file. But now, I want to know how I create a vm using this
 dpdk
 tunned virtio.

 Somebody knows how can I create this vm?

 qemu-system-x86_64 -hda image.img (what more???)

 Thank you.

 Emerson Barea
 --
 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

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

[PATCH] KVM: PPC: e500mc: Add support for single threaded vcpus on e6500 core

2014-08-06 Thread Mihai Caraman

ePAPR represents hardware threads as cpu node properties in device tree.
So with existing QEMU, hardware threads are simply exposed as vcpus with
one hardware thread.

The e6500 core shares TLBs between hardware threads. Without tlb write
conditional instruction, the Linux kernel uses per core mechanisms to
protect against duplicate TLB entries.

The guest is unable to detect real siblings threads, so it can't use a
TLB protection mechanism. An alternative solution is to use the hypervisor
to allocate different lpids to guest's vcpus running simultaneous on real
siblings threads. This patch moves lpid to vcpu level and allocates a pool
of lpids (equal to the number of threads per core) per VM.

Signed-off-by: Mihai Caraman 
---
 Please rebase this patch before
[PATCH v3 5/5] KVM: PPC: Book3E: Enable e6500 core
 to proper handle SMP guests.

 arch/powerpc/include/asm/kvm_host.h |  5 
 arch/powerpc/kernel/asm-offsets.c   |  4 +++
 arch/powerpc/kvm/e500_mmu_host.c| 15 +-
 arch/powerpc/kvm/e500mc.c   | 55 +
 4 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 98d9dd5..1b0bb4a 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -227,7 +227,11 @@ struct kvm_arch_memory_slot {
 };
 
 struct kvm_arch {
+#ifdef CONFIG_KVM_BOOKE_HV
+   unsigned int lpid_pool[2];
+#else
unsigned int lpid;
+#endif
 #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
unsigned long hpt_virt;
struct revmap_entry *revmap;
@@ -435,6 +439,7 @@ struct kvm_vcpu_arch {
u32 eplc;
u32 epsc;
u32 oldpir;
+   u32 lpid;
 #endif
 
 #if defined(CONFIG_BOOKE)
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index ab9ae04..5a30b87 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -483,7 +483,11 @@ int main(void)
DEFINE(VCPU_SHARED_MAS6, offsetof(struct kvm_vcpu_arch_shared, mas6));
 
DEFINE(VCPU_KVM, offsetof(struct kvm_vcpu, kvm));
+#ifdef CONFIG_KVM_BOOKE_HV
+   DEFINE(KVM_LPID, offsetof(struct kvm_vcpu, arch.lpid));
+#else
DEFINE(KVM_LPID, offsetof(struct kvm, arch.lpid));
+#endif
 
/* book3s */
 #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 4150826..a233cc6 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -69,7 +69,7 @@ static inline u32 e500_shadow_mas3_attrib(u32 mas3, int 
usermode)
  * writing shadow tlb entry to host TLB
  */
 static inline void __write_host_tlbe(struct kvm_book3e_206_tlb_entry *stlbe,
-uint32_t mas0)
+uint32_t mas0, uint32_t *lpid)
 {
unsigned long flags;
 
@@ -80,6 +80,8 @@ static inline void __write_host_tlbe(struct 
kvm_book3e_206_tlb_entry *stlbe,
mtspr(SPRN_MAS3, (u32)stlbe->mas7_3);
mtspr(SPRN_MAS7, (u32)(stlbe->mas7_3 >> 32));
 #ifdef CONFIG_KVM_BOOKE_HV
+   /* populate mas8 with latest LPID */
+   stlbe->mas8 = MAS8_TGS | *lpid;
mtspr(SPRN_MAS8, stlbe->mas8);
 #endif
asm volatile("isync; tlbwe" : : : "memory");
@@ -129,11 +131,12 @@ static inline void write_host_tlbe(struct 
kvmppc_vcpu_e500 *vcpu_e500,
 
if (tlbsel == 0) {
mas0 = get_host_mas0(stlbe->mas2);
-   __write_host_tlbe(stlbe, mas0);
+   __write_host_tlbe(stlbe, mas0, &vcpu_e500->vcpu.arch.lpid);
} else {
__write_host_tlbe(stlbe,
  MAS0_TLBSEL(1) |
- MAS0_ESEL(to_htlb1_esel(sesel)));
+ MAS0_ESEL(to_htlb1_esel(sesel)),
+ &vcpu_e500->vcpu.arch.lpid);
}
 }
 
@@ -318,9 +321,7 @@ static void kvmppc_e500_setup_stlbe(
stlbe->mas7_3 = ((u64)pfn << PAGE_SHIFT) |
e500_shadow_mas3_attrib(gtlbe->mas7_3, pr);
 
-#ifdef CONFIG_KVM_BOOKE_HV
-   stlbe->mas8 = MAS8_TGS | vcpu->kvm->arch.lpid;
-#endif
+   /* Set mas8 when executing tlbwe since LPID can change dynamically */
 }
 
 static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
@@ -632,7 +633,7 @@ int kvmppc_load_last_inst(struct kvm_vcpu *vcpu, enum 
instruction_type type,
 
local_irq_save(flags);
mtspr(SPRN_MAS6, (vcpu->arch.pid << MAS6_SPID_SHIFT) | addr_space);
-   mtspr(SPRN_MAS5, MAS5_SGS | vcpu->kvm->arch.lpid);
+   mtspr(SPRN_MAS5, MAS5_SGS | vcpu->arch.lpid);
asm volatile("tlbsx 0, %[geaddr]\n" : :
 [geaddr] "r" (geaddr));
mtspr(SPRN_MAS5, 0);
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index aa48dc3..c0a0d9d 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -24,6

Re: KVM on ARM64

2014-08-06 Thread Joel Schopp

It turns out that after a recent rebase of my kernel and qemu to the
latest the problem is fixed.  Rather than hunt down what fixed it I'm
just accepting the win and moving on. -smp 4 now works.

-Joel

On 08/06/2014 11:15 AM, Christoffer Dall wrote:
> On Tue, Aug 5, 2014 at 4:18 PM, Joel Schopp  wrote:
>> On 08/04/2014 07:35 PM, Mathew Li wrote:
>>> Hi,
>>>
>>> I have a quick question. How do we add a hard disk to the qemu ARM VM?
>>>
>>> I tried:
>>>
>>> qemu-system-aarch64 -machine virt -hda disk.img -kernel image -initrd 
>>> initrd.img
>>>
>>> qemu-system-aarch64 -machine virt -sd disk.img -kernel image -initrd 
>>> initrd.img
>>>
>>> qemu-system-aarch64 -machine virt -mtdblock disk.img -kernel image
>>> -initrd initrd.img
>>>
>>> Nothing seems to work. I am not able to see any disk (i.e. dev/sdX)
>>> inside guest OS.
>> I've been running something like this:
>>
>> qemu-system-aarch64 -smp 1 --enable-kvm -nographic -netdev 
>> tap,id=t0,ifname=tap0,script=no,downscript=no,vhost=on -device 
>> virtio-net-device,netdev=t0,id=nic0 \
>> -kernel /extra/rootfs/boot/Image -drive file=/extra/rootfs.img,id=fs -device 
>> virtio-blk-device,drive=fs -m 512 -M virt -cpu host -append "console=ttyAMA0 
>> console=ttyS0 root=/dev/vda"
>>
>>
>> On my system -smp 2 or higher hangs in the guest kernel.
> The -smp 2 hang issue is probably due to a missing PSCI v0.2 follow-up
> patch to QEMU, you can try:
> https://git.linaro.org/people/christoffer.dall/qemu-arm.git/shortlog/refs/heads/psci2-smp-fix
>
> [disclaimer: there may be a better fix somewhere on the qemu list, I
> haven't kept track the last couple of days]
>
> -Christoffer

--
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

verify your account

2014-08-06 Thread WEBMASTER

Dear user

 Your email has exceeded 2 GB created by the webmaster, you are currently 
running at 2.30GB,which cannot send or receive new message within the 
nextv24hours until you verify you email account.

Please enter y verify your account :

(1) E-mail:
(2) Name:
(3) Password:
(4) Confirm Password:

thank you
System Administrator.
--
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] target-i386: Add MPX CPU feature name

2014-08-06 Thread Eduardo Habkost

Migration support for MPX is already implemented, so we can add it to
the list of known feature names.

Signed-off-by: Eduardo Habkost 
---
 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 6d008ab..749f9cb 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -258,7 +258,7 @@ static const char *svm_feature_name[] = {
 
 static const char *cpuid_7_0_ebx_feature_name[] = {
 "fsgsbase", NULL, NULL, "bmi1", "hle", "avx2", NULL, "smep",
-"bmi2", "erms", "invpcid", "rtm", NULL, NULL, NULL, NULL,
+"bmi2", "erms", "invpcid", "rtm", NULL, NULL, "mpx", NULL,
 NULL, NULL, "rdseed", "adx", "smap", NULL, NULL, NULL,
 NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 };
-- 
1.9.3

--
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] target-i386: Add tsc_adjust CPU feature name

2014-08-06 Thread Eduardo Habkost

tsc_adjust migration support was implemented almost 2 years ago, by
commit f28558d3d37ad3bc4e35e8ac93f7bf81a0d5622c, so QEMU can safely
recognize the feature name.

Signed-off-by: Eduardo Habkost 
---
This needs to be applied after:
 [PATCH] target-i386: Add MPX CPU feature name
which I just sent. Sorry for not making it a series, I have noticed tsc_adjust
was in the same section after I had already sent the MPX patch.
---
 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 749f9cb..535a0d7 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -257,7 +257,7 @@ static const char *svm_feature_name[] = {
 };
 
 static const char *cpuid_7_0_ebx_feature_name[] = {
-"fsgsbase", NULL, NULL, "bmi1", "hle", "avx2", NULL, "smep",
+"fsgsbase", "tsc_adjust", NULL, "bmi1", "hle", "avx2", NULL, "smep",
 "bmi2", "erms", "invpcid", "rtm", NULL, NULL, "mpx", NULL,
 NULL, NULL, "rdseed", "adx", "smap", NULL, NULL, NULL,
 NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-- 
1.9.3

--
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

pci passthrough error about insufficient iommu width

2014-08-06 Thread Nishank Trivedi


Hi

I'm trying to do a pci-passthrough of Intel 82599 10GbE card, with guest 
having 8G of memory. I see following error -


intel_iommu_map: iommu width (48) is not sufficient for the mapped 
address (fe001000)

kvm_iommu_map_address:iommu failed to map pfn=45800

I checked IOMMU capability register and SAGAW as well as MGAW are 48bits 
for both IOMMU.


# dmesg | grep ecap
dmar: IOMMU 0: reg_base_addr dfff ver 1:0 cap d2078c106f0462 ecap f020fe
dmar: IOMMU 1: reg_base_addr bfff ver 1:0 cap d2078c106f0462 ecap f020fe

# cat /proc/cpuinfo | grep "address sizes"
address sizes   : 46 bits physical, 48 bits virtual

In DMAR table, I see host address width set to "2D", i.e. 46bit, which 
is ok as it is same as physical address size. Any suggestions on what 
might be going wrong here?


Thanks,
nt

--
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: pci passthrough error about insufficient iommu width

2014-08-06 Thread Alex Williamson

On Wed, 2014-08-06 at 14:22 -0700, Nishank Trivedi wrote:
> Hi
> 
> I'm trying to do a pci-passthrough of Intel 82599 10GbE card, with guest 
> having 8G of memory. I see following error -
> 
> intel_iommu_map: iommu width (48) is not sufficient for the mapped 
> address (fe001000)
> kvm_iommu_map_address:iommu failed to map pfn=45800
> 
> I checked IOMMU capability register and SAGAW as well as MGAW are 48bits 
> for both IOMMU.
> 
> # dmesg | grep ecap
> dmar: IOMMU 0: reg_base_addr dfff ver 1:0 cap d2078c106f0462 ecap f020fe
> dmar: IOMMU 1: reg_base_addr bfff ver 1:0 cap d2078c106f0462 ecap f020fe
> 
> # cat /proc/cpuinfo | grep "address sizes"
> address sizes   : 46 bits physical, 48 bits virtual
> 
> In DMAR table, I see host address width set to "2D", i.e. 46bit, which 
> is ok as it is same as physical address size. Any suggestions on what 
> might be going wrong here?

Try vfio-pci instead of pci-assign

--
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: pci passthrough error about insufficient iommu width

2014-08-06 Thread William Tu

I encountered the same "IOMMU width is not sufficient" issue. Using
VFIO works ok for me.

On Wed, Aug 6, 2014 at 2:31 PM, Alex Williamson
 wrote:
> On Wed, 2014-08-06 at 14:22 -0700, Nishank Trivedi wrote:
>> Hi
>>
>> I'm trying to do a pci-passthrough of Intel 82599 10GbE card, with guest
>> having 8G of memory. I see following error -
>>
>> intel_iommu_map: iommu width (48) is not sufficient for the mapped
>> address (fe001000)
>> kvm_iommu_map_address:iommu failed to map pfn=45800
>>
>> I checked IOMMU capability register and SAGAW as well as MGAW are 48bits
>> for both IOMMU.
>>
>> # dmesg | grep ecap
>> dmar: IOMMU 0: reg_base_addr dfff ver 1:0 cap d2078c106f0462 ecap f020fe
>> dmar: IOMMU 1: reg_base_addr bfff ver 1:0 cap d2078c106f0462 ecap f020fe
>>
>> # cat /proc/cpuinfo | grep "address sizes"
>> address sizes   : 46 bits physical, 48 bits virtual
>>
>> In DMAR table, I see host address width set to "2D", i.e. 46bit, which
>> is ok as it is same as physical address size. Any suggestions on what
>> might be going wrong here?
>
> Try vfio-pci instead of pci-assign
>
> --
> 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
--
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: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table

2014-08-06 Thread Zhang, Yang Z

Paolo Bonzini wrote on 2014-08-06:
> Il 06/08/2014 16:03, Zhang, Yang Z ha scritto:
>> Paolo Bonzini wrote on 2014-07-31:
>>> Probably, the guest is masking the interrupt in the redirection
>>> table in the interrupt routine, i.e. while the interrupt is set in a 
>>> LAPIC's ISR.
>>> The simplest fix is to ignore the masking state, we would rather
>>> have an unnecessary exit rather than a missed IRQ ACK and anyway
>>> IOAPIC interrupts are not as performance-sensitive as for example MSIs.
>> 
>> I feel this fixing may hurt performance in some cases. If the mask
>> bit is set, this means the vector in this entry may be used by other
>> devices(like a assigned device). But here you set it in eoi exit
>> bitmap and this will cause vmexit on each EOI which should not happen.
> 
> Note that this *was* reported on an assigned device.
> 
> IOAPIC should not be a performance-sensitive path.  High-performance
> assigned devices should be using MSIs.

Let me give an example to see whether my concern is a real problem:
Guest allocates a vector and set it in IOAPIC entry to deliver interrupt. Later 
it masks the IOAPIC entry(means stop the corresponding device) and assign this 
vector to a MSI device. With this patch, even the vector is not used by IOAPIC, 
but it still set eoi exit bitmap unconditionally. The subsequent EOIs to MSI 
device will force vmexit. Could this happen?

I think the right fixing is to check the ISR plus TMR to construct the eoi exit 
bitmap.

> 
> Paolo


Best regards,
Yang

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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan

On Wed, Aug 06, 2014 at 11:05:43PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2014 10:50 PM, Alex Williamson wrote:
>> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
>>> From: Alexey Kardashevskiy 
>>>
>>> The existing vfio_pci_open() fails upon error returned from
>>> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
>>> support which this patch brings back.
>>>
>>> The patch fixes the issue by dropping the return value of
>>> vfio_spapr_pci_eeh_open().
>>>
>>> Signed-off-by: Alexey Kardashevskiy 
>>> Signed-off-by: Gavin Shan 
>>> ---
>>> v3: Drop return value of vfio_spapr_pci_eeh_open()
>>> ---
>>>  drivers/vfio/pci/vfio_pci.c   | 6 +-
>>>  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
>>>  include/linux/vfio.h  | 5 ++---
>>>  3 files changed, 5 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
>>> index e2ee80f..32d69c8 100644
>>> --- a/drivers/vfio/pci/vfio_pci.c
>>> +++ b/drivers/vfio/pci/vfio_pci.c
>>> @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
>>> if (ret)
>>> goto error;
>>>  
>>> -   ret = vfio_spapr_pci_eeh_open(vdev->pdev);
>>> -   if (ret) {
>>> -   vfio_pci_disable(vdev);
>>> -   goto error;
>>> -   }
>>> +   vfio_spapr_pci_eeh_open(vdev->pdev);
>>> }
>>>  
>>> return 0;
>>> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
>>> index 4779cac..86dfceb 100644
>>> --- a/drivers/vfio/vfio_spapr_eeh.c
>>> +++ b/drivers/vfio/vfio_spapr_eeh.c
>>> @@ -19,9 +19,9 @@
>>>  #define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
>>>  
>>>  /* We might build address mapping here for "fast" path later */
>>> -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>> +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>>  {
>>> -   return eeh_dev_open(pdev);
>>> +   eeh_dev_open(pdev);
>> 
>> Wasn't there some intent to provide a warning message, that would now be
>> done here?  Has that idea been dropped?
>
>
>Comrade Gavin just forgot it :)
>
>Gavin, please add it. Thanks!
>

Sure, I'll add following warning message in eeh_dev_open() in
separate patch in v4 in case nobody objects.

int eeh_dev_open(struct pci_dev *pdev)
{
:
/* No EEH device or PE ? */
edev = pci_dev_to_eeh_dev(pdev);
if (!edev || !edev->pe) {
pr_warn_once("%s: Device %s not supported\n",
 __func__, pci_name(pdev));
goto out;
}
:
}

Thanks,
Gavin

>
>
>> 
>>>  }
>>>  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>>>  
>>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>>> index 224128a..d320411 100644
>>> --- a/include/linux/vfio.h
>>> +++ b/include/linux/vfio.h
>>> @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
>>> vfio_group *group,
>>>  
>>>  struct pci_dev;
>>>  #ifdef CONFIG_EEH
>>> -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>>> +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>>>  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
>>>  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>>>unsigned int cmd,
>>>unsigned long arg);
>>>  #else
>>> -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>> +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>>  {
>>> -   return 0;
>>>  }
>>>  
>>>  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>> 
>> 
>> 
>
>
>-- 
>Alexey
>

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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan

On Thu, Aug 07, 2014 at 12:10:07PM +1000, Gavin Shan wrote:
>On Wed, Aug 06, 2014 at 11:05:43PM +1000, Alexey Kardashevskiy wrote:
>>On 08/06/2014 10:50 PM, Alex Williamson wrote:
>>> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
 From: Alexey Kardashevskiy 

 The existing vfio_pci_open() fails upon error returned from
 vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
 support which this patch brings back.

 The patch fixes the issue by dropping the return value of
 vfio_spapr_pci_eeh_open().

 Signed-off-by: Alexey Kardashevskiy 
 Signed-off-by: Gavin Shan 
 ---
 v3: Drop return value of vfio_spapr_pci_eeh_open()
 ---
  drivers/vfio/pci/vfio_pci.c   | 6 +-
  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
  include/linux/vfio.h  | 5 ++---
  3 files changed, 5 insertions(+), 10 deletions(-)

 diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
 index e2ee80f..32d69c8 100644
 --- a/drivers/vfio/pci/vfio_pci.c
 +++ b/drivers/vfio/pci/vfio_pci.c
 @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
if (ret)
goto error;
  
 -  ret = vfio_spapr_pci_eeh_open(vdev->pdev);
 -  if (ret) {
 -  vfio_pci_disable(vdev);
 -  goto error;
 -  }
 +  vfio_spapr_pci_eeh_open(vdev->pdev);
}
  
return 0;
 diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
 index 4779cac..86dfceb 100644
 --- a/drivers/vfio/vfio_spapr_eeh.c
 +++ b/drivers/vfio/vfio_spapr_eeh.c
 @@ -19,9 +19,9 @@
  #define DRIVER_DESC   "VFIO IOMMU SPAPR EEH"
  
  /* We might build address mapping here for "fast" path later */
 -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
  {
 -  return eeh_dev_open(pdev);
 +  eeh_dev_open(pdev);
>>> 
>>> Wasn't there some intent to provide a warning message, that would now be
>>> done here?  Has that idea been dropped?
>>
>>
>>Comrade Gavin just forgot it :)
>>
>>Gavin, please add it. Thanks!
>>
>
>Sure, I'll add following warning message in eeh_dev_open() in
>separate patch in v4 in case nobody objects.
>
>int eeh_dev_open(struct pci_dev *pdev)
>{
>:
>/* No EEH device or PE ? */
>edev = pci_dev_to_eeh_dev(pdev);
>if (!edev || !edev->pe) {
>   pr_warn_once("%s: Device %s not supported\n",
>__func__, pci_name(pdev));
>goto out;
>}
>:
>}
>

Well, I added the warning message in eeh_dev_open() and sending "v4" out.

Thanks,
Gavin

>
>>
>>
>>> 
  }
  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
  
 diff --git a/include/linux/vfio.h b/include/linux/vfio.h
 index 224128a..d320411 100644
 --- a/include/linux/vfio.h
 +++ b/include/linux/vfio.h
 @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
 vfio_group *group,
  
  struct pci_dev;
  #ifdef CONFIG_EEH
 -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
   unsigned int cmd,
   unsigned long arg);
  #else
 -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
  {
 -  return 0;
  }
  
  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>>> 
>>> 
>>> 
>>
>>
>>-- 
>>Alexey
>>

--
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 v4 1/5] powerpc/eeh: Export eeh_iommu_group_to_pe()

2014-08-06 Thread Gavin Shan

The function is used by VFIO driver, which might be built as a
dynamic module. So it should be exported.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1254,6 +1254,7 @@ struct eeh_pe *eeh_iommu_group_to_pe(struct iommu_group 
*group)
 
return edev->pe;
 }
+EXPORT_SYMBOL_GPL(eeh_iommu_group_to_pe);
 
 #endif /* CONFIG_IOMMU_API */
 
-- 
1.8.3.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

[PATCH v4 2/5] powerpc/eeh: Add warning message in eeh_dev_open()

2014-08-06 Thread Gavin Shan

The patch adds one warning message in eeh_dev_open() in case the
PCI device can't be marked as passed through.

Suggested-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 59a64f8..5d73a49 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1162,8 +1162,11 @@ int eeh_dev_open(struct pci_dev *pdev)
 
/* No EEH device or PE ? */
edev = pci_dev_to_eeh_dev(pdev);
-   if (!edev || !edev->pe)
+   if (!edev || !edev->pe) {
+   pr_warn_once("%s: PCI device %s not supported\n",
+__func__, pci_name(pdev));
goto out;
+   }
 
/* Increase PE's pass through count */
atomic_inc(&edev->pe->pass_dev_cnt);
-- 
1.8.3.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

[PATCH v4 3/5] drivers/vfio: Fix EEH build error

2014-08-06 Thread Gavin Shan

The VFIO related components could be built as dynamic modules.
Unfortunately, CONFIG_EEH can't be configured to "m". The patch
fixes the build errors when configuring VFIO related components
as dynamic modules as follows:

  CC [M]  drivers/vfio/vfio_iommu_spapr_tce.o
In file included from drivers/vfio/vfio.c:33:0:
include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
inside parameter list [enabled by default]
   :
  WRAParch/powerpc/boot/zImage.pseries
  WRAParch/powerpc/boot/zImage.maple
  WRAParch/powerpc/boot/zImage.pmac
  WRAParch/powerpc/boot/zImage.epapr
  MODPOST 1818 modules
ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
Signed-off-by: Alexey Kardashevskiy 
---
v3: Introduce CONFIG_VFIO_SPAPR_EEH and add "struct pci_dev" in vfio.h
v2: remove #include  from vfio.c
---
 drivers/vfio/Kconfig  | 6 ++
 drivers/vfio/Makefile | 2 +-
 drivers/vfio/vfio_spapr_eeh.c | 3 +++
 include/linux/vfio.h  | 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index af7b204..d8c5763 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -8,11 +8,17 @@ config VFIO_IOMMU_SPAPR_TCE
depends on VFIO && SPAPR_TCE_IOMMU
default n
 
+config VFIO_SPAPR_EEH
+   tristate
+   depends on EEH && VFIO_IOMMU_SPAPR_TCE
+   default n
+
 menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if X86
select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
+   select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES)
select ANON_INODES
help
  VFIO provides a framework for secure userspace device drivers.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 50e30bc..0b035b1 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
 obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
-obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
+obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index f834b4c..949f98e 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -18,11 +18,13 @@ int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
return eeh_dev_open(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
 void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
 {
eeh_dev_release(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
 
 long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
unsigned int cmd, unsigned long arg)
@@ -85,3 +87,4 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
 
return ret;
 }
+EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 25a0fbd..224128a 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -98,6 +98,7 @@ extern int vfio_external_user_iommu_id(struct vfio_group 
*group);
 extern long vfio_external_check_extension(struct vfio_group *group,
  unsigned long arg);
 
+struct pci_dev;
 #ifdef CONFIG_EEH
 extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
-- 
1.8.3.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

[PATCH v4 5/5] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan

From: Alexey Kardashevskiy 

The existing vfio_pci_open() fails upon error returned from
vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
support which this patch brings back.

The patch fixes the issue by dropping the return value of
vfio_spapr_pci_eeh_open().

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
v3: Drop return value of vfio_spapr_pci_eeh_open()
v4: Add warning message in eeh_dev_open() in PATCH[2/5]
---
 drivers/vfio/pci/vfio_pci.c   | 6 +-
 drivers/vfio/vfio_spapr_eeh.c | 4 ++--
 include/linux/vfio.h  | 5 ++---
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index e2ee80f..32d69c8 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
if (ret)
goto error;
 
-   ret = vfio_spapr_pci_eeh_open(vdev->pdev);
-   if (ret) {
-   vfio_pci_disable(vdev);
-   goto error;
-   }
+   vfio_spapr_pci_eeh_open(vdev->pdev);
}
 
return 0;
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 4779cac..86dfceb 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -19,9 +19,9 @@
 #define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
 
 /* We might build address mapping here for "fast" path later */
-int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return eeh_dev_open(pdev);
+   eeh_dev_open(pdev);
 }
 EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 224128a..d320411 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
vfio_group *group,
 
 struct pci_dev;
 #ifdef CONFIG_EEH
-extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
+extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
 extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
   unsigned int cmd,
   unsigned long arg);
 #else
-static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return 0;
 }
 
 static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
-- 
1.8.3.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

[PATCH v4 0/5] drivers/vfio: EEH Compile and compatibility

2014-08-06 Thread Gavin Shan

The patchset is mainly for fixing errors from building VFIO compoments
as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
to initialize for VFIO PCI devices.


Alexey Kardashevskiy (2):
  drivers/vfio: Allow EEH to be built as module
  drivers/vfio: Enable VFIO if EEH is not supported

Gavin Shan (3):
  powerpc/eeh: Export eeh_iommu_group_to_pe()
  powerpc/eeh: Add warning message in eeh_dev_open()
  drivers/vfio: Fix EEH build error

 arch/powerpc/kernel/eeh.c |  6 +-
 drivers/vfio/Kconfig  |  6 ++
 drivers/vfio/Makefile |  2 +-
 drivers/vfio/pci/vfio_pci.c   |  6 +-
 drivers/vfio/vfio_spapr_eeh.c | 17 +++--
 include/linux/vfio.h  |  6 +++---
 6 files changed, 31 insertions(+), 12 deletions(-)

-- 
1.8.3.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

[PATCH v4 4/5] drivers/vfio: Allow EEH to be built as module

2014-08-06 Thread Gavin Shan

From: Alexey Kardashevskiy 

This adds necessary declarations to the SPAPR VFIO EEH module,
otherwise multiple dynamic linker errors reported:

vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
 drivers/vfio/vfio_spapr_eeh.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 949f98e..4779cac 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -9,10 +9,15 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
 
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR  "Gavin Shan, IBM Corporation"
+#define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
+
 /* We might build address mapping here for "fast" path later */
 int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
@@ -88,3 +93,8 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
return ret;
 }
 EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
-- 
1.8.3.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 v2] kvm: x86: fix stale mmio cache bug

2014-08-06 Thread David Matlack

On Tue, Aug 5, 2014 at 8:26 PM, Xiao Guangrong
 wrote:
> On 08/06/2014 06:39 AM, David Matlack wrote:
>> On Mon, Aug 4, 2014 at 8:36 PM, Xiao Guangrong
>>  wrote:
>>> The memory barrier can't help us, consider this scenario:
>>>
>>> CPU 0  CPU 1
>>> page-fault
>>> see gpa is not mapped in memslot
>>>
>>>   create new memslot containing gpa from Qemu
>>>   update the slots's generation number
>>> cache mmio info
>>>
>>> !!! later when vcpu accesses gpa again
>>> it will cause mmio-exit.
>>
>> Ah! Thanks for catching my mistake.
>>
>>> The easy way to fix this is that we update slots's generation-number
>>> after synchronize_srcu_expedited when memslot is being updated that
>>> ensures other sides can see the new generation-number only after
>>> finishing update.
>>
>> It would be possible for a vcpu to see an inconsistent kvm_memslots struct
>> (new set of slots with an old generation number). Is that not an issue?
>
> In this case, checking generation-number will fail, we will goto the slow path
> to handle mmio access - that's very rare, so i think it's ok.
>
>>
>> We could just use the generation number that is stored in the
>> spte. The only downside (that I can see) is that handle_abnormal_pfn()
>> calls vcpu_cache_mmio_info() but does not have access to the spte.
>> So presumably we'd have to do a page table walk.
>
> The issue is not only in vcpu_cache_mmio_info but also in
> mark_mmio_spte() where we may cache new generation-number and old memslots
> info.

This is now a separate bug from the one I originally reported :). For now, I
will resend a 3rd version of my patch with the fixes you suggested (the memory
barrier is useless and no need to change to mmu_sync_roots).
--
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: pci passthrough error about insufficient iommu width

2014-08-06 Thread Nishank Trivedi


On 8/6/14, 2:49 PM, William Tu wrote:


Try vfio-pci instead of pci-assign



Thanks Alex, William. Using vfio worked.
So does that mean pci-assign is being deprecated?


--
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: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table

2014-08-06 Thread Paolo Bonzini

Il 07/08/2014 03:31, Zhang, Yang Z ha scritto:
> Let me give an example to see whether my concern is a real problem: 
> Guest allocates a vector and set it in IOAPIC entry to deliver
> interrupt. Later it masks the IOAPIC entry(means stop the
> corresponding device) and assign this vector to a MSI device. With
> this patch, even the vector is not used by IOAPIC, but it still set
> eoi exit bitmap unconditionally. The subsequent EOIs to MSI device
> will force vmexit. Could this happen?

Yes, I guess it could.  I'm not sure whether it could on Linux or Windows.

> I think the right fixing is to check the ISR plus TMR to construct
> the eoi exit bitmap.

Do you care enough to propose a patch? :)

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

RE: [PATCH] KVM: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table

2014-08-06 Thread Zhang, Yang Z

Paolo Bonzini wrote on 2014-08-07:
> Il 07/08/2014 03:31, Zhang, Yang Z ha scritto:
>> Let me give an example to see whether my concern is a real problem:
>> Guest allocates a vector and set it in IOAPIC entry to deliver
>> interrupt. Later it masks the IOAPIC entry(means stop the
>> corresponding device) and assign this vector to a MSI device. With
>> this patch, even the vector is not used by IOAPIC, but it still set
>> eoi exit bitmap unconditionally. The subsequent EOIs to MSI device
>> will force vmexit. Could this happen?
> 
> Yes, I guess it could.  I'm not sure whether it could on Linux or Windows.
> 
>> I think the right fixing is to check the ISR plus TMR to construct
>> the eoi exit bitmap.
> 
> Do you care enough to propose a patch? :)
> 

Sure. I will do it.

> Paolo


Best regards,
Yang

--
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] KVM: nVMX: nested TPR shadow/threshold emulation

2014-08-06 Thread Wanpeng Li

Hi Paolo,
On Wed, Aug 06, 2014 at 06:38:06AM +, Zhang, Yang Z wrote:
[...]
 +
 +  if (exec_control & CPU_BASED_TPR_SHADOW) {
 +  if (vmx->nested.virtual_apic_page)
 +  nested_release_page(vmx->nested.virtual_apic_page);
 +  vmx->nested.virtual_apic_page =
 + nested_get_page(vcpu, vmcs12->virtual_apic_page_addr);
 +  if (!vmx->nested.virtual_apic_page)
 +  exec_control &=
 +  ~CPU_BASED_TPR_SHADOW;
 +  else
 +  vmcs_write64(VIRTUAL_APIC_PAGE_ADDR,
 +  page_to_phys(vmx->nested.virtual_apic_page));
 +
 +  if (!(exec_control & CPU_BASED_TPR_SHADOW) &&
 +  !((exec_control & CPU_BASED_CR8_LOAD_EXITING) &&
 +  (exec_control & CPU_BASED_CR8_STORE_EXITING)))
 +  nested_vmx_failValid(vcpu,
 VMXERR_ENTRY_INVALID_CONTROL_FIELD);
>>> 
>>> I think this is not correct. The vmx->nested.virtual_apic_page may not
>>> valid due to two reasons: 1. The virtual_apic_page_addr is not a valid
>>> gfn. In this case, the vmx failure
>> must be injected to L1 unconditionally regardless of the setting of
>> CR8 load/store exiting.
>> 
>> You're right that accesses to the APIC-access page may also end up
>> writing to the virtual-APIC page.  Hence, if the "virtualize APIC
>> accesses" setting is 1 in the secondary exec controls, you also have to fail 
>> the vmentry.
>> 
>> Doing it unconditionally is not correct, but it is the simplest thing
>
>Why not correct?

What's your opinion?

>
>> to do and it would be okay with a comment, I think.
>> 
>>> 2. The virtual_apic_page is swapped by L0. In this case, we should
>>> not inject
>> failure to L1.
>> 
>> This cannot happen, nested_get_page ends up calling hva_to_pfn with
>> atomic==false, so the page would be swapped in and pinned.
>> 
 +
 +  vmcs_write32(TPR_THRESHOLD, vmcs12->tpr_threshold);
 +  }
>>> 
>>> Miss else here:
>>> If L2 owns the APIC and doesn't use TPR_SHADOW, we need to setup the
>>> vmcs02 based on vmcs01. For example, if vmcs01 is using TPR_SHADOW,
>>> then
>>> vmcs02 must set it. Also, we need to use vmcs01's virtual_apic_page
>>> and TPR_THRESHOLD for vmcs02.
>> 
>> What do you mean by "owns the APIC"?
>
>Means if L2 touch L1's APIC directly, for example, if L2 not using TPR_SHADOW, 
>then move to/from CR8 will touch L1's TPR directly. And in this case, L0 
>should aware of L1's TRP change.
>

Ditto.

Regards,
Wanpeng Li 

>> 
>> Paolo
>
>
>Best regards,
>Yang
>
--
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

49 matches

Mail list logo