Hi Gleb,
Thanks for the reply. Please see below.
On 07/12/2014 04:04 PM, Gleb Natapov wrote:
On Tue, Jul 08, 2014 at 09:01:32PM +0800, Tang Chen wrote:
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
Hi Gleb,
Please see below.
On 07/12/2014 03:44 PM, Gleb Natapov wrote:
On Wed, Jul 09, 2014 at 10:08:03AM +0800, 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
This patch adds missing sync of SRR0/1 in set SREGS interface.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/kvm/booke.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index c2471ed..368b48e 100644
---
On Thu, Jul 10, 2014 at 03:59:43AM -0700, kan.li...@intel.com wrote:
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
On Thu, Jul 10, 2014 at 03:59:43AM -0700, kan.li...@intel.com wrote:
+/*
+ * Under certain circumstances, access certain MSR may cause #GP.
+ * The function tests if the input MSR can be safely accessed.
+ */
+static inline bool check_msr(unsigned long msr)
+{
+ u64 val_old, val_new,
From: Bandan Das b...@redhat.com
Core emulator functions all belong in emulator.c,
x86 should have no knowledge of emulator internals
Signed-off-by: Bandan Das b...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/include/asm/kvm_emulate.h | 1 +
arch/x86/kvm/emulate.c
From: Bandan Das b...@redhat.com
rip_relative is only set if decode_modrm runs, and if you have ModRM
you will also have a memopp. We can then access memopp unconditionally.
Note that rip_relative cannot be hoisted up to decode_modrm, or you
break mov $0, xyz(%rip).
Also, move typecast on out
When the CS base is not page-aligned, the linear address of the code could
get close to the page boundary (e.g. 0x...ffe) even if the EIP value is
not. So we need to first linearize the address, and only then compute
the number of valid bytes that can be fetched.
This happens relatively often
These are the emulator speedup patches that have survived autotest
and kvm-unit-tests. I dropped the patches for direct access to
memory operands because they caused a failure in vmx.flat.
These patches have been in kvm/queue for a while, but I've always
left them out of kvm/next because they
This simplifies the code a bit, especially the overflow checks.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/include/asm/kvm_emulate.h | 4 ++--
arch/x86/kvm/emulate.c | 34 +++---
arch/x86/kvm/trace.h | 6 +++---
3 files
We do not need a memory copying loop anymore in insn_fetch; we
can use a byte-aligned pointer to access instruction fields directly
from the fetch_cache. This eliminates 50-150 cycles (corresponding to
a 5-10% improvement in performance) from each instruction.
Signed-off-by: Paolo Bonzini
Emulator accesses are always done a page at a time, either by the emulator
itself (for fetches) or because we need to query the MMU for address
translations. Speed up these accesses by using kvm_read_guest_page
and, in the case of fetches, by inlining kvm_read_guest_virt_helper and
dropping the
From: Bandan Das b...@redhat.com
The same information can be gleaned from ctxt-d and avoids having
to zero/NULL initialize intercept and check_perm
Signed-off-by: Bandan Das b...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/emulate.c | 8
1 file changed,
do_insn_fetch_bytes will only be called once in a given insn_fetch and
insn_fetch_arr, because in fact it will only be called at most twice
for any instruction and the first call is explicit in x86_decode_insn.
This observation lets us hoist the call out of the memory copying loop.
It does not buy
Hoist the common case up from do_insn_fetch_byte to do_insn_fetch,
and prime the fetch_cache in x86_decode_insn. This helps a bit the
compiler and the branch predictor, but above all it lays the
ground for further changes in the next few patches.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
From: Bandan Das b...@redhat.com
A lot of initializations are unnecessary as they get set to
appropriate values before actually being used. Optimize
placement of fields in x86_emulate_ctxt
Signed-off-by: Bandan Das b...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
From: Bandan Das b...@redhat.com
x86_decode_insn already sets a default for seg_override,
so remove it from the zeroed area. Also replace set/get functions
with direct access to the field.
Signed-off-by: Bandan Das b...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
The if/return checks are useless, because we return X86EMUL_CONTINUE
anyway if we do not return.
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/emulate.c | 28 +++-
1 file changed, 11 insertions(+), 17
From: Bandan Das b...@redhat.com
Remove the if conditional - that will help us avoid
an else initialize to 0 Also, rearrange operators
for slightly better code.
Signed-off-by: Bandan Das b...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/emulate.c | 14
About 25% of the time spent in emulation of invalid guest state
is wasted in checking whether emulation is required for the next
instruction. However, this almost never changes except when a
segment register (or TR or LDTR) changes, or when there is a mode
transition (i.e. CR0 changes).
In fact,
The only purpose of this patch is to make the next patch simpler
to review. No semantic change.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/emulate.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/emulate.c
For the next patch we will need to know the full state of the
interrupt shadow; we will then set KVM_REQ_EVENT when one bit
is cleared.
However, right now get_interrupt_shadow only returns the one
corresponding to the emulated instruction, or an unconditional
0 if the emulated instruction does
Despite the provisions to emulate up to 130 consecutive instructions, in
practice KVM will emulate just one before exiting handle_invalid_guest_state,
because x86_emulate_instruction always sets KVM_REQ_EVENT.
However, we only need to do this if an interrupt could be injected,
which happens a) if
We can just blindly move all 16 bytes of ctxt-src's value to ctxt-dst.
write_register_operand will take care of writing only the lower bytes.
Avoiding a call to memcpy (the compiler optimizes it out) gains about
200 cycles on kvm-unit-tests for register-to-register moves, and makes
them about as
There are several checks for peculiar aspects of instructions in both
x86_decode_insn and x86_emulate_insn. Group them together, and guard
them with a single if that lets the processor quickly skip them all.
Make this more effective by adding two more flag bits that say whether the
.intercept and
Il 10/07/2014 12:59, kan.li...@intel.com ha scritto:
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
On Mon, Jul 14, 2014 at 01:55:03PM +0200, Paolo Bonzini wrote:
Il 10/07/2014 12:59, kan.li...@intel.com ha scritto:
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.
Il 14/07/2014 14:09, Peter Zijlstra ha scritto:
On Mon, Jul 14, 2014 at 01:55:03PM +0200, Paolo Bonzini wrote:
Il 10/07/2014 12:59, kan.li...@intel.com ha scritto:
From: Kan Liang kan.li...@intel.com
x86, perf: Protect LBR and extra_regs against KVM lying
With -cpu host, KVM reports LBR and
On Mon, Jul 14, 2014 at 02:40:33PM +0200, Paolo Bonzini wrote:
Hmmm, I thought rdmsr_safe was going to return zero, but it just returns
whatever happened to be in edx:eax which maybe should also be fixed.
Kan Liang, what happens if CONFIG_PARAVIRT=y? Do you get garbage or just no
events
Hi Peter,
On 10/07/14 13:17, Peter Maydell wrote:
On 17 June 2014 23:10, James Hogan james.ho...@imgtec.com wrote:
The patchset depends on v4 of target-mips: implement UserLocal
Register. I'm aiming for QEMU 2.1, hopefully it isn't too late to get
some final review.
Thanks to everybody who
For reproducing the issue, please build the kernel with
CONFIG_KVM_INTEL = y (for host kernel).
And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest
kernel).
I'm not sure this is a useful patch.
This is #GP'ing just because of a limitation in the PMU; just compile
the
Il 14/07/2014 15:36, Liang, Kan ha scritto:
Kan Liang, what happens if CONFIG_PARAVIRT=y? Do you get garbage or
just no events reported?
Guest rdmsr/wrmsr will eventually call rdmsr_safe/wrmsr_safe. They will handle
the #GP. So there is no error report in guest.
Yeah, but what's the
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Monday, July 14, 2014 9:40 AM
To: Liang, Kan; Peter Zijlstra
Cc: a...@firstfloor.org; linux-ker...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH V5 1/2] perf ignore LBR and extra_regs
Il
Il 14/07/2014 14:48, Peter Zijlstra ha scritto:
In fact there's no reason why LBR cannot be virtualized (though it does need
support from the processor), and it may even be possible to support
OFFCORE_RSP_X in the KVM virtual PMU.
But its not, so something needs to be done, right?
A first
On Mon, 30 Jun 2014 20:51:08 +1000
Paul Mackerras pau...@samba.org wrote:
I would like to see this go into 3.17.
FWIW: I've given this a whirl on s390 (with a dataplane disk), and
everything seems to work as before.
The only thing which is I think worth mentioning is that embedding the
routing
On Mon, Jul 14, 2014 at 05:17:04PM +0800, Tang Chen wrote:
On 07/12/2014 03:44 PM, Gleb Natapov wrote:
On Wed, Jul 09, 2014 at 10:08:03AM +0800, 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
diff --git a/arch/x86/kernel/cpu/perf_event.h
b/arch/x86/kernel/cpu/perf_event.h
index 3b2f9bd..992c678 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -464,6 +464,12 @@ struct x86_pmu {
*/
struct extra_reg *extra_regs;
On 14 July 2014 14:33, James Hogan james.ho...@imgtec.com wrote:
On 10/07/14 13:17, Peter Maydell wrote:
More generally, there doesn't really seem to be provision in the
KVM KVM_EXIT_MMIO API for returning this access failed.
I guess in theory userspace could do all the figure out how
to
CCing Jan to check my nested kvm findings below.
On Mon, Jul 14, 2014 at 03:57:09PM +0800, Tang Chen wrote:
Hi Gleb,
Thanks for the reply. Please see below.
On 07/12/2014 04:04 PM, Gleb Natapov wrote:
On Tue, Jul 08, 2014 at 09:01:32PM +0800, Tang Chen wrote:
apic access page is pinned
On 14/07/14 15:35, Peter Maydell wrote:
On 14 July 2014 14:33, James Hogan james.ho...@imgtec.com wrote:
On 10/07/14 13:17, Peter Maydell wrote:
More generally, there doesn't really seem to be provision in the
KVM KVM_EXIT_MMIO API for returning this access failed.
I guess in theory userspace
so once more; and then I'm going to route your emails to /dev/null, wrap
text at 78 chars.
On Mon, Jul 14, 2014 at 02:28:36PM +, Liang, Kan wrote:
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -464,6 +464,12 @@ struct x86_pmu {
*/
struct extra_reg *extra_regs;
unsigned int
With Book3S KVM we can create both PR and HV VMs in parallel on the same
machine. That gives us new challenges on the CAPs we return - both have
different capabilities.
When we get asked about CAPs on the kvm fd, there's nothing we can do. We
can try to be smart and assume we're running HV if HV
On PowerPC we have a small problem :). We can run both HV and PR style VMs
on the same kvm fd. While this is great, it means that anything that's
different between the two needs to have a token in form of a VM fd to find
out which one we're asking for.
The one thing where this bites us are CAPs.
In preparation to make the check_extension function available to VM scope
we add a struct kvm * argument to the function header and rename the function
accordingly. It will still be called from the /dev/kvm fd, but with a NULL
argument for struct kvm *.
Signed-off-by: Alexander Graf ag...@suse.de
The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately
on PPC some of the capabilities change depending on the way a VM was created.
So instead we need a way to expose capabilities as VM ioctl, so that we can
see which VM type we're using (HV or PR). To enable this, add the
On 14.07.14 19:03, Alexander Graf wrote:
The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately
on PPC some of the capabilities change depending on the way a VM was created.
So instead we need a way to expose capabilities as VM ioctl, so that we can
see which VM type
The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately
on PPC some of the capabilities change depending on the way a VM was created.
So instead we need a way to expose capabilities as VM ioctl, so that we can
see which VM type we're using (HV or PR). To enable this, add the
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 the
Hi Paul,
I've just seen a crash on POWER7 in HV KVM on a host where I run HV and
PR KVM VMs in parallel based on the latest code (linus/master merged
with for-3.16 merged with kvm-ppc-queue plus some PR patches):
Unable to handle kernel paging request for data at address 0x000c
Faulting
On Mon, 30 Jun 2014 20:51:08 +1000
Paul Mackerras pau...@samba.org wrote:
I would like to see this go into 3.17.
FWIW: I've given this a whirl on s390 (with a dataplane disk), and
everything seems to work as before.
The only thing which is I think worth mentioning is that embedding the
routing
In preparation to make the check_extension function available to VM scope
we add a struct kvm * argument to the function header and rename the function
accordingly. It will still be called from the /dev/kvm fd, but with a NULL
argument for struct kvm *.
Signed-off-by: Alexander Graf ag...@suse.de
On PowerPC we have a small problem :). We can run both HV and PR style VMs
on the same kvm fd. While this is great, it means that anything that's
different between the two needs to have a token in form of a VM fd to find
out which one we're asking for.
The one thing where this bites us are CAPs.
With Book3S KVM we can create both PR and HV VMs in parallel on the same
machine. That gives us new challenges on the CAPs we return - both have
different capabilities.
When we get asked about CAPs on the kvm fd, there's nothing we can do. We
can try to be smart and assume we're running HV if HV
On 14.07.14 13:24, Alexander Graf wrote:
Hi Paul,
I've just seen a crash on POWER7 in HV KVM on a host where I run HV
and PR KVM VMs in parallel based on the latest code (linus/master
merged with for-3.16 merged with kvm-ppc-queue plus some PR patches):
I guess I must have used an older
The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately
on PPC some of the capabilities change depending on the way a VM was created.
So instead we need a way to expose capabilities as VM ioctl, so that we can
see which VM type we're using (HV or PR). To enable this, add the
The KVM_CHECK_EXTENSION is only available on the kvm fd today. Unfortunately
on PPC some of the capabilities change depending on the way a VM was created.
So instead we need a way to expose capabilities as VM ioctl, so that we can
see which VM type we're using (HV or PR). To enable this, add the
57 matches
Mail list logo
