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 of
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
---
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
--- a/arch/powerpc/kvm/booke.c
+++ b
On Thu, Jul 10, 2014 at 03:59:43AM -0700, kan.li...@intel.com wrote:
> 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_reg
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_n
From: Bandan Das
Core emulator functions all belong in emulator.c,
x86 should have no knowledge of emulator internals
Signed-off-by: Bandan Das
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/kvm_emulate.h | 1 +
arch/x86/kvm/emulate.c | 13 +
arch/x86/kvm/x86.c
From: Bandan Das
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 of range value
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 whe
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 had
This simplifies the code a bit, especially the overflow checks.
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/kvm_emulate.h | 4 ++--
arch/x86/kvm/emulate.c | 34 +++---
arch/x86/kvm/trace.h | 6 +++---
3 files changed, 20 insertion
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
---
a
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 lo
From: Bandan Das
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
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/emulate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/ar
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
---
arch/x86/kvm/em
From: Bandan Das
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
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/kvm_emulate.h | 20 +++-
From: Bandan Das
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
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/kvm_emulate.h | 3 +--
arch/x86/kvm/emu
The "if/return" checks are useless, because we return X86EMUL_CONTINUE
anyway if we do not return.
Reviewed-by: Marcelo Tosatti
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/emulate.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm
From: Bandan Das
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
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/emulate.c | 14 ++
1 file changed, 6 insertions(+), 8 deletion
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
---
arch/x86/kvm/emulate.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 15
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 not
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
Il 10/07/2014 12:59, kan.li...@intel.com ha scritto:
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 access
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
> >
> >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.
> >Whe
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
x86, perf: Protect LBR and extra_regs against KVM lying
With -cpu host, KVM reports LBR and extra_regs support,
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 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 has alread
> >>> 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; ju
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 ef
> -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 thi
On Mon, 30 Jun 2014 20:51:08 +1000
Paul Mackerras 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 entry into the
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.
>
> > 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_re
On 14 July 2014 14:33, James Hogan 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 adjust CPU stat
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
On 14/07/14 15:35, Peter Maydell wrote:
> On 14 July 2014 14:33, James Hogan 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
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;
> > >
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 i
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. W
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
---
arch/arm
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
K
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 we're
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
K
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_regs
On Mon, 14 Jul 2014 19:03:35 +0200
Alexander Graf wrote:
> 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 o
50 matches
Mail list logo
