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 memory
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
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 (hwc-
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 Com
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
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() caller.
In case of an erro
From: Anton Blanchard
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: Anton Blanchard
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
---
arch/powerpc/include/asm/ppc_asm.h | 2 ++
1 file changed, 2 inserti
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
---
arch/powerpc/kvm/book3s_interrupts.S | 4
arch/powerpc/kvm/book3s_rmhandlers.S | 4
2 files changed
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 avail
From: "Aneesh Kumar K.V"
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 patch a hpte lookup can fail sin
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
git://git.kernel.org/pub/scm/linux/kernel/git/r
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
git
Markus Armbruster 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 http://vger.kernel.org/majordomo-info.html
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
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
---
include/kvm/arm_vgic.h | 3 +--
virt/kvm/arm/vgic.c| 6 +++---
2 files
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
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 siz
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
---
arch/arm/inc
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 KVM_DEV_ARM_VGIC_GRP_ADDR_OFFS
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
---
include/kvm/arm_vgic.h | 1 -
virt/kvm/arm/vg
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
corresponding
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. And
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
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 17 -
2
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, kvm_arch->ept_i
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
---
arch/x86/kvm/svm.c | 3 ++-
arch/x86/kvm/vmx.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arc
>
> 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 accesse
> -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
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
> hand
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 87c00572ba05aa8c9db118da
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 l
test_vmptrld was actually invoking vmclear. make_vmcs_current is
the wrapper for vmptrld, not vmcs_clear!
Signed-off-by: Paolo Bonzini
---
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
--- a/x86/vmx.c
+++
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
---
lib/x86/desc.h | 15 +--
x86/cstart64.S | 10 +-
x86/svm.c | 15 +--
3 files changed, 27 i
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 +-
x86/svm.
Paolo Bonzini 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
> ---
> x86/vmx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a
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
qemu-kvm-t
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 Rev
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 synchro
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 vfio
"Michael S. Tsirkin" 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 v1.0 only
From: Kan Liang
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 extra_regs support.
From: Kan Liang
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 the LBR and extra_reg
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 be
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 pag
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, kvm_arch->ept_i
51 matches
Mail list logo
