3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
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 guest exit, presumably in
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit c4c6f2cad9e1d4cc076bc183c3689cc9e7019c75 upstream.
Ensure any hardware page table walker (HTW) is disabled while in KVM
guest mode, as KVM doesn't yet set up hardware page t
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is bu
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit ca5d25642e212f73492d332d95dc90ef46a0e8dc upstream.
Export the _save_msa asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is b
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit c4c6f2cad9e1d4cc076bc183c3689cc9e7019c75 upstream.
Ensure any hardware page table walker (HTW) is disabled while in KVM
guest mode, as KVM doesn't yet set up hardware page t
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit ca5d25642e212f73492d332d95dc90ef46a0e8dc upstream.
Export the _save_msa asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is b
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is bu
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
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 guest exit, presumably in
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: James Hogan
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 guest exit, presumably in
On Wed, Mar 4, 2015 at 12:04 PM, Bandan Das wrote:
> Wincy Van writes:
>
>> On Wed, Mar 4, 2015 at 1:39 AM, Bandan Das wrote:
>>> Wincy Van writes:
>>>
In commit 3af18d9c5fe9 ("KVM: nVMX: Prepare for using hardware MSR
bitmap"),
we are setting MSR_BITMAP in prepare_vmcs02 if we
Wincy Van writes:
> On Wed, Mar 4, 2015 at 1:39 AM, Bandan Das wrote:
>> Wincy Van 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 b
On Wed, Mar 4, 2015 at 1:39 AM, Bandan Das wrote:
> Wincy Van 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
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 writes:
>
>> halt_poll_ns is used only locally. Make it static.
>>
>> Signed-off-by: Christian Borntraeger
>> ---
>> virt/kvm/kvm_main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/virt/kvm/kvm_ma
Christian Borntraeger writes:
> halt_poll_ns is used only locally. Make it static.
>
> Signed-off-by: Christian Borntraeger
> ---
> virt/kvm/kvm_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 34310a8..58bc2a9 100
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 momen
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 scenari
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 5b79b1cadd3e565b6d1a5ba59764b
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 so
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,
>> +
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/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 classif
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
Wincy Van 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 vmx_msr_bitmap_nested
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 wr
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-w
2015-03-02 13:43-0600, Joel Schopp:
> From: David Kaplan
>
> No need to re-decode WBINVD since we know what it is from the intercept.
>
> Signed-off-by: David Kaplan
> [extracted from larger unlrelated patch, forward ported, tested,style cleanup]
> Signed-off-by: Joel Schopp
> ---
Reviewed-by
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
> ---
Reviewed-by: Radim Krčmář
> diff --git a/a
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
2015-03-02 15:02-0600, Joel Schopp:
> From: David Kaplan
>
> 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 couple return 0
Peter Maydell writes:
> On 3 March 2015 at 20:06, Paolo Bonzini 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
2015-03-03 12:18+0200, Nadav Amit:
> Paolo Bonzini 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 fir
On 3 March 2015 at 20:06, Paolo Bonzini 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 two f
Christoffer Dall 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 +, Alex Bennée 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 two for ARM. Either the process is
> > > running or not.
> >
On Mon, 2 Mar 2015 16:17:33 -0300
Eduardo Habkost 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
> it in a r
Peter Maydell writes:
> On 26 February 2015 at 01:02, 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
On Mon, 02 Mar 2015 17:57:01 +0100
Andreas Färber wrote:
> Am 02.03.2015 um 17:43 schrieb Michael Mueller:
> > On Mon, 02 Mar 2015 14:57:21 +0100
> > Andreas Färber wrote:
> >
> >>> int configure_accelerator(MachineState *ms)
> >>> {
> >>> -const char *p;
> >>> +const char *p, *name;
Paolo,
Thanks for the feedback. One small comment below.
Paolo Bonzini 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 appreciate
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. As
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
43 matches
Mail list logo