On Tue, Sep 10, 2013 at 09:12:11AM +0800, Arthur Chunqi Li wrote:
On Mon, Sep 9, 2013 at 8:29 PM, Gleb Natapov g...@redhat.com wrote:
On Mon, Sep 09, 2013 at 12:53:02PM +0200, Paolo Bonzini wrote:
Il 09/09/2013 12:22, SPA ha scritto:
Thanks Paolo.
Is there a way where reads would
On Mon, Sep 09, 2013 at 09:40:20AM -0600, Bruce Rogers wrote:
Opcode CA
This gets used by a DOS based NetWare guest.
Signed-off-by: Bruce Rogers brog...@suse.com
Reviewed-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c | 14 +-
1 files changed, 13
On 03.09.2013 20:13, Gleb Natapov wrote:
On Tue, Sep 03, 2013 at 03:19:27PM +0200, Stefan Bader wrote:
With current 3.11 kernels we got reports of nested qemu failing in weird
ways. I
believe 3.10 also had issues before. Not sure whether those were the same.
With 3.8 based kernels (close to
Currently on powerpc we store and access floating-point and vector
state in various ad-hoc arrays in places such as the thread_struct and
the kvm_vcpu_arch struct. This leads to code duplication for the code
that transfers this state between CPU registers and memory, and leads
to double-copying
This uses struct thread_fp_state and struct thread_vr_state to store
the floating-point, VMX/Altivec and VSX state, rather than flat arrays.
This makes transferring the state to/from the thread_struct simpler
and allows us to unify the get/set_one_reg implementations for the
VSX registers.
Now that we have the vcpu floating-point and vector state stored in
the same type of struct as the main kernel uses, we can load that
state directly from the vcpu struct instead of having extra copies
to/from the thread_struct. Similarly, when the guest state needs to
be saved, we can have it
This modifies kvmppc_load_fp and kvmppc_save_fp to use the generic
FP/VSX and VMX load/store functions instead of open-coding the
FP/VSX/VMX load/store instructions. Since kvmppc_load/save_fp don't
follow C calling conventions, we make them private symbols within
book3s_hv_rmhandlers.S.
The load_up_fpu and load_up_altivec functions were never intended to
be called from C, and do things like modifying the MSR value in their
callers' stack frames, which are assumed to be interrupt frames. In
addition, on 32-bit Book S they require the MMU to be off.
This makes KVM use the new
This creates new 'thread_fp_state' and 'thread_vr_state' structures
to store FP/VSX state (including FPSCR) and Altivec/VSX state
(including VSCR), and uses them in the thread_struct. In the
thread_fp_state, the FPRs and VSRs are represented as u64 rather
than double, since we rarely perform
This provides a facility which is intended for use by KVM, where the
contents of the FP/VSX and VMX (Altivec) registers can be saved away
to somewhere other than the thread_struct when kernel code wants to
use floating point or VMX instructions. This is done by providing a
pointer in the
Il 04/09/2013 18:44, Paul Gortmaker ha scritto:
Hi Greg,
The 3.4.44+ cherry pick:
commit 5b5b30580218eae22609989546bac6e44d0eda6e
Author: Gleb Natapov g...@redhat.com
Date: Wed Apr 24 13:38:36 2013 +0300
KVM: X86 emulator: fix source operand decoding for
Il 10/09/2013 12:53, Gleb Natapov ha scritto:
+#ifndef __KERNEL__
+/* For hv_*() */
+#define KVM_EMULATE(name) [HV_SYS_##name] = qemu_emulate_illegal,
+#define USER_EMULATE(name) [HV_SYS_##name] = qemu_emulate_hv_##name,
+#define NO_EMULATE(name) [HV_SYS_##name] = qemu_emulate_illegal,
Il 28/08/2013 22:58, Chris Metcalf ha scritto:
This change enables support for a virtio-based console,
network support, and block driver support.
We remove some debug code in relocate_kernel_64.S that made raw
calls to the hv_console_putc Tilera hypervisor API, since everything
now should
On Mon, Sep 2, 2013 at 4:21 PM, Gleb Natapov g...@redhat.com wrote:
On Thu, Aug 08, 2013 at 04:26:28PM +0200, Jan Kiszka wrote:
Likely a typo, but a fatal one as kvm_set_cr0 performs checks on the
Not a typo :) That what Avi asked for do during initial nested VMX
review:
Il 10/09/2013 15:14, Arthur Chunqi Li ha scritto:
On Thu, Aug 08, 2013 at 04:26:28PM +0200, Jan Kiszka wrote:
Likely a typo, but a fatal one as kvm_set_cr0 performs checks on the
Not a typo :) That what Avi asked for do during initial nested VMX
review:
Hi
Please, send any topic that you are interested in covering.
Last week I forgot to send the call for topics. We still have a topic there.
Thanks, Juan.
Agenda so far:
- Talk about qemu reverse executing (1st description was done this week)
How to handle IO when we want to do reverse
On 10.09.2013, at 05:20, Paul Mackerras wrote:
This creates new 'thread_fp_state' and 'thread_vr_state' structures
to store FP/VSX state (including FPSCR) and Altivec/VSX state
(including VSCR), and uses them in the thread_struct. In the
thread_fp_state, the FPRs and VSRs are represented as
On 10.09.2013, at 05:21, Paul Mackerras wrote:
This provides a facility which is intended for use by KVM, where the
contents of the FP/VSX and VMX (Altivec) registers can be saved away
to somewhere other than the thread_struct when kernel code wants to
use floating point or VMX instructions.
Hi folks,
We have been experiencing a problem with our test bed for a while now, and were
hoping perhaps some of the expertise on this mailing list might be able to help
us find a solution.
We have a cluster of 7 KVM vms on a host. The host OS is Fedora 18, and the
guest OS is Centos 6.4.
On 10.09.2013, at 05:22, Paul Mackerras wrote:
Now that we have the vcpu floating-point and vector state stored in
the same type of struct as the main kernel uses, we can load that
state directly from the vcpu struct instead of having extra copies
to/from the thread_struct. Similarly, when
On 10.09.2013, at 05:22, Paul Mackerras wrote:
This modifies kvmppc_load_fp and kvmppc_save_fp to use the generic
FP/VSX and VMX load/store functions instead of open-coding the
FP/VSX/VMX load/store instructions. Since kvmppc_load/save_fp don't
follow C calling conventions, we make them
I'm doing some experimenting in our Development lab and as a result I'm
kickstarting over and over Virtual guests. This is of course causing the guest
Id to increment by one with each test. I've googled around and tried searching
the list but have not found out how (if at all) it would be
On Tue, Sep 10, 2013 at 12:12:47PM -0500, Alexander Graf wrote:
On 10.09.2013, at 05:21, Paul Mackerras wrote:
@@ -212,6 +212,7 @@ struct thread_struct {
#endif
#endif
struct thread_fp_state fp_state;
+ struct thread_fp_state *fp_save_area;
Why do you need these pointers?
On Tue, Sep 10, 2013 at 12:07:46PM -0500, Alexander Graf wrote:
On 10.09.2013, at 05:20, Paul Mackerras wrote:
@@ -897,7 +897,7 @@ int fix_alignment(struct pt_regs *regs)
return -EFAULT;
}
} else if (flags F) {
- data.dd =
This patch just contains two minor changes to EPT framwork.
1. Reorder macro definition
2. Fix bug of setting CPU_EPT without check.
Signed-off-by: Arthur Chunqi Li yzt...@gmail.com
---
x86/vmx.h |2 +-
x86/vmx_tests.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
Hi Paolo,
Sorry but I should trouble you merging these two minor changes to vmx branch.
Until now, all the commits in vmx branch seems fine (if others have no
comments). Because I have some patches to commit based on vmx branch,
should we merge this branch to master or I just commit patches
Currently on powerpc we store and access floating-point and vector
state in various ad-hoc arrays in places such as the thread_struct and
the kvm_vcpu_arch struct. This leads to code duplication for the code
that transfers this state between CPU registers and memory, and leads
to double-copying
This provides a facility which is intended for use by KVM, where the
contents of the FP/VSX and VMX (Altivec) registers can be saved away
to somewhere other than the thread_struct when kernel code wants to
use floating point or VMX instructions. This is done by providing a
pointer in the
The load_up_fpu and load_up_altivec functions were never intended to
be called from C, and do things like modifying the MSR value in their
callers' stack frames, which are assumed to be interrupt frames. In
addition, on 32-bit Book S they require the MMU to be off.
This makes KVM use the new
This uses struct thread_fp_state and struct thread_vr_state to store
the floating-point, VMX/Altivec and VSX state, rather than flat arrays.
This makes transferring the state to/from the thread_struct simpler
and allows us to unify the get/set_one_reg implementations for the
VSX registers.
This creates new 'thread_fp_state' and 'thread_vr_state' structures
to store FP/VSX state (including FPSCR) and Altivec/VSX state
(including VSCR), and uses them in the thread_struct. In the
thread_fp_state, the FPRs and VSRs are represented as u64 rather
than double, since we rarely perform
This modifies kvmppc_load_fp and kvmppc_save_fp to use the generic
FP/VSX and VMX load/store functions instead of open-coding the
FP/VSX/VMX load/store instructions. Since kvmppc_load/save_fp don't
follow C calling conventions, we make them private symbols within
book3s_hv_rmhandlers.S.
Now that we have the vcpu floating-point and vector state stored in
the same type of struct as the main kernel uses, we can load that
state directly from the vcpu struct instead of having extra copies
to/from the thread_struct. Similarly, when the guest state needs to
be saved, we can have it
On 10.09.2013, at 05:20, Paul Mackerras wrote:
This creates new 'thread_fp_state' and 'thread_vr_state' structures
to store FP/VSX state (including FPSCR) and Altivec/VSX state
(including VSCR), and uses them in the thread_struct. In the
thread_fp_state, the FPRs and VSRs are represented as
On 10.09.2013, at 05:21, Paul Mackerras wrote:
This provides a facility which is intended for use by KVM, where the
contents of the FP/VSX and VMX (Altivec) registers can be saved away
to somewhere other than the thread_struct when kernel code wants to
use floating point or VMX instructions.
On 10.09.2013, at 05:22, Paul Mackerras wrote:
Now that we have the vcpu floating-point and vector state stored in
the same type of struct as the main kernel uses, we can load that
state directly from the vcpu struct instead of having extra copies
to/from the thread_struct. Similarly, when
On 10.09.2013, at 05:22, Paul Mackerras wrote:
This modifies kvmppc_load_fp and kvmppc_save_fp to use the generic
FP/VSX and VMX load/store functions instead of open-coding the
FP/VSX/VMX load/store instructions. Since kvmppc_load/save_fp don't
follow C calling conventions, we make them
37 matches
Mail list logo
