On 07/03/2014 11:42 AM, Hongyang Yang wrote:
I wonder if there is anyway to coordinate this between COLO, Michael
Hines microcheckpointing and the two separate reverse-execution
projects that also need to do some similar things.
Are there any standard APIs for the heartbeet thing we can
Hi Michael,
Thank you for paying attention on this.
On 07/08/2014 02:06 PM, Michael R. Hines wrote:
On 07/03/2014 11:42 AM, Hongyang Yang wrote:
I wonder if there is anyway to coordinate this between COLO, Michael
Hines microcheckpointing and the two separate reverse-execution
projects
These two registers are already saved in the block above. Aside from
being unnecessary, by the time we get down to the second save location
r8 no longer contains MMCR2, so we are clobbering the saved value with
PMC5.
MMCR2 primarily consists of counter freeze bits. So restoring the value
of PMC5
Tang,
I am sorry if I caused any confusion.
Following Gleb response, there is no apparent need for dealing with the
scenario I mentioned (relocating the APIC base), so you don't need to do
any changes to your patch, and I will post another patch later to warn
if the guest relocates its APIC
On 2014-07-08 07:50, Paolo Bonzini wrote:
Il 08/07/2014 06:30, Bandan Das ha scritto:
With commit b6b8a1451fc40412c57d1 that introduced
vmx_check_nested_events, checks for injectable interrupts happen
at different points in time for L1 and L2 that could potentially
cause a race. The
Il 08/07/2014 08:56, Jan Kiszka ha scritto:
I don't think arch.nmi_pending can flip asynchronously, only in the
context of the VCPU thread - in contrast to pending IRQ states.
Right, only nmi_queued is changed from other threads. /me should really
look at the code instead of going from
On Tue, Jul 08, 2014 at 10:00:35AM +0200, Paolo Bonzini wrote:
Il 08/07/2014 08:56, Jan Kiszka ha scritto:
I don't think arch.nmi_pending can flip asynchronously, only in the
context of the VCPU thread - in contrast to pending IRQ states.
Right, only nmi_queued is changed from other threads. /me
On Mon, Jul 07, 2014 at 06:34:25AM -0700, kan.li...@intel.com wrote:
+ /*
+ * Access LBR MSR may cause #GP under certain circumstances.
+ * E.g. KVM doesn't support LBR MSR
+ * Check all LBT MSR here.
+ * Disable LBR access if any LBR MSRs can not be accessed.
+
On Mon, Jul 07, 2014 at 06:34:25AM -0700, kan.li...@intel.com wrote:
@@ -555,7 +577,11 @@ static inline void __x86_pmu_enable_event(struct
hw_perf_event *hwc,
{
u64 disable_mask = __this_cpu_read(cpu_hw_events.perf_ctr_virt_mask);
- if (hwc-extra_reg.reg)
+ if
Ping,
On Fri, Jul 04, 2014 at 02:52:38PM +0800, Wanpeng Li wrote:
This bug can be trigger by L1 goes down directly w/ enable_shadow_vmcs.
[ 6413.158950] kvm: vmptrld (null)/7800 failed
[ 6413.158954] vmwrite error: reg 401e value 4 (err 1)
[ 6413.158957] CPU: 0 PID: 4840 Comm:
Hi Wanpeng,
On 07/07/2014 06:35 PM, Wanpeng Li wrote:
On Wed, Jul 02, 2014 at 05:00:37PM +0800, Tang Chen wrote:
apic access page is pinned in memory, and as a result it cannot be
migrated/hot-removed.
Actually it doesn't need to be pinned in memory.
This patch introduces a new vcpu request:
From: Mihai Caraman mihai.cara...@freescale.com
The patch 08c9a188d0d0fc0f0c5e17d89a06bb59c493110f
kvm: powerpc: use caching attributes as per linux pte
do not handle properly the error case, letting mmu_lock locked. The lock
will further generate a RCU stall from kvmppc_e500_emul_tlbwe()
From: Anton Blanchard an...@samba.org
Both kvmppc_hv_entry_trampoline and kvmppc_entry_trampoline are
assembly functions that are exported to modules and also require
a valid r2.
As such we need to use _GLOBAL_TOC so we provide a global entry
point that establishes the TOC (r2).
Signed-off-by:
Commit ac5a8ee8 started using _GLOBAL_TOC on ppc32 code. Unfortunately it's only
defined for 64bit targets though. Define it for ppc32 as well, fixing the build
breakage that commit introduced.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/ppc_asm.h | 2 ++
1 file
We switched to ABIv2 on Little Endian systems now which gets rid of the
dotted function names. Branch to the actual functions when we see such
a system.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_interrupts.S | 4
arch/powerpc/kvm/book3s_rmhandlers.S | 4
2
In commit b59d9d26b we introduced implicit byte swaps for RTAS calls.
Unfortunately we messed up and didn't swizzle return values properly.
Also the old approach wasn't sparse compatible - we were randomly
reading __be32 values on an LE system.
Let's just do all of the swizzling explicitly with
Hi Paolo / Marcelo,
This is my current patch queue for 3.16. Please pull.
Alex
The following changes since commit 5c02c392cd2320e8d612376d6b72b6548a680923:
Merge tag 'virtio-next-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux (2014-06-11 21:10:33
-0700)
are
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
With guests supporting Multiple page size per segment (MPSS),
hpte_page_size returns the actual page size used. Add a new function to
return base page size and use that to compare against the the page size
calculated from SLB. Without this
Il 08/07/2014 12:04, Alexander Graf ha scritto:
Hi Paolo / Marcelo,
This is my current patch queue for 3.16. Please pull.
Alex
The following changes since commit 5c02c392cd2320e8d612376d6b72b6548a680923:
Merge tag 'virtio-next-for-linus' of
On 08.07.14 12:13, Paolo Bonzini wrote:
Il 08/07/2014 12:04, Alexander Graf ha scritto:
Hi Paolo / Marcelo,
This is my current patch queue for 3.16. Please pull.
Alex
The following changes since commit
5c02c392cd2320e8d612376d6b72b6548a680923:
Merge tag 'virtio-next-for-linus' of
Markus Armbruster arm...@redhat.com writes:
Please send topics.
No topics, no call today. Happy hacking!
[...]
--
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
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
starting to kick around).
This allow us to allocate memory for the exact number of CPUs we
have. As nobody configures the number of interrupts just yet,
use a fallback
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.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
include/kvm/arm_vgic.h | 3 +--
virt/kvm/arm/vgic.c
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
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
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
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
In order to make the number of interrupt 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
The GIC CPU interface is always 4k aligned. If the host is using
64k pages, it is critical to place the guest's GICC interface at the
same relative alignment as the host's GICV. Failure to do so results
in an impossibility for the guest to deal with interrupts.
Add a
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.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
include/kvm/arm_vgic.h |
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_notifier_invalidate_page() will invalidate the
ept identity pagetable and apic access page in kvm are pinned in memory.
As a result, they cannot be migrated/hot-removed.
But actually they don't need to be pinned in memory.
[For ept identity page]
Just do not pin it. When it is migrated, guest will be able to find the
new page in the next ept
ept identity page is pinned in memory. As a result, it cannot be
migrated/hot-removed.
Actually, this page is not necessary to be pinned. When it is migrated,
mmu_notifier_invalidate_page() in try_to_unmap_one() will invalidate the ept
entry so that the guest won't be able to access the page.
gfn_to_page() will finally call hva_to_pfn() to get the pfn, and pin the page
in memory by calling GUP functions. This function unpins the page.
Will be used by the followed patches.
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c |
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 identity page is initialized
Actually,
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
---
arch/x86/kvm/svm.c | 3 ++-
arch/x86/kvm/vmx.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git
On Mon, Jul 07, 2014 at 06:34:25AM -0700, kan.li...@intel.com wrote:
+ /*
+* Access LBR MSR may cause #GP under certain circumstances.
+* E.g. KVM doesn't support LBR MSR
+* Check all LBT MSR here.
+* Disable LBR access if any LBR MSRs can not be accessed.
+
-Original Message-
From: Peter Zijlstra [mailto:pet...@infradead.org]
Sent: Tuesday, July 08, 2014 5:29 AM
To: Liang, Kan
Cc: a...@firstfloor.org; linux-ker...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH V3 1/2] perf ignore LBR and offcore_rsp.
On Mon, Jul 07, 2014
On Tue, Jul 08, 2014 at 02:22:25PM +, Liang, Kan wrote:
This too is wrong in many ways; there's more than 2 extra_msrs on many
systems.
Right, there are four extra reg types on Intel systems. Since my
previous test only triggers the crash with RSP_0 and RSP_1, so I only
handle these
Any decision on this ? If we're going to revert monitor/mwait as nop,
it's hopefully not too late to avoid having it show up in an official
(3.16 ?) kernel release...
Thanks,
--Gabriel
On Thu, Jun 19, 2014 at 09:59:35AM -0400, Gabriel L. Somlo wrote:
This reverts commit
Il 08/07/2014 17:15, Gabriel L. Somlo ha scritto:
Any decision on this ? If we're going to revert monitor/mwait as nop,
it's hopefully not too late to avoid having it show up in an official
(3.16 ?) kernel release...
I don't really see a reason to revert it.
Paolo
--
To unsubscribe from this
test_vmptrld was actually invoking vmclear. make_vmcs_current is
the wrapper for vmptrld, not vmcs_clear!
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/vmx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/x86/vmx.c b/x86/vmx.c
index cc2598f..ef9caca 100644
This was broken because it needed the 32-bit and 16-bit selectors.
Add them back to cstart64.S, and change svm.c to use symbolic names.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
lib/x86/desc.h | 15 +--
x86/cstart64.S | 10 +-
x86/svm.c | 15 +--
3
I still have the following failures:
- npt_rsvd in the nested SVM test
- intercepted interrupt + hlt in the nested VMX test
Paolo Bonzini (2):
svm: fix mode switch testcase
vmx: actually test vmptrld, not vmclear
lib/x86/desc.h | 15 +--
x86/cstart64.S | 10 +-
Paolo Bonzini pbonz...@redhat.com writes:
test_vmptrld was actually invoking vmclear. make_vmcs_current is
the wrapper for vmptrld, not vmcs_clear!
Oops, this was my fault, sorry!!
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/vmx.c | 6 +++---
1 file changed, 3
Hello!
Running a CentOS 6.5 KVM host with a CentOS 6.5 QEMU guest with OpenNMS and
having a non-responsive network from the guest. The host is using:
2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 x86_64
x86_64 GNU/Linux
qemu-kvm-0.12.1.2-2.415.el6_5.10.x86_64
On Thu, Jul 03, 2014 at 06:45:45PM +0100, Marc Zyngier wrote:
Hi Jason,
On 30/06/14 16:50, Marc Zyngier wrote:
Hi Jason,
On 30/06/14 16:43, Jason Cooper wrote:
Marc,
On Mon, Jun 30, 2014 at 04:01:29PM +0100, Marc Zyngier wrote:
I now have received enough Reviewed-by from people
Marc,
On Mon, Jun 30, 2014 at 04:01:30PM +0100, Marc Zyngier wrote:
A few GICv2 low-level function are actually very useful to GICv3,
and it makes some sense to share them across the two drivers.
They end-up in their own file, with an additional parameter used
to ensure an optional
On Mon, Jun 02, 2014 at 07:42:58PM -0500, Kim Phillips wrote:
Needed by platform device drivers, such as the upcoming
vfio-platform driver, in order to bypass the existing OF, ACPI,
id_table and name string matches, and successfully be able to be
bound to any device, like so:
echo
Michael S. Tsirkin m...@redhat.com writes:
Below should be useful for some experiments Jason is doing.
I thought I'd send it out for early review/feedback.
Compiled-only at this point.
It's not a terrible idea, but it will come down to how effective it is
in practice.
I'm tempted to make it
From: Kan Liang kan.li...@intel.com
x86, perf: Protect LBR and extra_regs against KVM lying
With -cpu host, KVM reports LBR and extra_regs support, if the host has support.
When the guest perf driver tries to access LBR or extra_regs MSR,
it #GPs all MSR accesses,since KVM doesn't handle LBR and
From: Kan Liang kan.li...@intel.com
With -cpu host KVM reports LBR and extra_regs support, so the perf driver may
accesses the LBR and extra_regs MSRs.
However, there is no LBR and extra_regs virtualization support yet. This could
causes guest to crash.
As a workaround, KVM just simply ignore
On 07/08/2014 09:01 PM, Tang Chen wrote:
ept identity pagetable and apic access page in kvm are pinned in memory.
As a result, they cannot be migrated/hot-removed.
But actually they don't need to be pinned in memory.
[For ept identity page]
Just do not pin it. When it is migrated, guest will
On 07/08/2014 09:01 PM, Tang Chen wrote:
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 identity
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 identity page is initialized
Actually,
These two registers are already saved in the block above. Aside from
being unnecessary, by the time we get down to the second save location
r8 no longer contains MMCR2, so we are clobbering the saved value with
PMC5.
MMCR2 primarily consists of counter freeze bits. So restoring the value
of PMC5
Commit ac5a8ee8 started using _GLOBAL_TOC on ppc32 code. Unfortunately it's only
defined for 64bit targets though. Define it for ppc32 as well, fixing the build
breakage that commit introduced.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/ppc_asm.h | 2 ++
1 file
We switched to ABIv2 on Little Endian systems now which gets rid of the
dotted function names. Branch to the actual functions when we see such
a system.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_interrupts.S | 4
arch/powerpc/kvm/book3s_rmhandlers.S | 4
2
From: Anton Blanchard an...@samba.org
Both kvmppc_hv_entry_trampoline and kvmppc_entry_trampoline are
assembly functions that are exported to modules and also require
a valid r2.
As such we need to use _GLOBAL_TOC so we provide a global entry
point that establishes the TOC (r2).
Signed-off-by:
From: Mihai Caraman mihai.cara...@freescale.com
The patch 08c9a188d0d0fc0f0c5e17d89a06bb59c493110f
kvm: powerpc: use caching attributes as per linux pte
do not handle properly the error case, letting mmu_lock locked. The lock
will further generate a RCU stall from kvmppc_e500_emul_tlbwe()
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
With guests supporting Multiple page size per segment (MPSS),
hpte_page_size returns the actual page size used. Add a new function to
return base page size and use that to compare against the the page size
calculated from SLB. Without this
In commit b59d9d26b we introduced implicit byte swaps for RTAS calls.
Unfortunately we messed up and didn't swizzle return values properly.
Also the old approach wasn't sparse compatible - we were randomly
reading __be32 values on an LE system.
Let's just do all of the swizzling explicitly with
Hi Paolo / Marcelo,
This is my current patch queue for 3.16. Please pull.
Alex
The following changes since commit 5c02c392cd2320e8d612376d6b72b6548a680923:
Merge tag 'virtio-next-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux (2014-06-11 21:10:33
-0700)
are
Il 08/07/2014 12:04, Alexander Graf ha scritto:
Hi Paolo / Marcelo,
This is my current patch queue for 3.16. Please pull.
Alex
The following changes since commit 5c02c392cd2320e8d612376d6b72b6548a680923:
Merge tag 'virtio-next-for-linus' of
On 08.07.14 12:13, Paolo Bonzini wrote:
Il 08/07/2014 12:04, Alexander Graf ha scritto:
Hi Paolo / Marcelo,
This is my current patch queue for 3.16. Please pull.
Alex
The following changes since commit
5c02c392cd2320e8d612376d6b72b6548a680923:
Merge tag 'virtio-next-for-linus' of
66 matches
Mail list logo
