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 completio
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().
> >
>
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_rese
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 sup
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 Kar
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/
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
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
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 inter
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-
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 t
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 re
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: Pranav
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
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 s
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 ba
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 ra
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 h
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
--
T
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
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:
> h
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 v
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-s
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 sa
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 mech
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 w
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 Passwo
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
---
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.
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 capabili
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_io
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
>> havi
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 f
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_op
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_p
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
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/e
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/
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 Kar
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 su
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_rese
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
>>
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 ma
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
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
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
49 matches
Mail list logo
