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
>>>
>>> ---
>>>
>>> I don't think irq.h is needed anym
>> 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'
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
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 Chri
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_fo
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 g
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
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 pro
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.
P
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
> Reviewed-by: Gleb Natapov
> ---
> arch/x86/kvm/svm.c | 3 ++-
> arch/x86/kvm/vmx.c | 6 +++---
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 1
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,
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?
>
> Ye
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, kvm_mmu_notif
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
> fo
> 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
> th
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, page_to_phys
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 i
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 h
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 v3.17-r
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.
Signe
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 vmx
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. Whe
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 in
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 = -E
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
>>
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 add
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_a
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
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 siz
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 cha
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
Signed-off-by: Marc Zyngier
---
include/kvm/arm
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
---
Documentati
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
---
include/kvm/arm_vgic.h | 6 +++---
virt/kvm/arm/vgic.c| 17 +++--
2 files ch
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
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 3 +--
virt/kvm/ar
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 63
Amos Kong 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()
> doesn't work b
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
file=ubuntu-14.04.1-desktop-i386.iso,me
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 cooper
>> 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
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 BU
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 pro
> On August 6, 2014 at 1:19 PM Erik Rull 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 guest, the gu
On 2014-09-11 15:25, Erik Rull wrote:
>> On August 6, 2014 at 1:19 PM Erik Rull 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
>> k
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 pag
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 vmcs02->A
> On September 11, 2014 at 3:32 PM Jan Kiszka wrote:
>
>
> On 2014-09-11 15:25, Erik Rull wrote:
> >> On August 6, 2014 at 1:19 PM Erik Rull wrote:
> >>
> >>
> >> Hi all,
> >>
> >> I did already several tests and I'm not completely sure what's going wrong,
> >> but
> >> here my scenario:
> >>
> >
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
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 notifie
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))
> > write(
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_
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".
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 tar
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.
> >>
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 coopera
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_RESE
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
> >> eve
Paolo Bonzini 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 ")?
Sure, no problem. I've built the trace-cmd tool against udis86 (I hope) and
have put the resulting trac
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,
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/UNFORW
On Thu, Sep 11, 2014 at 10:44 AM, 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 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_f
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
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
>> wrote:
>> > On Thu, Jun 05, 2014 at 07:03:23PM +0200, Antonios Motakis wrote:
>> >> Adds support to mask interrupts
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 attribut
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 wro
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-
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 h
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 __KV
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 any
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 a
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 uns
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:4
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 s
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 struc
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
Did anything dramticall
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 incr
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 t
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
> Signed-off-by: Joel Schopp
> ---
> virt/kvm/arm/vgic.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/vir
Amit Shah 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 completing
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 L2->L0
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 othe
>>> > > 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
This patch replace the set_bit method by kvm_make_request
to makes it more readable and consistency.
Signed-off-by: Guo Hui Liu
---
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
index 916e895..5fed2d
在 08/01/2014 11:03 PM, Dr. David Alan Gilbert 写道:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
implement colo checkpoint protocol.
Checkpoint synchronzing points.
Primary Secondary
NEW @
Suspend
在 08/01/2014 11:10 PM, Dr. David Alan Gilbert 写道:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
The ram cache was initially the same as PVM's memory. At
checkpoint, we cache the dirty memory of PVM into ram cache
(so that ram cache always the same as PVM's memory at every
checkpoint), flush c
在 08/01/2014 10:43 PM, Dr. David Alan Gilbert 写道:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
migrate colo info to migration target to tell the target colo is
enabled.
If I understand this correctly this means that you send a 'colo info' device
information for migrations that don't have C
98 matches
Mail list logo
