On 2014-09-11 07:06, Zhang Haoyu wrote:
Currently, we call ioapic_service() immediately when we find the irq is still
active during eoi broadcast. But for real hardware, there's some dealy between
the EOI writing and irq delivery (system bus latency?). So we need to emulate
this behavior.
On 2014-09-10 18:53, Chris J Arges wrote:
cppcheck found the following error:
[ioapic.c:114]: (error) Array index -1 is out of bounds.
If CONFIG_X86 is not defined, RTC_GSI == -1U which means that an out of bounds
That issue is limited to the dead ia64 architecture, no other builds
ioapic.c
On (Wed) 10 Sep 2014 [17:07:06], Amos Kong wrote:
It doesn't save too much cpu time as expected, just a cleanup.
Frankly I won't bother with this. It doesn't completely remove all
copying from the mutex, so it's not worthwhile.
Signed-off-by: Amos Kong ak...@redhat.com
---
On (Wed) 10 Sep 2014 [17:07:07], Amos Kong wrote:
When I check hwrng attributes in sysfs, cat process always gets
stuck if guest has only 1 vcpu and uses a slow rng backend.
Currently we check if there is any tasks waiting to be run on
current cpu in rng_dev_read() by need_resched(). But
On (Sun) 07 Sep 2014 [17:46:26], Zhang Haoyu wrote:
Hi, Paolo, Amit,
any ideas?
I'll check this, thanks for testing with Linux guests.
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
Il 11/09/2014 05:09, Christoffer Dall ha scritto:
On Mon, Sep 01, 2014 at 12:11:19PM +0200, Paolo Bonzini wrote:
Il 01/09/2014 10:36, Eric Auger ha scritto:
No more needed. irq.h would be void on ARM.
Signed-off-by: Eric Auger eric.au...@linaro.org
---
I don't think irq.h is needed
Currently, we call ioapic_service() immediately when we find the irq is still
active during eoi broadcast. But for real hardware, there's some dealy
between
the EOI writing and irq delivery (system bus latency?). So we need to emulate
this behavior. Otherwise, for a guest who haven't
On 09/11/2014 05:09 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 10:53:04AM +0200, Eric Auger wrote:
This patch enables irqfd on ARM.
irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
a kvm_irqfd
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:43PM +0200, Eric Auger wrote:
In case the IRQ is forwarded, the VFIO platform IRQ handler does not
need to disable the IRQ anymore. In that mode, when the handler completes
add a comma after completes
Hi
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:44PM +0200, Eric Auger wrote:
add new device group commands:
- KVM_DEV_VFIO_DEVICE_FORWARD_IRQ and
KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ
which enable to turn forwarded IRQ mode on/off.
the kvm_arch_forwarded_irq
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:45PM +0200, Eric Auger wrote:
New functions are added to be called from ARM KVM-VFIO device.
This commit message seems somewhat random. This patch doesn't deal with
anything ARM specific, it introduces some
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:46PM +0200, Eric Auger wrote:
add functions that implement the gateway to the extended
Capital letter when beginning a new sentence. Also the reference to
'the extended VFIO API' feels a bit weird. Can't you make
Currently, we call ioapic_service() immediately when we find the irq is still
active during eoi broadcast. But for real hardware, there's some dealy between
the EOI writing and irq delivery (system bus latency?). So we need to emulate
this behavior. Otherwise, for a guest who haven't register a
Il 11/09/2014 08:01, Jan Kiszka ha scritto:
That issue is limited to the dead ia64 architecture, no other builds
ioapic.c (besides x86, of course). Maybe finally remove KVM support for
that arch instead of bloating otherwise correct code?
Yes, we should. I've just been too busy to do it.
Il 11/09/2014 07:38, Tang Chen ha scritto:
We have APIC_DEFAULT_PHYS_BASE defined as 0xfee0, which is also the
address of
apic access page. So use this macro.
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Gleb Natapov g...@kernel.org
---
arch/x86/kvm/svm.c | 3 ++-
Il 10/09/2014 15:53, Christian Borntraeger ha scritto:
Paolo,
please have a look at the next bunch of s390 patches and consider to apply:
The following changes since commit fd2752352bbc98850d83b5448a288d8991590317:
KVM: x86: use guest maxphyaddr to check MTRR values (2014-08-29
Il 11/09/2014 07:38, Tang Chen ha scritto:
kvm_arch-ept_identity_pagetable holds the ept identity pagetable page. But
it is never used to refer to the page at all.
In vcpu initialization, it indicates two things:
1. indicates if ept page is allocated
2. indicates if a memory slot for
Il 11/09/2014 07:38, Tang Chen ha scritto:
In init_rmode_identity_map(), there two variables indicating the return
value, r and ret, and it return 0 on error, 1 on success. The function
is only called by vmx_create_vcpu(), and r is redundant.
This patch removes the redundant variable r, and
On 2014-09-11 11:08, Paolo Bonzini wrote:
Il 11/09/2014 08:01, Jan Kiszka ha scritto:
That issue is limited to the dead ia64 architecture, no other builds
ioapic.c (besides x86, of course). Maybe finally remove KVM support for
that arch instead of bloating otherwise correct code?
Yes, we
Il 11/09/2014 07:38, Tang Chen ha scritto:
apic access page is pinned in memory. As a result, it cannot be
migrated/hot-removed.
Actually, it is not necessary to be pinned.
The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer. When
the page is migrated,
Il 11/09/2014 07:38, Tang Chen ha scritto:
This patch only handle L1 and L2 vm share one apic access page situation.
When L1 vm is running, if the shared apic access page is migrated,
mmu_notifier will
request all vcpus to exit to L0, and reload apic access page physical address
for
all
Subject: [Qemu-devel] [PATCH] kvm: ioapic: conditionally delay irq delivery
duringeoi broadcast
Currently, we call ioapic_service() immediately when we find the irq is still
active during eoi broadcast. But for real hardware, there's some dealy between
the EOI writing and irq delivery
Il 11/09/2014 07:38, Tang Chen ha scritto:
Just like we removed kvm_arch-apic_access_page, nested_vmx-apic_access_page
becomes useless for the same reason. This patch removes
nested_vmx-apic_access_page,
and use gfn_to_page() to pin it in memory when we need it, and unpin it after
then.
Il 11/09/2014 07:38, Tang Chen ha scritto:
+ if (vm_need_virtualize_apic_accesses(vmx-vcpu.kvm)) {
+ struct page *page = gfn_to_page(vmx-vcpu.kvm,
+ APIC_DEFAULT_PHYS_BASE PAGE_SHIFT);
+ vmcs_write64(APIC_ACCESS_ADDR,
Il 11/09/2014 11:19, Jan Kiszka ha scritto:
On 2014-09-11 11:08, Paolo Bonzini wrote:
Il 11/09/2014 08:01, Jan Kiszka ha scritto:
That issue is limited to the dead ia64 architecture, no other builds
ioapic.c (besides x86, of course). Maybe finally remove KVM support for
that arch instead of
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
This is a new control channel which enables KVM to cooperate with
viable VFIO devices.
The kvm-vfio device now holds a list
On 09/11/2014 05:33 PM, Paolo Bonzini wrote:
This patch is not against the latest KVM tree. The call to
nested_get_page is now in nested_get_vmcs12_pages, and you have to
handle virtual_apic_page in a similar manner.
Hi Paolo,
Thanks for the reviewing.
This patch-set is against Linux
Il 08/09/2014 15:28, Chris Webb ha scritto:
divide error: [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 743 Comm: syslogd Not tainted 3.16.2-guest #2
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
Initially the tracepoint was added only to the APIC_DM_FIXED case,
also because it reported coalesced interrupts that only made sense
for that case. However, the coalesced argument is not used anymore
and tracing other delivery modes is useful, so hoist the call out
of the switch statement.
On Thu, Sep 11, 2014 at 11:21:49AM +0200, Paolo Bonzini wrote:
Il 11/09/2014 07:38, Tang Chen ha scritto:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 63c4c3e..da6d55d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -7093,6 +7093,11 @@ static void
On 09/11/2014 05:21 PM, Paolo Bonzini wrote:
Il 11/09/2014 07:38, Tang Chen ha scritto:
apic access page is pinned in memory. As a result, it cannot be
migrated/hot-removed.
Actually, it is not necessary to be pinned.
The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer.
On 11/09/14 04:12, Christoffer Dall wrote:
On Tue, Sep 09, 2014 at 12:02:59PM +0100, Marc Zyngier wrote:
[resending, as ARM email server seems to be in some mood]
On 09/09/14 11:27, Ard Biesheuvel wrote:
The ISS encoding for an exception from a Data Abort has a WnR
bit[6] that indicates
On 09/11/2014 05:17 PM, Paolo Bonzini wrote:
..
@@ -7645,7 +7642,7 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm *kvm,
unsigned int id)
kvm-arch.ept_identity_map_addr =
VMX_EPT_IDENTITY_PAGETABLE_ADDR;
err =
On 11/09/14 08:11, Paolo Bonzini wrote:
Il 11/09/2014 05:09, Christoffer Dall ha scritto:
On Mon, Sep 01, 2014 at 12:11:19PM +0200, Paolo Bonzini wrote:
Il 01/09/2014 10:36, Eric Auger ha scritto:
No more needed. irq.h would be void on ARM.
Signed-off-by: Eric Auger eric.au...@linaro.org
Folks,
we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq
rework that happened between 3.15 and 3.16, but it can be something completely
different.
[ 65.992022] Unable to handle kernel pointer dereference in virtual kernel
address space
[ 65.992187] failing
Il 11/09/2014 12:20, tangchen ha scritto:
+vmcs_write64(APIC_ACCESS_ADDR, hpa);
This has to be guarded by if (!is_guest_mode(vcpu)).
Since we cannot get vcpu through kvm, I'd like to move this check to
vcpu_reload_apic_access_page() when
kvm_x86_ops-set_apic_access_page_addr()
is
Il 11/09/2014 12:12, Gleb Natapov ha scritto:
On Thu, Sep 11, 2014 at 11:21:49AM +0200, Paolo Bonzini wrote:
Il 11/09/2014 07:38, Tang Chen ha scritto:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 63c4c3e..da6d55d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@
So far, all the VGIC data structures are statically defined by the
*maximum* number of vcpus and interrupts it supports. It means that
we always have to oversize it to cater for the worse case.
Start by changing the data structures to be dynamically sizeable,
and allocate them at runtime.
The
So far, the VGIC data structures have been statically sized, meaning
that we always have to support more interrupts than we actually want,
and more CPU interfaces than we should. This is a waste of resource,
and is the kind of things that should be tuneable.
This series addresses that issue by
Having a dynamic number of supported interrupts means that we
cannot relly on VGIC_NR_SHARED_IRQS being fixed anymore.
Instead, make it take the distributor structure as a parameter,
so it can return the right value.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Marc
As it stands, nothing prevents userspace from injecting an interrupt
before the guest's GIC is actually initialized.
This goes unnoticed so far (as everything is pretty much statically
allocated), but ends up exploding in a spectacular way once we switch
to a more dynamic allocation (the GIC data
Now that we can (almost) dynamically size the number of interrupts,
we're facing an interesting issue:
We have to evaluate at runtime whether or not an access hits a valid
register, based on the sizing of this particular instance of the
distributor. Furthermore, the GIC spec says that accessing a
In order to make the number of interrupts configurable, use the new
fancy device management API to add KVM_DEV_ARM_VGIC_GRP_NR_IRQS as
a VGIC configurable attribute.
Userspace can now specify the exact size of the GIC (by increments
of 32 interrupts).
Signed-off-by: Marc Zyngier
Nuke VGIC_NR_IRQS entierly, now that the distributor instance
contains the number of IRQ allocated to this GIC.
Also add VGIC_NR_IRQS_LEGACY to preserve the current API.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
include/kvm/arm_vgic.h | 6 +++---
virt/kvm/arm/vgic.c| 17
It is now quite easy to delay the allocation of the vgic tables
until we actually require it to be up and running (when the first
vcpu is kicking around, or someones tries to access the GIC registers).
This allow us to allocate memory for the exact number of CPUs we
have. As nobody configures the
We now have the information about the number of CPU interfaces in
the distributor itself. Let's get rid of VGIC_MAX_CPUS, and just
rely on KVM_MAX_VCPUS where we don't have the choice. Yet.
Reviewed-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
On Thu, Sep 11, 2014 at 12:47:16PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 12:12, Gleb Natapov ha scritto:
On Thu, Sep 11, 2014 at 11:21:49AM +0200, Paolo Bonzini wrote:
Il 11/09/2014 07:38, Tang Chen ha scritto:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
Amos Kong ak...@redhat.com writes:
When I check hwrng attributes in sysfs, cat process always gets
stuck if guest has only 1 vcpu and uses a slow rng backend.
Currently we check if there is any tasks waiting to be run on
current cpu in rng_dev_read() by need_resched(). But need_resched()
Hi list,
after hours for searching in google-world, i didnt find any appropriate
for this problem:
I want to boot a live-cd (i.e. ubuntu 14.04.1-desktop) in qemu, which
starts with an graphical interface, done i.e. by
qemu-system-x86_64 -m 3G -smp 2 -drive
On 09/11/2014 07:05 AM, Alex Williamson wrote:
On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
This is a new control channel which enables KVM to cooperate with
Subject: [Qemu-devel] [PATCH] kvm: ioapic: conditionally delay irq delivery
duringeoi broadcast
Currently, we call ioapic_service() immediately when we find the irq is still
active during eoi broadcast. But for real hardware, there's some dealy
between
the EOI writing and irq delivery
Il 11/09/2014 13:30, Gleb Natapov ha scritto:
+ vmcs_write64(APIC_ACCESS_ADDR, page_to_phys(page));
+ /*
+ * Do not pin apic access page in memory so that memory
+ * hotplug process is able to migrate it.
+
This patch enables running intensive I/O workloads, e.g. netperf, in a guest
deployed on a RT host. No change for !RT kernels.
The openpic spinlock becomes a sleeping mutex on a RT system. This no longer
guarantees that EPR is atomic with exception delivery. The guest VCPU thread
fails due to a
Currently, we call ioapic_service() immediately when we find the irq is still
active during eoi broadcast. But for real hardware, there's some dealy between
the EOI writing and irq delivery (system bus latency?). So we need to emulate
this behavior. Otherwise, for a guest who haven't register a
On August 6, 2014 at 1:19 PM Erik Rull erik.r...@rdsoftware.de wrote:
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
On 2014-09-11 15:25, Erik Rull wrote:
On August 6, 2014 at 1:19 PM Erik Rull erik.r...@rdsoftware.de wrote:
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
On Thu, Sep 11, 2014 at 03:05:05PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 13:30, Gleb Natapov ha scritto:
+vmcs_write64(APIC_ACCESS_ADDR,
page_to_phys(page));
+/*
+ * Do not pin apic access page in memory so
Il 11/09/2014 15:59, Gleb Natapov ha scritto:
Suppose vmcs01-APIC_ACCESS_ADDR = 0xf000. During L2 entry
vmcs02-APIC_ACCESS_ADDR is set to 0xf000 too (by prepare_vmcs02). Now
0xf000 is migrated to 0x8000, mmu notifier is called, it forces vmexit,
but vcpu is in a guest mode so
On September 11, 2014 at 3:32 PM Jan Kiszka jan.kis...@siemens.com wrote:
On 2014-09-11 15:25, Erik Rull wrote:
On August 6, 2014 at 1:19 PM Erik Rull erik.r...@rdsoftware.de wrote:
Hi all,
I did already several tests and I'm not completely sure what's going wrong,
but
here my
Il 11/09/2014 16:21, Gleb Natapov ha scritto:
As far as I can tell the if that is needed there is:
if (!is_guest_mode() || !(vmcs12-secondary_vm_exec_control
ECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES))
write(PIC_ACCESS_ADDR)
In other words if L2 shares L1 apic access page then reload,
On Thu, Sep 11, 2014 at 04:06:58PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 15:59, Gleb Natapov ha scritto:
Suppose vmcs01-APIC_ACCESS_ADDR = 0xf000. During L2 entry
vmcs02-APIC_ACCESS_ADDR is set to 0xf000 too (by prepare_vmcs02). Now
0xf000 is migrated to 0x8000, mmu notifier is
On Thu, Sep 11, 2014 at 04:24:04PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 16:21, Gleb Natapov ha scritto:
As far as I can tell the if that is needed there is:
if (!is_guest_mode() || !(vmcs12-secondary_vm_exec_control
ECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES))
Il 11/09/2014 16:31, Gleb Natapov ha scritto:
What if the page being swapped out is L1's APIC access page? We don't
run prepare_vmcs12 in that case because it's an L2-L0-L2 entry, so we
need to do something.
We will do something on L2-L1 exit. We will call
kvm_reload_apic_access_page().
On Thu, Sep 11, 2014 at 04:37:39PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 16:31, Gleb Natapov ha scritto:
What if the page being swapped out is L1's APIC access page? We don't
run prepare_vmcs12 in that case because it's an L2-L0-L2 entry, so we
need to do something.
We will do
Hi Anup,
On 08/09/14 09:17, 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.
If KVM_ARM_PREFERRED_TARGET vm ioctl fails then we fallback to
old method of trying all known target
On Thu, 2014-09-11 at 14:04 +0200, Eric Auger wrote:
On 09/11/2014 07:05 AM, Alex Williamson wrote:
On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
This is a
On Thu, 2014-09-11 at 11:35 +0200, Eric Auger wrote:
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
This is a new control channel which enables KVM to cooperate with
Anup,
On 08/09/14 09:17, 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.
Why do you need this still if the previous
On 08/09/14 09:17, 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
On Thu, Sep 11, 2014 at 10:14:13AM +0200, Eric Auger wrote:
On 09/11/2014 05:09 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 10:53:04AM +0200, Eric Auger wrote:
This patch enables irqfd on ARM.
irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger.
Paolo Bonzini pbonz...@redhat.com wrote:
This is a hypercall that should have kicked VCPU 3 (see rcx).
Can you please apply this patch and gather a trace of the host
(using trace-cmd -e kvm qemu-kvm arguments)?
Sure, no problem. I've built the trace-cmd tool against udis86 (I hope) and
have
On Thu, Sep 11, 2014 at 10:44:02AM +0200, Eric Auger wrote:
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:43PM +0200, Eric Auger wrote:
In case the IRQ is forwarded, the VFIO platform IRQ handler does not
need to disable the IRQ anymore. In that mode, when
On Thu, Sep 11, 2014 at 10:49:08AM +0200, Eric Auger wrote:
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:44PM +0200, Eric Auger wrote:
[...]
+
+It is up to the caller of this API to make sure the IRQ is not
+outstanding when the FORWARD/UNFORWARD is
On Thu, Sep 11, 2014 at 10:44 AM, Eric Auger eric.au...@linaro.org wrote:
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:43PM +0200, Eric Auger wrote:
In case the IRQ is forwarded, the VFIO platform IRQ handler does not
need to disable the IRQ anymore. In
On Wed, Sep 10, 2014 at 11:05:49PM -0600, Alex Williamson wrote:
On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
[...]
+#ifdef __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
+int kvm_arch_set_fwd_state(struct kvm_fwd_irq
Hi Paolo,
On Tue, Sep 02, 2014 at 10:27:32AM +0100, Will Deacon wrote:
Hi all,
This is version 3 of the patches originally posted here:
v1: http://www.spinics.net/lists/kvm-arm/msg10219.html
v2: http://www.spinics.net/lists/kvm/msg105197.html
Changes since v2 include:
-
On Wed, Sep 10, 2014 at 12:13 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Tue, Sep 02, 2014 at 06:06:17PM +0200, Antonios Motakis wrote:
On Sun, Jun 8, 2014 at 12:17 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On Thu, Jun 05, 2014 at 07:03:23PM +0200, Antonios
On Thu, Sep 11, 2014 at 02:04:39PM +0200, Eric Auger wrote:
On 09/11/2014 07:05 AM, Alex Williamson wrote:
On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
This patch introduces a new KVM_DEV_VFIO_DEVICE attribute.
On Thu, Sep 11, 2014 at 09:59:24AM -0600, Alex Williamson wrote:
On Thu, 2014-09-11 at 14:04 +0200, Eric Auger wrote:
On 09/11/2014 07:05 AM, Alex Williamson wrote:
On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
On 09/11/2014 05:09 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:41PM +0200, Eric Auger wrote:
add a lock related to the rb tree manipulation. The rb tree can be
Ok, I can't hold myself back any longer.
Please begin sentences with a
capital letter. You don't do this in
On Thu, Sep 11, 2014 at 11:35:56AM +0200, Eric Auger wrote:
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
[...]
+ if (!pfwd)
+ return -ENOMEM;
+ pfwd-index = fwd_irq-index;
+ pfwd-gsi = fwd_irq-gsi;
+
An OOPS has just bricked my main machine (or so it seems---firmware
doesn't show up at all, not even with disks removed), so I'll likely
spend part of tomorrow reviving an older one which I've luckily kept.
Plus, I'll be travelling most of next week.
For this reason I might be slow answering the
On Thu, 2014-09-11 at 19:05 +0200, Christoffer Dall wrote:
On Thu, Sep 11, 2014 at 10:44:02AM +0200, Eric Auger wrote:
On 09/11/2014 05:10 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:43PM +0200, Eric Auger wrote:
In case the IRQ is forwarded, the VFIO platform IRQ handler
On Thu, 2014-09-11 at 19:10 +0200, Christoffer Dall wrote:
On Wed, Sep 10, 2014 at 11:05:49PM -0600, Alex Williamson wrote:
On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM +0200, Eric Auger wrote:
[...]
+#ifdef
On 09/11/2014 05:09 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:40PM +0200, Eric Auger wrote:
Fix multiple injection of level sensitive forwarded IRQs.
With current code, the second injection fails since the state bitmaps
are not reset (process_maintenance is not called anymore).
On Thu, 2014-09-11 at 15:25 -0400, Bogdan Purcareata wrote:
This patch enables running intensive I/O workloads, e.g. netperf, in a guest
deployed on a RT host. No change for !RT kernels.
The openpic spinlock becomes a sleeping mutex on a RT system. This no longer
guarantees that EPR is
Hi,
I am running an OpenStack infrastructure and some compute nodes are
frequently having kernel panic, as far as I see, the kernel panics are
related with KVM.
Do you guys have any recommendation about the kernel and KVM version
to be used in
an production environment?
Thanks,
Flávio
--
To
On Thu, Sep 11, 2014 at 12:14:10PM -0600, Alex Williamson wrote:
On Thu, 2014-09-11 at 19:10 +0200, Christoffer Dall wrote:
On Wed, Sep 10, 2014 at 11:05:49PM -0600, Alex Williamson wrote:
On Thu, 2014-09-11 at 05:10 +0200, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:47PM
On Thu, Sep 11, 2014 at 08:17:49PM +0200, Eric Auger wrote:
On 09/11/2014 05:09 AM, Christoffer Dall wrote:
On Mon, Sep 01, 2014 at 02:52:40PM +0200, Eric Auger wrote:
Fix multiple injection of level sensitive forwarded IRQs.
With current code, the second injection fails since the state
On Thu, Sep 11, 2014 at 12:09:09PM +0100, Marc Zyngier wrote:
So far, all the VGIC data structures are statically defined by the
*maximum* number of vcpus and interrupts it supports. It means that
we always have to oversize it to cater for the worse case.
Start by changing the data
On Thu, Sep 11, 2014 at 12:09:13PM +0100, Marc Zyngier wrote:
Nuke VGIC_NR_IRQS entierly, now that the distributor instance
contains the number of IRQ allocated to this GIC.
Also add VGIC_NR_IRQS_LEGACY to preserve the current API.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
Did
On Thu, Sep 11, 2014 at 12:09:15PM +0100, Marc Zyngier wrote:
In order to make the number of interrupts configurable, use the new
fancy device management API to add KVM_DEV_ARM_VGIC_GRP_NR_IRQS as
a VGIC configurable attribute.
Userspace can now specify the exact size of the GIC (by
On Tue, Sep 09, 2014 at 05:27:18PM +0100, Alex Bennée wrote:
In preparation for working on the ARM implementation I noticed the debug
interface was missing from the API document. I've pieced together the
expected behaviour from the code and commit messages written it up as
best I can.
On Wed, Sep 10, 2014 at 11:34:53AM +0200, Paolo Bonzini wrote:
Il 09/09/2014 18:27, Alex Bennée ha scritto:
Hi,
I'm preparing to add ARM KVM GDB support and I went to read the API
documentation and found it surprisingly mute on the subject ;-)
The first patch documents the new
On Mon, Sep 08, 2014 at 10:21:44PM +, Joel Schopp wrote:
Add a one liner to identify the gic-400. It's gicv2 with optional MSI
extensions.
Cc: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Joel Schopp joel.sch...@amd.com
---
virt/kvm/arm/vgic.c |1 +
1 file
Amit Shah amit.s...@redhat.com writes:
On (Wed) 10 Sep 2014 [14:11:36], 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 exits the waiting by
Hi Gleb, Paolo,
On 09/11/2014 10:47 PM, Gleb Natapov wrote:
On Thu, Sep 11, 2014 at 04:37:39PM +0200, Paolo Bonzini wrote:
Il 11/09/2014 16:31, Gleb Natapov ha scritto:
What if the page being swapped out is L1's APIC access page? We don't
run prepare_vmcs12 in that case because it's an
Hi Paolo,
On 09/11/2014 10:24 PM, Paolo Bonzini wrote:
Il 11/09/2014 16:21, Gleb Natapov ha scritto:
As far as I can tell the if that is needed there is:
if (!is_guest_mode() || !(vmcs12-secondary_vm_exec_control
ECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES))
write(PIC_ACCESS_ADDR)
In other
If virtio-blk and virtio-serial share an IRQ, the guest operating
system has to check each virtqueue for activity. Maybe there is some
inefficiency doing that.
AFAIK virtio-serial registers 64 virtqueues (on 31 ports + console)
even if everything is unused.
That could be the
This patch replace the set_bit method by kvm_make_request
to makes it more readable and consistency.
Signed-off-by: Guo Hui Liu liuguo...@gmail.com
---
arch/x86/kvm/x86.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
1 - 100 of 102 matches
Mail list logo
