Dear List,
I'm a PhD student researching about virtualization. I'm currently
working on performance degradation that is caused by neighboring VMs.
I am running KVM 1.7.1 on Debian with 3.10.0-2-pve kernel (proxmox).
Hardware is a core i7 server with 8GB of RAM.
KVM runs 4 ubuntu 12.04 VMs. Each
On 08/06/2014 01:54 PM, Gavin Shan wrote:
On Tue, Aug 05, 2014 at 09:12:50PM -0600, Alex Williamson wrote:
On Wed, 2014-08-06 at 12:48 +1000, Alexey Kardashevskiy wrote:
From: Gavin Shan gws...@linux.vnet.ibm.com
The VFIO related components could be built as dynamic modules.
Unfortunately,
Paolo Bonzini wrote on 2014-08-05:
Il 05/08/2014 09:56, Zhang, Yang Z ha scritto:
Wanpeng Li wrote on 2014-08-04:
This patch fix bug
https://bugzilla.kernel.org/show_bug.cgi?id=61411
TPR shadow/threshold feature is important to speed up the Windows guest.
Besides, it is a must feature for
Debug interrupt can be either critical level or debug level.
There are separate set of save/restore registers used for different level.
Example: DSRR0/DSRR1 are used for debug level and CSRR0/CSRR1
are used for critical level debug interrupt.
Using CPU_FTR_DEBUG_LVL_EXC to decide which interrupt
This patch adds rfdi instruction emulation which is required for
guest debug hander on BOOKE-HV
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- No change
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/booke_emulate.c| 13 +
2 files changed,
This patchset adds debug register and interrupt emulation
support for guest, which enables running gdb/kgdb etc in guest.
v2-v3
- Added One-reg interface for DBSR
- removed arch-shadow_dbg_reg
- Addressed some more comments on v2 (detail in individual patch)
Bharat Bhushan (7):
KVM: PPC:
This patch changes the default behavior of MSRP_DEP, that is
guest is not allowed to change the MSR_DE, to guest can change
MSR_DE. When userspace is debugging guest then it override the
default behavior and set MSRP_DEP. This stops guest to change
MSR_DE when userspace is debugging guest.
This patch emulates debug registers and debug exception
to support guest using debug resource. This enables running
gdb/kgdb etc in guest.
On BOOKE architecture we cannot share debug resources between QEMU and
guest because:
When QEMU is using debug resources then debug exception must
be
Dbsr is not visible to userspace and we do not think any need to
expose this to userspace because:
Userspace cannot inject debug interrupt to guest (as this
does not know guest ability to handle debug interrupt), so
userspace will always clear DBSR.
Now if userspace has to always clear
Guest visible debug register and hardware visible debug registers are
same, so ther is no need to have arch-shadow_dbg_reg, instead use
arch-dbg_reg.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- New Patch ( As per comment we are now using arch-dbg_reg only)
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- New patch
arch/powerpc/include/uapi/asm/kvm.h | 1 +
arch/powerpc/kvm/booke.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
On Wed, Aug 06, 2014 at 04:33:29PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2014 01:54 PM, Gavin Shan wrote:
On Tue, Aug 05, 2014 at 09:12:50PM -0600, Alex Williamson wrote:
On Wed, 2014-08-06 at 12:48 +1000, Alexey Kardashevskiy wrote:
From: Gavin Shan gws...@linux.vnet.ibm.com
The VFIO
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
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
From: Alexey Kardashevskiy a...@ozlabs.ru
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
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
From: Alexey Kardashevskiy a...@ozlabs.ru
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().
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
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 gws...@linux.vnet.ibm.com
---
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
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
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
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
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,
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
On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
From: Alexey Kardashevskiy a...@ozlabs.ru
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
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
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
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
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
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 a...@ozlabs.ru
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
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
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
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
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
--
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
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 vincent.jar...@6wind.com:
Check on dev DPDK mailing list.
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
On Tue, Aug 5, 2014 at 4:18 PM, Joel Schopp joel.sch...@amd.com 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
Great.
Thank you Vincent.
2014-08-06 13:15 GMT-03:00 Vincent JARDIN vincent.jar...@6wind.com:
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
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
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
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
Migration support for MPX is already implemented, so we can add it to
the list of known feature names.
Signed-off-by: Eduardo Habkost ehabk...@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
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 ehabk...@redhat.com
---
This needs to be applied after:
[PATCH] target-i386: Add MPX CPU feature name
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
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)
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
alex.william...@redhat.com 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,
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
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 a...@ozlabs.ru
The existing vfio_pci_open() fails upon error returned from
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 a...@ozlabs.ru
The existing
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 gws...@linux.vnet.ibm.com
---
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
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 a...@ozlabs.ru
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh.c | 5 -
1 file changed, 4 insertions(+), 1
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
From: Alexey Kardashevskiy a...@ozlabs.ru
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().
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
From: Alexey Kardashevskiy a...@ozlabs.ru
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
On Tue, Aug 5, 2014 at 8:26 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
On 08/06/2014 06:39 AM, David Matlack wrote:
On Mon, Aug 4, 2014 at 8:36 PM, Xiao Guangrong
xiaoguangr...@linux.vnet.ibm.com wrote:
The memory barrier can't help us, consider this scenario:
CPU 0
This patchset adds debug register and interrupt emulation
support for guest, which enables running gdb/kgdb etc in guest.
v2-v3
- Added One-reg interface for DBSR
- removed arch-shadow_dbg_reg
- Addressed some more comments on v2 (detail in individual patch)
Bharat Bhushan (7):
KVM: PPC:
This patch adds rfdi instruction emulation which is required for
guest debug hander on BOOKE-HV
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- No change
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/booke_emulate.c| 13 +
2 files changed,
Debug interrupt can be either critical level or debug level.
There are separate set of save/restore registers used for different level.
Example: DSRR0/DSRR1 are used for debug level and CSRR0/CSRR1
are used for critical level debug interrupt.
Using CPU_FTR_DEBUG_LVL_EXC to decide which interrupt
Dbsr is not visible to userspace and we do not think any need to
expose this to userspace because:
Userspace cannot inject debug interrupt to guest (as this
does not know guest ability to handle debug interrupt), so
userspace will always clear DBSR.
Now if userspace has to always clear
This patch emulates debug registers and debug exception
to support guest using debug resource. This enables running
gdb/kgdb etc in guest.
On BOOKE architecture we cannot share debug resources between QEMU and
guest because:
When QEMU is using debug resources then debug exception must
be
Guest visible debug register and hardware visible debug registers are
same, so ther is no need to have arch-shadow_dbg_reg, instead use
arch-dbg_reg.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- New Patch ( As per comment we are now using arch-dbg_reg only)
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- New patch
arch/powerpc/include/uapi/asm/kvm.h | 1 +
arch/powerpc/kvm/booke.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
Though SPE/AltiVec shares interrupts numbers on BookE cores, use distinct
defines to identify these numbers. This improves code readability especially
in KVM.
Revert c58ce397 and 6b310fc5 patches that added common defines.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
SPE exception handlers are now defined for 32-bit e500mc cores even though
SPE unit is not present and CONFIG_SPE is undefined.
Restrict SPE exception handlers to e200/e500 cores adding CONFIG_SPE_POSSIBLE
and consequently guard __stup_ivors and __setup_cpu functions.
Signed-off-by: Mihai
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
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
68 matches
Mail list logo
