On Fri, Nov 14, 2008 at 08:55:38AM +0800, Greg KH wrote:
On Thu, Nov 13, 2008 at 02:50:24PM +0800, Yu Zhao wrote:
On Fri, Nov 07, 2008 at 11:18:37AM +0800, Greg KH wrote:
On Fri, Nov 07, 2008 at 11:01:29AM +0800, Zhao, Yu wrote:
Currently PCI subsystem has /sys/.../{vendor,device,...}
Avi Kivity wrote:
Han, Weidong wrote:
From bba614bf2acf22f765995fb2364de04cec039226 Mon Sep 17 00:00:00
2001
From: Weidong Han [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 16:53:10 +0800
Subject: [PATCH] support VT-d device hotplug
wrap kvm_assign_device() and kvm_deassign_device() to
Avi Kivity wrote:
Michael Tokarev wrote:
A question that I asked on irc many times,
but got no answer..
Giving guest linux with CONFIG_KVM_TIME set,
is it necessary to run ntpd in it for accurate
time, or ntpd on host is sufficient?
And the same, but without CONFIG_KVM_TIME ?
In theory,
- Nitin A Kamble [EMAIL PROTECTED] wrote:
Amit, Alex,
Please see my comments bellow.
Avi,
Please have a look at the patches, and let me know the parts you
think
can be done better.
On Fri, 2008-11-14 at 06:07 -0700, Amit Shah wrote:
* On Thursday 13 Nov 2008 19:08:14
Han, Weidong wrote:
Need a KVM_CAP_ to indicate this is available.
KVM_ASSIGN_PCI_DEVICE and KVM_ASSIGN_IRQ don't need a KVM_CAP_xxx. Why do you
need it for KVM_DEASSIGN_PCI_DEVICE?
#define KVM_CAP_DEVICE_ASSIGNMENT 17
--
error compiling committee.c: too many arguments to
Long running guests on a large farm shouldn't expect to stay on the same
host they were booted on.
If they change frequently and the vendors are even matched in the farm
their chance of running fast again will be quite good. The only
worst case would be to start on one vendor, run for a
Andi Kleen wrote:
But at least for Linux, if we notify the
guest telling it to retune (which can include the vsyscall path) we can
avoid the cost entirely.
Hmm, we discussed something like this some time ago anyways (add
a way to rescan CPUID features) because there are microcode updates
Rusty Russell wrote:
On Friday 07 November 2008 18:17:54 Zhao, Yu wrote:
Greg KH wrote:
On Thu, Nov 06, 2008 at 04:40:21PM -0600, Anthony Liguori wrote:
Greg KH wrote:
On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
I don't think we really know what the One True Usage
Hello list,
I did some benchmarks over the weekend and compared
kvm-78 on a 2.6.27.4-2-default against vmware server 2.0.0-122956
Host Machine:
- Host E8400 (3GHz) 2GB RAM
- virtual machines are on iSCSI or NFS
- virtual machine is booted with -m 1024 and e1000
1. Bench
=
Does the license of the vmware server you used allow the publication of
your results?
On Mon, Nov 17, 2008 at 01:30:31PM +0100, Martin Vogt wrote:
Hello list,
I did some benchmarks over the weekend and compared
kvm-78 on a 2.6.27.4-2-default against vmware server 2.0.0-122956
Host
Avi Kivity wrote:
Han, Weidong wrote:
Need a KVM_CAP_ to indicate this is available.
KVM_ASSIGN_PCI_DEVICE and KVM_ASSIGN_IRQ don't need a KVM_CAP_xxx.
Why do you need it for KVM_DEASSIGN_PCI_DEVICE?
#define KVM_CAP_DEVICE_ASSIGNMENT 17
Do you mean add it like that:
#ifdef
Hi Everyone,
We are pleased to announce ConVirt 0.9.6. This release has some UI
improvements, feature enhancements and critical bug fixes. For more
information, please visit http://www.convirt.net.
Thanks
ConVirt Team
--
To unsubscribe from this list: send the line unsubscribe kvm
Hello Avi,
this patch should go into 2.6.28-rcx. It fixes an important guest bug.
-
From: Christian Borntraeger [EMAIL PROTECTED]
We can get an exit for instructions starting with 0xae, even if the guest is
in userspace. Lets make sure, that the signal processor handler is only called
in guest
Han, Weidong wrote:
Avi Kivity wrote:
Han, Weidong wrote:
Need a KVM_CAP_ to indicate this is available.
KVM_ASSIGN_PCI_DEVICE and KVM_ASSIGN_IRQ don't need a KVM_CAP_xxx.
Why do you need it for KVM_DEASSIGN_PCI_DEVICE?
#define KVM_CAP_DEVICE_ASSIGNMENT 17
Han, Weidong wrote:
This is how KVM_CAP_ works:
- kvm.h defines KVM_CAP_DEVICE_ASSIGNMENT
- userspace compiles device assignment code only if it sees
KVM_CAP_DEVICE_ASSIGNMENT in kvm.h
- kvm.ko returns nonzero to ioctl(KVM_CHECK_EXTENSION,
KVM_CAP_DEVICE_ASSIGNMENT) if it supports device
Don't use kvm in the tarball. It's not what you want. That's just a wrapper
that calls qemu/kvm (possibly even the system one) after it mangles some
command line options. Use qemu/x86_64-softmmu/qemu-system-x86_64 from the
tarball if you aren't going to install it. Then you just use the same
On Sun, Nov 16, 2008 at 09:57:55AM +0200, Avi Kivity wrote:
Eduardo Habkost wrote:
Hi,
This is a new spin of the series to disable vmx on kdump and on
emergency_restart. Now we avoid doing the function pointer stuff by
moving 4 small KVM functions to a header, as inline functions. The code
Eduardo Habkost wrote:
Because of their location, I thought svm.h and vmx.h had KVM-specific
code. Now I've noticed they are independent from KVM. May I move svm.h
and vmx.h to arch/x86/include/asm, then?
Indeed the intent was to have these as hardware descriptions rather than
bits of
Hey Jd,
On 14.11.2008, at 04:07, jd wrote:
Hi Alex
Hope your tooth op went smoothly.
Did u get a chance to put up your new version of the nested KVM
patch ?
I'm still working on it. I'll post a new version this week that I'll
try to accelerate a bit further.
I am on KVM-70... can
This function can be used by the reboot or kdump code to forcibly
disable SVM on the CPU.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/virtext.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/virtext.h
Unfortunately we can't use exactly the same code from vmx
hardware_disable(), because the KVM function uses the
__kvm_handle_fault_on_reboot() tricks.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/virtext.h | 15 +++
1 files changed, 15 insertions(+), 0
svm.h will be used by core code that is independent of KVM, so I am
moving it outside the arch/x86/kvm directory.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/svm.h | 328
arch/x86/kvm/kvm_svm.h |2 +-
On emergency_restart, we may need to use an NMI to disable virtualization
on all CPUs. We do that using nmi_shootdown_cpus() if VMX is enabled.
Note: With this patch, we will run the NMI stuff only when the CPU where
emergency_restart() was called has VMX enabled. This should work on most
cases
Hi, Ingo,
This is yet another spin of the series to disable vmx on kdump and on
emergency_restart, after some feedback from Avi.
The only change from v3 is that vmx.h and svm.h were moved from
arch/x86/kvm to arch/x86/include/asm, instead of moving code
from those headers to asm/virtext.h.
I
Add cpu_emergency_vmxoff() and its friends: cpu_vmx_enabled() and
__cpu_emergency_vmxoff().
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/virtext.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git
Create cpu_svm_disable() function.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/virtext.h | 14 ++
arch/x86/kvm/svm.c |6 +-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/virtext.h
Use a trick to keep the printk()s on has_svm() working as before. gcc
will take care of not generating code for the 'msg' stuff when the
function is called with a NULL msg argument.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/virtext.h | 41
Along with some comments on why it is different from the core cpu_vmxoff()
function.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/kvm/vmx.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
We need to disable virtualization extensions on all CPUs before booting
the kdump kernel, otherwise the kdump kernel booting will fail, and
rebooting after the kdump kernel did its task may also fail.
We do it using cpu_emergency_vmxoff() and cpu_emergency_svm_disable(),
that should always work,
Those definitions will be used by code outside KVM, so move it outside
of a KVM-specific source file.
Those definitions are used only on kvm/vmx.c, that already includes
asm/vmx.h, so they can be moved safely.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/kvm_host.h
vmx.h will be used by core code that is independent of KVM, so I am
moving it outside the arch/x86/kvm directory.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/vmx.h | 359
arch/x86/kvm/mmu.c |2 +-
It will be used by core code on kdump and reboot, to disable
vmx if needed.
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
arch/x86/include/asm/virtext.h | 31 +++
arch/x86/kvm/vmx.c |4 ++--
2 files changed, 33 insertions(+), 2 deletions(-)
Jan Kiszka [EMAIL PROTECTED] writes:
[...]
To summarize the contributions of this series (+ its related kernel
bits):
- fully functional guest debugging via gdbstub,
including hardware breakpoints and watchpoints
(pick up current gdb cvs to have hbreak via remote gdb)
- (Almost)
On Sun, 2008-11-16 at 05:26 -0800, Avi Kivity wrote:
Kamble, Nitin A wrote:
The capability itself can return the count; for example
case KVM_CAP_NR_CPUID_LEAVES:
return KVM_MAX_CPUID_ENTRIES;
which is simpler to use and shorter.
Avi,
Yes, it is simpler and shorter,
Currently, kvm only sets new.userspace_addr in slots
that were just allocated. This is not the intended behaviour,
and actually breaks when we try to use the slots to implement
aliases, for example.
Cirrus VGA aliases maps and address to a userspace address, and
then keep mapping this same
Avi Kivity wrote:
Han, Weidong wrote:
This is how KVM_CAP_ works:
- kvm.h defines KVM_CAP_DEVICE_ASSIGNMENT
- userspace compiles device assignment code only if it sees
KVM_CAP_DEVICE_ASSIGNMENT in kvm.h
- kvm.ko returns nonzero to ioctl(KVM_CHECK_EXTENSION,
KVM_CAP_DEVICE_ASSIGNMENT) if
36 matches
Mail list logo
