Currently, kdump just makes all the logical processors leave VMX operation by
executing VMXOFF instruction, so any VMCSs active on the logical processors may
be corrupted. But, sometimes, we need the VMCSs to debug guest images contained
in the host vmcore. To prevent the corruption, we should
This patch provides an alternative way to clear vmcss related to guests
on all cpus when doing kdump.
Signed-off-by: zhangyanfei zhangyan...@cn.fujitsu.com
---
arch/x86/include/asm/kexec.h |3 +++
arch/x86/kernel/crash.c | 23 +++
2 files changed, 26 insertions(+),
Signed-off-by: zhangyanfei zhangyan...@cn.fujitsu.com
---
arch/x86/kvm/vmx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4ff0ab9..f6a16b2 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -41,6 +41,7 @@
This patch exports the variable clear_loaded_vmcs_enabled to userspace.
Signed-off-by: zhangyanfei zhangyan...@cn.fujitsu.com
---
Documentation/sysctl/kernel.txt |8
kernel/sysctl.c | 10 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git
Hey all,
I have a simple user question. I have a few LVM based KVM guests and
wan't to backup them to files. The simple and nasty way would be to
create a complete output file with dd, which wastes very much space. So
I would like to create a backup of the LVM to a file which only locates
Il 12/10/2012 00:37, Rusty Russell ha scritto:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
OK. Well, Anthony wants qemu to be robust in this regard, so I am
tempted to rework all the qemu drivers to handle arbitrary layouts.
They
On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
I have a simple user question. I have a few LVM based KVM guests and
wan't to backup them to files. The simple and nasty way would be to
create a complete output file with dd, which wastes very much space.
So I would like to create
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
I have a simple user question. I have a few LVM based KVM guests and
wan't to backup them to files. The simple and nasty way would be to
On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote:
For writes, the standard seems to be a commit latch. We could abuse the
generation count for this: the driver writes to it to commit config
changes.
I think this will work. There are a couple of things that bother me:
On Fri, Oct 12, 2012 at 08:21:50PM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote:
For writes, the standard seems to be a commit latch. We could abuse the
generation count for this: the driver writes to
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
I have a simple user question. I have a few LVM based KVM guests
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
I have a simple user
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
On Fri,
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri,
On Fri, 12 Oct 2012 09:07:46 +1030
Rusty Russell ru...@rustcorp.com.au wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
OK. Well, Anthony wants qemu to be robust in this regard, so I am
tempted to rework all the qemu drivers
On Fri, Oct 12, 2012 at 1:51 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp
Am 12.10.2012 14:59, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 1:51 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri,
Hello Michael,
Thanks for the review!
On 10/11/2012 08:41 PM, Michael S. Tsirkin wrote:
On Tue, Oct 09, 2012 at 04:05:18PM +0800, Asias He wrote:
vhost-blk is an in-kernel virito-blk device accelerator.
Due to lack of proper in-kernel AIO interface, this version converts
guest's I/O request
On Fri, Oct 12, 2012 at 3:02 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 14:59, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 1:51 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp
On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
I would leave them raw as long as they are sparse (zero regions do not
take up space). If you need to copy them you can either convert to
qcow2 or use tools that preserve sparseness (BTW compression tools are
good at
Am 12.10.2012 16:36, schrieb Javier Guerra Giraldez:
On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
I would leave them raw as long as they are sparse (zero regions do not
take up space). If you need to copy them you can either convert to
qcow2 or use tools that
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri,
This was part of [PATCH v6 00/16] Allow changing of Hypervisor CPUIDs.
Since it is no longer in use by any of the patches in v7, I have split it off.
Don Slutz (1):
target-i386: Add missing kvm bits.
target-i386/cpu.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
--
On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp
On Fri, Oct 12, 2012 at 4:36 PM, Javier Guerra Giraldez
jav...@guerrag.com wrote:
On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
I would leave them raw as long as they are sparse (zero regions do not
take up space). If you need to copy them you can either convert to
Am 12.10.2012 21:13, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri,
Currently -cpu host,-kvmclock,-kvm_nopiodelay,-kvm_mmu does not
turn off all bits in CPUID 0x4001 EAX.
The missing ones are KVM_FEATURE_STEAL_TIME and
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT.
This adds the names kvm_steal_time and kvm_clock_stable for these
bits.
Signed-off-by: Don Slutz
This was part of [PATCH v6 00/16] Allow changing of Hypervisor CPUIDs.
Since it is no longer in use by any of the patches in v7, I have split it off.
Don Slutz (1):
target-i386: Add missing kvm bits.
target-i386/cpu.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
--
Also known as Paravirtualization CPUIDs.
This is primarily done so that the guest will think it is running
under vmware when hypervisor-vendor=vmware is specified as a
property of a cpu.
Patches 1 to 3 define new cpu properties.
Patches 4 to 6 Add QOM access to the new properties.
Patches 7 to 9
Part of target-i386: Add way to expose VMWare CPUID
Also known as Paravirtualization level or maximim cpuid function present in
this leaf.
This is the EAX value for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
This is based on:
Microsoft Hypervisor CPUID Leaves:
Part of target-i386: Add way to expose VMWare CPUID
Also known as Paravirtualization vendor.
This is EBX, ECX, and EDX data for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
This is based on:
Microsoft Hypervisor CPUID Leaves:
Part of target-i386: Add way to expose VMWare CPUID
Also known as kvm festures or Hypervisor vendor-neutral interface
identification.
This is the EAX value for 0x4001.
QEMU knows this is KVM_CPUID_FEATURES (0x4001) in some builds.
This is based on:
Microsoft Hypervisor CPUID Leaves:
Part of target-i386: Add way to expose VMWare CPUID
These are modeled after x86_cpuid_get_xlevel and x86_cpuid_set_xlevel.
Signed-off-by: Don Slutz d...@cloudswitch.com
---
target-i386/cpu.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git
Part of target-i386: Add way to expose VMWare CPUID
These are modeled after x86_cpuid_set_vendor and x86_cpuid_get_vendor.
Since kvm's vendor is shorter, the test for correct size is removed and zero
padding is added.
See http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/00100.html for
Part of target-i386: Add way to expose VMWare CPUID
Also known as kvm festures or Hypervisor vendor-neutral interface
identification.
This is just the EAX value for 0x4001.
QEMU knows this is KVM_CPUID_FEATURES (0x4001) in some builds.
When exposing VMWare CPUID this needs to be set to
Part of target-i386: Add way to expose VMWare CPUID
At this stage it is used to set the cpu object's hypervisor level to
the default for Microsoft's Hypervisor.
Also known as Paravirtualization level or maximim cpuid function
present in this leaf. This is the EAX value for 0x4000.
This is
Part of target-i386: Add way to expose VMWare CPUID
At this stage it is used to set the cpu object's hypervisor vendor
to the default for Microsoft's Hypervisor (Microsoft Hv).
Also known as Paravirtualization vendor.
This is EBX, ECX, EDX data for 0x4000.
QEMU knows this is
Part of target-i386: Add way to expose VMWare CPUID
At this stage it is used to set the cpu object's hypervisor features
to the default for Microsoft's Hypervisor (Hv#1).
Also known as kvm festures or Hypervisor vendor-neutral interface
identification.
This is the EAX value for 0x4001.
Part of target-i386: Add way to expose VMWare CPUID
Also known as Paravirtualization level.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
Signed-off-by: Don Slutz d...@cloudswitch.com
---
target-i386/kvm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git
Part of target-i386: Add way to expose VMWare CPUID
Also known as Paravirtualization vendor.
This is EBX, ECX, and EDX data for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
If hypervisor vendor is set then add kvm's
signature at KVM_CPUID_SIGNATURE_NEXT (0x4100).
Part of target-i386: Add way to expose VMWare CPUID
QEMU knows this as KVM_CPUID_FEATURES (0x4001) in some builds.
If hypervisor features are set, then pass adjusted
cpuid_kvm_features as EAX in 0x4101.
This is based on:
Microsoft Hypervisor CPUID Leaves:
Part of target-i386: Add way to expose VMWare CPUID
This is EAX and EBX data for 0x4010.
Add new #define CPUID_HV_TIMING_INFO for this.
The best documentation I have found is:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/22643
And a test under ESXi 4.0 shows that VMware is
Part of target-i386: Add way to expose VMWare CPUID
Also adds some other known names (kvm, hyperv) to Hypervisor vendor.
This allows hypervisor-vendor=vmware3 instead of
hypervisor-vendor=VMwareVMware,hypervisor-level=2,hypervisor-features=0.
And hypervisor-vendor=vmware instead of
Part of target-i386: Add way to expose VMWare CPUID
Also known as Paravirtualization level.
QEMU knows this as KVM_CPUID_SIGNATURE (0x4000) in kvm on linux.
This does not provide vendor support in tcg yet.
From http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/00100.html
kvm has this
Part of target-i386: Add way to expose VMWare CPUID
Also known as Paravirtualization vendor.
This change is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v=vs.85%29.aspx
Linux kernel change starts with:
Part of target-i386: Add way to expose VMWare CPUID
This is EAX and EBX data for 0x4010.
Add new #define CPUID_HV_TIMING_INFO for this.
The best documentation I have found is:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/22643
And a test under ESXi 4.0 shows that VMware is
On Fri, Oct 12, 2012 at 9:26 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 21:13, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp
Am 12.10.2012 22:43, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 9:26 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 21:13, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp lu...@laukamp.me wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri,
On Fri, Oct 12, 2012 at 3:56 PM, Lukas Laukamp lu...@laukamp.me wrote:
I think that it must be possible to create an image with a size like the
used space + a few hundret MB with metadata or something like that.
the 'best' way to do it is 'from within' the VM
the typical workaround is to
51 matches
Mail list logo
