This adds missing decoder flags for sub instructions (opcodes 0x2c - 0x2d)
Signed-off-by: Mohammed Gamal
---
arch/x86/kvm/emulate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index be5e78d..5c523ed 100644
--- a/arch/x
This adds missing decoder flags for xor instructions (opcodes 0x34 - 0x35)
Signed-off-by: Mohammed Gamal
---
arch/x86/kvm/emulate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 5c523ed..1650fe5 100644
--- a/arch/x
On Wed, 2010-05-12 at 00:28 +0300, Avi Kivity wrote:
> The current lmsw implementation allows the guest to clear cr0.pe, contrary
> to the manual, which breaks EMM386.EXE.
>
> Fix by ORing the old cr0.pe with lmsw's operand.
>
> Signed-off-by: Avi Kivity
> ---
> arch/x86/kvm/x86.c |2 +-
>
On Tue, May 11, 2010 at 06:44:21AM -0400, Alex Williamson wrote:
> If the init function of a device fails, as might happen with device
> assignment, we never undo the work done by do_pci_register_device().
> This not only causes a bit of a memory leak, but also leaves a bogus
> pointer in the bus d
Peter Lieven wrote:
> Hi Qemu/KVM Devel Team,
>
> Live Migration from a 0.12.2 qemu-kvm to a 0.12.3 (and 0.12.4)
> does not work: "load of migration failed"
>
> Is there any way to find out, why exactly it fails? I have
> a lot of VMs running on 0.12.2 and would like to migrate
> them to 0.12.4
>
On Tue, May 11, 2010 at 03:47:40PM +0300, Gleb Natapov wrote:
> On Tue, May 11, 2010 at 08:45:29AM -0400, Kevin O'Connor wrote:
> > On Tue, May 11, 2010 at 10:04:25AM +0100, Stefan Hajnoczi wrote:
> > > From what I can tell SeaBIOS is reading CMOS_BIOS_BOOTFLAG1 and
> > > CMOS_BIOS_BOOTFLAG2 from n
On Tue, May 11, 2010 at 06:29:48PM +0800, Xu, Dongxiao wrote:
> From: Dongxiao Xu
>
> SDM suggests VMXON should be called before VMPTRLD, and VMXOFF
> should be called after doing VMCLEAR.
>
> Therefore in vmm coexistence case, we should firstly call VMXON
> before any VMCS operation, and then c
On Wednesday 12 May 2010 03:36:26 Marcelo Tosatti wrote:
> On Tue, May 11, 2010 at 01:30:07PM +0800, Sheng Yang wrote:
> > Only modifying some bits of CR0/CR4 needs paging mode switch.
> >
> > Add update_rsvd_bits_mask() to address EFER.NX bit updating for reserved
> > bits.
> >
> > Signed-off-by
Only modifying some bits of CR0/CR4 needs paging mode switch.
Add update_rsvd_bits_mask() to address EFER.NX bit updating for reserved bits.
Signed-off-by: Sheng Yang
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/mmu.c | 17 ++---
arch/x86/kvm/x86.c
On 05/11/2010 06:17 AM, Glauber Costa wrote:
This is the fourth version ov kvmclock fixes.
Just two minor changes in patch 5, per avi request, and
the addition of cpuid.txt file, documenting all cpuid flags
we use.
As a side effect, this patch removes the time-travel feature
in kvm guests.
Gla
On Tue, May 11, 2010 at 08:03:20AM -0700, Greg KH wrote:
>On Tue, May 11, 2010 at 09:33:50PM +1000, CaT wrote:
>> On Wed, May 05, 2010 at 10:52:50AM +0800, Américo Wang wrote:
>> > On Wed, May 5, 2010 at 10:32 AM, Yong Zhang
>> > wrote:
>> > > On Tue, May 04, 2010 at 11:37:37AM +0300, Avi Kivity
On 12.05.2010, at 05:33, Zachary Amsden wrote:
> On 05/11/2010 06:17 AM, Glauber Costa wrote:
>> This is the fourth version ov kvmclock fixes.
>>
>> Just two minor changes in patch 5, per avi request, and
>> the addition of cpuid.txt file, documenting all cpuid flags
>> we use.
>>
>> As a side
One alternative would be:
KVM_SWITCH_DIRTY_LOG passing the address of a bitmap. If the active
bitmap was clean, it returns 0, no switch performed. If the active
bitmap was dirty, the kernel switches to the new bitmap and returns 1.
And the responsability of cleaning the new bitmap could also b
Marcelo Tosatti wrote:
> On Tue, May 11, 2010 at 06:29:48PM +0800, Xu, Dongxiao wrote:
>> From: Dongxiao Xu
>>
>> SDM suggests VMXON should be called before VMPTRLD, and VMXOFF
>> should be called after doing VMCLEAR.
>>
>> Therefore in vmm coexistence case, we should firstly call VMXON
>> befor
On Mon, 10 May 2010, Avi Kivity wrote:
On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote:
For 256 color more the first priority is to find out why direct mapping is
not used. I'd suggest tracing the code that makes this decision (in
hw/*vga.c) and seeing if it's right or not.
I think this
r = 0;
@@ -1195,11 +1232,16 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
gfn = unalias_gfn(kvm, gfn);
memslot = gfn_to_memslot_unaliased(kvm, gfn);
if (memslot&& memslot->dirty_bitmap) {
- unsigned long rel_gfn = gfn - memslot->base_gfn;
+
On 05/12/2010 05:09 AM, Sheng Yang wrote:
Only modifying some bits of CR0/CR4 needs paging mode switch.
Add update_rsvd_bits_mask() to address EFER.NX bit updating for reserved bits.
Can you please repost the whole series? Due to a problem with my
mailbox I don't have the patches either
kvm_x86_ops->set_efer() would execute vcpu->arch.efer = efer, so the
checking of LMA bit didn't work.
Signed-off-by: Sheng Yang
---
arch/x86/kvm/x86.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cd8a606..2cae460 100644
Only modifying some bits of CR0/CR4 needs paging mode switch.
Add update_rsvd_bits_mask() to address EFER.NX bit updating for reserved bits.
Signed-off-by: Sheng Yang
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/mmu.c | 17 ++---
arch/x86/kvm/x86.c
Modify EFER won't result in mode switch directly. After EFER.LME set, the
following set CR0.PG would result in mode switch to IA32e. And the later
action already covered by kvm_set_cr0().
Signed-off-by: Sheng Yang
---
arch/x86/kvm/x86.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
mmu.free() already set root_hpa to INVALID_PAGE, no need to do it again in the
destory_kvm_mmu().
kvm_x86_ops->set_cr4() and set_efer() already assign cr4/efer to
vcpu->arch.cr4/efer, no need to do it again later.
Signed-off-by: Sheng Yang
---
arch/x86/kvm/mmu.c |5 ++---
arch/x86/kvm/x86.c
On 05/12/2010 08:47 AM, Alexander Graf wrote:
How about stable queuing of this one?
Only after this gets some serious field testing. I'm not happy to trade
a known issue for an unknown regression. While I don't expect any
problems with the patchset, testing has often proven me wrong.
--
On 12.05.2010, at 08:33, Avi Kivity wrote:
> On 05/12/2010 08:47 AM, Alexander Graf wrote:
>> How about stable queuing of this one?
>>
>
> Only after this gets some serious field testing. I'm not happy to trade a
> known issue for an unknown regression. While I don't expect any problems
> w
On 05/12/2010 09:14 AM, Gerhard Wiesinger wrote:
On Mon, 10 May 2010, Avi Kivity wrote:
On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote:
For 256 color more the first priority is to find out why direct
mapping is not used. I'd suggest tracing the code that makes this
decision (in hw/*vga.
In common cases, guest SRAO MCE will cause corresponding poisoned page
be un-mapped and SIGBUS be sent to QEMU-KVM, then QEMU-KVM will relay
the MCE to guest OS.
But it is reported that if the poisoned page is accessed in guest
after un-mapped and before MCE is relayed to guest OS, QEMU-KVM will
b
On 05/12/2010 09:33 AM, Sheng Yang wrote:
Only modifying some bits of CR0/CR4 needs paging mode switch.
Add update_rsvd_bits_mask() to address EFER.NX bit updating for reserved bits.
@@ -2335,6 +2335,19 @@ static void reset_rsvds_bits_mask(struct kvm_vcpu *vcpu,
int level)
}
}
+voi
101 - 126 of 126 matches
Mail list logo
