I got two conformance issues in x86/KVM. For the first one I have no
solution. For the latter, my solution is not “great”. Ideas and feedback
would be appreciated.
The first problem is caused by the deprecating of FPU CS/DS in new Intel
CPUs. Assume the VM executes a floating point instruction in
On 03/03/2015 09:34, Nadav Amit wrote:
I got two conformance issues in x86/KVM. For the first one I have no
solution. For the latter, my solution is not “great”. Ideas and feedback
would be appreciated.
The first problem is caused by the deprecating of FPU CS/DS in new Intel
CPUs. Assume
On Mon, 2 Mar 2015 16:17:33 -0300
Eduardo Habkost ehabk...@redhat.com wrote:
+if (probe_mode) {
+/* Use these accelerators in probe mode, tcg should be last */
+p = probe_mode_accels;
I don't fully understand the purpose of this patch yet (I will discuss
On 03/03/2015 11:56, Alex Bennée wrote:
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
potential states for x86 we only use two for ARM. Either the process is
running or not.
By this
Peter Maydell peter.mayd...@linaro.org writes:
On 3 March 2015 at 20:06, Paolo Bonzini pbonz...@redhat.com wrote:
On 03/03/2015 11:56, Alex Bennée wrote:
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a
2015-03-02 13:43-0600, Joel Schopp:
Currently kvm_emulate() skips the instruction but kvm_emulate_* sometimes
don't. The end reult is the caller ends up doing the skip themselves.
Let's make them consistant.
Signed-off-by: Joel Schopp joel.sch...@amd.com
---
Reviewed-by: Radim Krčmář
2015-03-02 15:02-0600, Joel Schopp:
+int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port)
+{
+ unsigned long val;
+ int ret = emulator_pio_in_emulated(vcpu-arch.emulate_ctxt, size,
+port, val, 1);
+
Btw. does this return 1
2015-03-02 15:02-0600, Joel Schopp:
From: David Kaplan david.kap...@amd.com
We can make the in instruction go faster the same way the out instruction is
already.
(How much faster do benchmarks run?)
Changes from v2[Joel]:
* changed rax from u32 to unsigned long
* changed a
2015-03-02 13:43-0600, Joel Schopp:
From: David Kaplan david.kap...@amd.com
No need to re-decode WBINVD since we know what it is from the intercept.
Signed-off-by: David Kaplan david.kap...@amd.com
[extracted from larger unlrelated patch, forward ported, tested,style cleanup]
On 03/03/2015 17:30, Alex Bennée wrote:
Right now this is not migrated on ARM if I remember correctly, but
perhaps you'll want to add it in the future.
...which is why we don't need to migrate this: it just means
that migration during WFI causes an unnecessary-wakeup, which
is
Hi Ard,
couple side effects would be guest address translation may
return attributes in PAR register it wound not expect.
Likewise for read of MAIR registers.
- Mario
On 02/19/2015 02:54 AM, Ard Biesheuvel wrote:
This adds handling to el1_trap() to perform some sysreg writes directly
in EL2,
Thank you for your detailed review on several of my patches.
+static int complete_fast_pio(struct kvm_vcpu *vcpu)
(complete_fast_pio_in()?)
If I do a v4 I'll adopt that name.
+{
+unsigned long new_rax = kvm_register_read(vcpu, VCPU_REGS_RAX);
Shouldn't we handle writes in EAX
On Thu, Feb 19, 2015 at 10:54:43AM +, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force the guest
to avoid uncached mappings, at least from the moment the MMU is on. (Before
that, all of memory is implicitly classified as Device-nGnRnE)
That's just
On 03/03/2015 10:44 AM, Radim Krčmář wrote:
2015-03-02 15:02-0600, Joel Schopp:
+int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port)
+{
+unsigned long val;
+int ret = emulator_pio_in_emulated(vcpu-arch.emulate_ctxt, size,
+
On 03/03/15 18:34, Alexander Graf wrote:
On 02/19/2015 11:54 AM, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force
the guest
to avoid uncached mappings, at least from the moment the MMU is on.
(Before
that, all of memory is implicitly classified as
2015-03-03 13:48-0600, Joel Schopp:
+ unsigned long new_rax = kvm_register_read(vcpu, VCPU_REGS_RAX);
Shouldn't we handle writes in EAX differently than in AX and AL, because
of implicit zero extension.
I don't think the implicit zero extension hurts us here, but maybe there
is something
On 03/04/2015 07:43 AM, Alexander Graf wrote:
On 03.03.15 01:42, Alexey Kardashevskiy wrote:
On 03/03/2015 12:51 AM, Alexander Graf wrote:
On 02.03.15 14:42, Andreas Färber wrote:
Am 02.03.2015 um 14:37 schrieb Alexander Graf:
On 01.03.15 01:31, Andreas Färber wrote:
This reverts commit
Am 03.03.2015 um 22:42 schrieb Bandan Das:
Christian Borntraeger borntrae...@de.ibm.com writes:
halt_poll_ns is used only locally. Make it static.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 03.03.15 01:42, Alexey Kardashevskiy wrote:
On 03/03/2015 12:51 AM, Alexander Graf wrote:
On 02.03.15 14:42, Andreas Färber wrote:
Am 02.03.2015 um 14:37 schrieb Alexander Graf:
On 01.03.15 01:31, Andreas Färber wrote:
This reverts commit 5b79b1cadd3e565b6d1a5ba59764bd47af58b271 to
On Tue, Mar 03, 2015 at 07:13:48PM +0100, Laszlo Ersek wrote:
On 03/03/15 18:34, Alexander Graf wrote:
On 02/19/2015 11:54 AM, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force
the guest
to avoid uncached mappings, at least from the moment the MMU
Christian Borntraeger borntrae...@de.ibm.com writes:
halt_poll_ns is used only locally. Make it static.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
virt/kvm/kvm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c
2015-03-03 14:03-0600, Joel Schopp:
On 03/03/2015 10:44 AM, Radim Krčmář wrote:
2015-03-02 15:02-0600, Joel Schopp:
+ int ret = emulator_pio_in_emulated(vcpu-arch.emulate_ctxt, size,
+ port, val, 1);
Btw. does this return 1 in some scenario?
If a
In commit 3af18d9c5fe9 (KVM: nVMX: Prepare for using hardware MSR bitmap),
we are setting MSR_BITMAP in prepare_vmcs02 if we should use hardware. This
is not enough since the field will be modified by following vmx_set_efer.
Fix this by setting vmx_msr_bitmap_nested in vmx_set_msr_bitmap if vcpu
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit c4c6f2cad9e1d4cc076bc183c3689cc9e7019c75 upstream.
Ensure any hardware page table walker (HTW) is disabled while in KVM
guest mode, as KVM doesn't yet
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit ca5d25642e212f73492d332d95dc90ef46a0e8dc upstream.
Export the _save_msa asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit c4c6f2cad9e1d4cc076bc183c3689cc9e7019c75 upstream.
Ensure any hardware page table walker (HTW) is disabled while in KVM
guest mode, as KVM doesn't yet
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit f798217dfd038af981a18bbe4bc57027a08bb182 upstream.
The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
kvm_mips_set_c0_status() on a
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit f798217dfd038af981a18bbe4bc57027a08bb182 upstream.
The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
kvm_mips_set_c0_status() on a
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit f798217dfd038af981a18bbe4bc57027a08bb182 upstream.
The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
kvm_mips_set_c0_status() on a
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan james.ho...@imgtec.com
commit ca5d25642e212f73492d332d95dc90ef46a0e8dc upstream.
Export the _save_msa asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make
Wincy Van fanwenyi0...@gmail.com writes:
On Wed, Mar 4, 2015 at 1:39 AM, Bandan Das b...@redhat.com wrote:
Wincy Van fanwenyi0...@gmail.com writes:
In commit 3af18d9c5fe9 (KVM: nVMX: Prepare for using hardware MSR bitmap),
we are setting MSR_BITMAP in prepare_vmcs02 if we should use
On Wed, Mar 4, 2015 at 1:39 AM, Bandan Das b...@redhat.com wrote:
Wincy Van fanwenyi0...@gmail.com writes:
In commit 3af18d9c5fe9 (KVM: nVMX: Prepare for using hardware MSR bitmap),
we are setting MSR_BITMAP in prepare_vmcs02 if we should use hardware. This
is not enough since the field will
On Wed, Mar 4, 2015 at 12:04 PM, Bandan Das b...@redhat.com wrote:
Wincy Van fanwenyi0...@gmail.com writes:
On Wed, Mar 4, 2015 at 1:39 AM, Bandan Das b...@redhat.com wrote:
Wincy Van fanwenyi0...@gmail.com writes:
In commit 3af18d9c5fe9 (KVM: nVMX: Prepare for using hardware MSR
bitmap),
On 02/19/2015 11:54 AM, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force the guest
to avoid uncached mappings, at least from the moment the MMU is on. (Before
that, all of memory is implicitly classified as Device-nGnRnE)
The idea (patch #2) is to trap
Wincy Van fanwenyi0...@gmail.com writes:
In commit 3af18d9c5fe9 (KVM: nVMX: Prepare for using hardware MSR bitmap),
we are setting MSR_BITMAP in prepare_vmcs02 if we should use hardware. This
is not enough since the field will be modified by following vmx_set_efer.
Fix this by setting
On Mon, 02 Mar 2015 17:57:01 +0100
Andreas Färber afaer...@suse.de wrote:
Am 02.03.2015 um 17:43 schrieb Michael Mueller:
On Mon, 02 Mar 2015 14:57:21 +0100
Andreas Färber afaer...@suse.de wrote:
int configure_accelerator(MachineState *ms)
{
-const char *p;
+const char
Peter Maydell peter.mayd...@linaro.org writes:
On 26 February 2015 at 01:02, Alex Bennée alex.ben...@linaro.org wrote:
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
potential states for x86 we
Christoffer Dall christoffer.d...@linaro.org writes:
Hi Alex,
Seems like you accidentally sent out two copies of this patch, hopefully
I'm reviewing the right one...
Oops, perils of not wiping your output directory. I think it was just a
title tweak!
On Wed, Feb 25, 2015 at 04:02:38PM
On 3 March 2015 at 20:06, Paolo Bonzini pbonz...@redhat.com wrote:
On 03/03/2015 11:56, Alex Bennée wrote:
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
potential states for x86 we only use
Paolo,
Thanks for the feedback. One small comment below.
Paolo Bonzini pbonz...@redhat.com wrote:
On 03/03/2015 09:34, Nadav Amit wrote:
I got two conformance issues in x86/KVM. For the first one I have no
solution. For the latter, my solution is not “great”. Ideas and feedback
would be
2015-03-03 12:18+0200, Nadav Amit:
Paolo Bonzini pbonz...@redhat.com wrote:
On 03/03/2015 09:34, Nadav Amit wrote:
I got two conformance issues in x86/KVM. For the first one I have no
solution. For the latter, my solution is not “great”. Ideas and feedback
would be appreciated.
The
43 matches
Mail list logo
