RE: [PATCH 4/4] KVM: Device assignemnt with VT-d
Ben-Ami Yassour wrote:
> From: Kay, Allen M <[EMAIL PROTECTED]>
>
> This patch includes the functions to support VT-d for passthrough
> devices.
>
> [Ben: fixed memory pinning, cleanup]
>
> Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
> Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
> Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
> ---
> arch/x86/kvm/Makefile |2 +-
> arch/x86/kvm/vtd.c | 182
> arch/x86/kvm/x86.c
> | 11 +++ include/asm-x86/kvm_host.h |3 +
> include/linux/kvm_host.h |6 ++
> virt/kvm/kvm_main.c|8 ++-
> 6 files changed, 210 insertions(+), 2 deletions(-)
> create mode 100644 arch/x86/kvm/vtd.c
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 5b470a1..49c4ed3 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -76,7 +77,7 @@ static inline int valid_vcpu(int n)
> return likely(n >= 0 && n < KVM_MAX_VCPUS);
> }
>
> -static inline int is_mmio_pfn(pfn_t pfn)
> +inline int is_mmio_pfn(pfn_t pfn)
> {
> if (pfn_valid(pfn))
> return PageReserved(pfn_to_page(pfn));
I cannot find this is_mmio_pfn() definition on main KVM tree, and failed
to patch it.
Randy (Weidong)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Device Paravirtualization
The second revision of PV NIC for Windows is on the KVM Source Forge site: http://sourceforge.net/project/showfiles.php?group_id=180599 Dave Waters -Original Message- From: Sukanto Ghosh <[EMAIL PROTECTED]> Sent: Monday, July 28, 2008 12:47 AM To: kvm@vger.kernel.org Subject: Device Paravirtualization As device paravirtualization requires a modified device driver (PV driver) in the guest, which is aware about the hypervisor, can this be done for proprietary OSs by writing a device driver for them and then installing it in the guest OS ? If yes, has it been done for Windows guests so far ? -- Regards, Sukanto Ghosh -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9][RFC] KVM virtio_net performance
On Sun, 2008-07-27 at 09:17 -0400, Bill Davidsen wrote:
> Avi Kivity wrote:
> > Bill Davidsen wrote:
> >>
> >> I have been discussing this (on this list) in another thread. Putting
> >> tcpdump on the eth0 device in the VM, the br0 device in the host, and
> >> the eth0 (physical NIC) in the host, you can see that when the VM
> >> generates a DHCP request it shows up on the br0 in the host, but
> >> never gets sent on the wire by eth0.
> >>
> >> That's the point of failure, at least using RHEL5/FC6/kvm-66 as the
> >> environment.
> >
> > Does playing with the bridge forward delay ('brctl setfd') help?
> >
> Update: Redhat has a user chain in iptables shared between INPUT and
> FORWARD (bad idea) which doesn't pass bootp packets by default.
Yeah, I've been trying to get that rule changed to allow all bridged
packets to be forwarded by default. See:
https://bugzilla.redhat.com/221828
> Adding
> the following rules to that table solved the DHCP for me.
>
> ACCEPT udp -- anywhere anywhereudp
> spt:bootps dpt:bootpc
> ACCEPT udp -- anywhere anywhereudp
> spt:bootpc dpt:bootps
>
> This seems to solve my problem, I just have to make it part of my "start
> kvm" procedure.
See here:
http://wiki.libvirt.org/page/Networking
in the 'Bridged networking (aka "shared physical device")' section:
# echo "-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT" >
/etc/sysconfig/iptables-forward-bridged
# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged
# service libvirtd reload
Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to run KVM on non-X environment
On Mon, 28 Jul 2008 13:18:32 +0800, Stephen Liu wrote: > > On running > # kvm -m 750 -cdrom /dev/scd0 -boot d ubuntu6.06.img add -vnc : or disable graphics completly (see kvm --help) - Thomas -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Device Paravirtualization
Thanks Dave On Mon, Jul 28, 2008 at 12:04 PM, Dave Waters <[EMAIL PROTECTED]> wrote: > The second revision of PV NIC for Windows is on the KVM Source Forge site: > > http://sourceforge.net/project/showfiles.php?group_id=180599 > > Dave Waters > > -Original Message- > From: Sukanto Ghosh <[EMAIL PROTECTED]> > Sent: Monday, July 28, 2008 12:47 AM > To: kvm@vger.kernel.org > Subject: Device Paravirtualization > > As device paravirtualization requires a modified device driver (PV > driver) in the guest, which is aware about the hypervisor, can this be > done for proprietary OSs by writing a device driver for them and then > installing it in the guest OS ? > > If yes, has it been done for Windows guests so far ? > > -- > Regards, > Sukanto Ghosh > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- Regards, Sukanto Ghosh -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2019608 ] Ubuntu 8.04.1 (IA32 && x86_64) - cannot install bootloader
Bugs item #2019608, was opened at 2008-07-16 15:03 Message generated for change (Comment added) made by awwy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2019608&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: intel Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Truschnigg (c0l0) Assigned to: Nobody/Anonymous (nobody) Summary: Ubuntu 8.04.1 (IA32 && x86_64) - cannot install bootloader Initial Comment: CPU: Intel Core 2 Quad Q6600 (4 cores) Distro, kernel: Gentoo GNU/Linux ~amd64, Kernel 2.6.25-r6 Bitness, compiler: x86_64, GCC 4.3.1 KVM versions: kvm-70, kvm-71 When trying to install Ubuntu) either 32bit or 64bit) in a KVM guest, grub-install croaks with. The guest kernel debug ringbuffer shows the following messages: (Please see http://pasted.at/9d7e95f873.html or the attached file!) Windows XP also hangs at installing, actually before anthing substantial other than copying installation files gets done. The first phase of the install completes, however - the "graphical installer" that's started after the first reboot hangs indefinitely. Worked fine with version <= kvm-69 with the very same settings. I'm happy to provide additional information upon request. -- Comment By: Alexander Graf (awwy) Date: 2008-07-28 06:34 Message: Logged In: YES user_id=376328 Originator: NO Ok this is SYSENTER, so things _should_ work actually: The address we're faulting in is: Pid: 1, comm: grub Not tainted 2.6.16.60-0.21-default #1 RIP: 0010:[<8011c8fc>] [<8011c8fc>] Looking at the same address extended by 0x gives us: (gdb) x /i 0x8011c8fc 0x8011c8fc : swapgs when I break at the wrong address (gdb) b *0x8011c8fc Breakpoint 1 at 0x8011c8fc The breakpoint jumps in in long mode: (qemu) info registers RAX=0024 RBX=f7ee1ff4 RCX=fff985f0 RDX=0001 RSI= RDI=fff98674 RBP=fff985ac RSP= R8 = R9 = R10= R11=0200 R12= R13= R14= R15= RIP=8011c8fc RFL=0022 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 but has this really weird IP. Shouldn't SYSENTER be completely handled by VMX? -- Comment By: Alexander Graf (awwy) Date: 2008-07-25 11:53 Message: Logged In: YES user_id=376328 Originator: NO The address we're seeing the fault in actually belongs to SYSCALL. When I remove the SYSCALL capability from the reportedly supported bits and run the VM with -no-kvm, I receive #UD exceptions. Apparently something calls SYSCALL even if it's not supported. -- Comment By: Alexander Graf (awwy) Date: 2008-07-24 13:36 Message: Logged In: YES user_id=376328 Originator: NO I bisected it down to commit cc91437d10770328d0b32f200399569a0ad22792, which lies between kvm-60 and kvm-61. I can't really make out any obvious problem that patch may rise though. Nevertheless it seems to be userspace in fault here. -- Comment By: Alexander Graf (awwy) Date: 2008-07-24 05:56 Message: Logged In: YES user_id=376328 Originator: NO I am getting exactly the same error on SLES10 SP2. Running a 32-bit binary in an x86_64 SLES10SP2 guest generates a #DF on a RIP, that looks like a 32-bit mangled kernel space address (80228ca0 vs. 80228ca0). Apparently something truncates it - I'll try to bisect. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2019608&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] KVM: PIT: fix injection logic and count
Hi Marcelo Thanks for your work! It finally reslove my problem on failing to ack some injected interrupts. :) On Sunday 27 July 2008 04:01:01 Marcelo Tosatti wrote: > The PIT injection logic is problematic under the following cases: > > 1) If there is a higher priority vector to be delivered by the time > kvm_pit_timer_intr_post is invoked ps->inject_pending won't be set. > This opens the possibility for missing many PIT event injections > (say if guest executes hlt at this point). IRQ ack is of course the better way. But I am still confuse about why PIT event lost. If higher priority vector there, it would inject first, but finally PIT one should be injected and because PIT inject one interrupt after another had been injected, so no PIT interrupt should be ignored. > > 2) ps->inject_pending is racy with more than two vcpus. Since > there's no locking around read/dec of pt->pending, two vcpu's can > inject two interrupts for a single pt->pending count. > > Fix 1 by using an irq ack notifier: only reinject when the previous > irq has been acked. Fix 2 with appropriate locking around > manipulation of pending count and irq_ack by the injection / ack > paths. > > Also, count_load_time should be set at the time the count is > reloaded, not when the interrupt is injected (BTW, LAPIC uses the > same apparently broken scheme, could someone explain what was the > reasoning behind that? kvm_apic_timer_intr_post). PIT did so because we don't know how long we should wait for interrupt injection, so that point is nearer the real injection point. I think lapic have the similar reason. I think keep timer_intr_post() for time update is reasonable. -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
How to run KVM on non-X environment
Hi folks, Ubuntu 8.04 server amd64, headless KVM 1:62+dfsg QEMU 0.9.1 OpenSSH 1:4.7p1 On running # kvm -m 750 -cdrom /dev/scd0 -boot d ubuntu6.06.img ===| DirectFB 1.0.1 |=== (c) 2001-2007 The DirectFB Organization (directfb.org) (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2008-04-08 15:15) (*) Direct/Memcpy: Using libc memcpy() (!) Direct/Util: opening '/dev/fb0' and '/dev/fb/0' failed --> No such file or directory (!) DirectFB/FBDev: Error opening framebuffer device! (!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable. (!) DirectFB/Core: Could not initialize 'system' core! --> Initialization error! Could not initialize SDL - exiting Please advise how to fix the problem. TIA B.R. Stephen L Send instant messages to your online friends http://uk.messenger.yahoo.com -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Device Paravirtualization
As device paravirtualization requires a modified device driver (PV driver) in the guest, which is aware about the hypervisor, can this be done for proprietary OSs by writing a device driver for them and then installing it in the guest OS ? If yes, has it been done for Windows guests so far ? -- Regards, Sukanto Ghosh -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] fix PIT injection
Hi Marcelo: With kvm-72 + this patch set, timekeeping in RHEL3, RHEL4 and RHEL5 guests with 2 vcpus is much better. Approaching 5 hours of uptime and all 3 guests are within 2 seconds of the host (part of the delta measurement based). I'll let all 3 run overnight and then turn on ntp tomorrow. Thanks for working on this, david Marcelo Tosatti wrote: > The in-kernel PIT emulation can either inject too many or too few > interrupts. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ANNOUNCE] kvm-72 release
On Monday, July 28, 2008 11:11 AM [EMAIL PROTECTED] wrote: > On Sun, Jul 27, 2008 at 7:11 PM, Xavier Gnata > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> kvm-72 does not compile with 2.6.26 kernels ( x86-64bits): >> >> ./configure && make gives : >> >> /usr/local/src/kvm-72/kernel/anon_inodes.c: In function >> 'kvm_anon_inode_getfd': >> /usr/local/src/kvm-72/kernel/anon_inodes.c:254: error: too many >> arguments to function 'anon_inode_getfd' > > I'm having the exact same problem, using a 2.6.26 64-bit > kernel as well. The problem also exists with 2.6.26 32-bit kernel. Best Regards Jiajun -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-72 release
On Sun, Jul 27, 2008 at 7:11 PM, Xavier Gnata <[EMAIL PROTECTED]> wrote: > Hi, > > kvm-72 does not compile with 2.6.26 kernels ( x86-64bits): > > ./configure && make gives : > > /usr/local/src/kvm-72/kernel/anon_inodes.c: In function > 'kvm_anon_inode_getfd': > /usr/local/src/kvm-72/kernel/anon_inodes.c:254: error: too many arguments to > function 'anon_inode_getfd' I'm having the exact same problem, using a 2.6.26 64-bit kernel as well. Cheers, Jorge -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 and PXE issues
The default rtl8139 seems to work for me, but granted it doesn't respond right away. It takes it about 8-10 seconds to figure stuff out. Also the rtl8139 seems to only come up as half duplex for me (not sure if that is related, but worth mentioning). I just tested kvm-72, and that doesn't fix the bug (not a big surprise considering there was nothing mentioned in the changelog regarding PXE fixups) but worth noting. Thanks everyone! Greg On Sun, Jul 27, 2008 at 10:32 AM, Farkas Levente <[EMAIL PROTECTED]> wrote: > Greg Kurtzer wrote: >> >> On Sat, Jul 26, 2008 at 1:12 AM, Avi Kivity <[EMAIL PROTECTED]> wrote: >>> >>> Greg Kurtzer wrote: Hello, I noticed some problems with the e1000 implementation in kvm >= 70. At first glance it seemed liked a PXE problem as it would not acknowledge the DHCP offer from the server. I tried several different Etherboot ROM images and version 5.2.6 seemed to work. That version isn't PXE compliant so I built an ELF image to boot, and it downloaded it very, very, very, very slowly (as in about 10 minutes) but it did end up working. This all worked perfectly with version 69 and previous. >>> There are two patches to e1000 in kvm-70; can you try backing them out >>> (patch -Rp1 < test.patch) to see which one is guilty? >>> >>> Candidates attached. >> >> Reverted both of these patches yet the problem remains. :( >> >> This is easy to reproduce (at least on my build). if there is a DHCP >> server on the network, just do a network boot on the e1000. It makes a >> correct DHCPDISCOVER, but never responds to the DHCPOFFER (it should >> do a DHCPREQUEST next). No packets are getting lost according tcpdump >> on the master. >> >> The console is showing: >> >> Probing pci nic... >> [e1000-82540em]Ethernet addr: 00:04:21:DE:99:55 >> Searching for server (DHCP)No IP address >> .No IP address >> .No IP address >> .No IP address >> .No IP address >> .No IP address >> .No IP address >> ... > > the same happend with us both with e1000 and rtl8139 driver and the rh guy > said it's not a virt-manager problem... > currently we're not able to pxe boot any kind of kvm guest with any network > driver:-( > > -- > Levente "Si vis pacem para bellum!" > -- Greg Kurtzer http://www.infiscale.com/ http://www.runlevelzero.net/ http://www.perceus.org/ http://www.caoslinux.org/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] LTTng merge plan
* Avi Kivity ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers wrote: > > >>> Yes, but the userspace side would collect the format strings as well >>> (just once) and could put them in the same file. The aggregation is >>> portable across kernel versions. >>> >>> >> >> Yes, >> >> LTTng does exactly all that. >> >> >> > > [snip goodies] > >> I'll be more than happy to answer your questions. >> > > What's the merge plan for this? > Hi Avi, Thanks for asking. Given the amount of expectation from kernel developers, distributions and users I have seen for kernel tracing at this year's OLS, I think giving a detailed merge plan for my LTTng work is appropriate. Currently, it looks like : In Ingo's trees : - Tracepoints, scheduler tracepoints instrumentation, ftrace port to tracepoints - Should make it into 2.6.27 since ftrace needs those. - Immediate Values (faster branch based on load immediate instruction) Useful for markers and tracepoints, but can also be used for any compiled-in code that has to be dynamically enabled. - Aims at 2.6.28 - Text Edit Lock : protection of kernel text modification with a mutex. Synchronises kprobes and immediate values. - Aims at 2.6.28 Short-term submission plan In LTTng patchset (http://ltt.polymtl.ca/lttng/patch-2.6.26-0.12.tar.bz2) - Instrumentation - LTTng tracepoints - Used by LTTng, SystemTAP and usable specialized probes. - Port specific sets of tracepoints along with their current users - ftrace (port currently in Ingo's tree), KVM trace, blktrace. - Data extraction - LTTng timestamping - Based on the CPU cycle counter when synchronized across CPUs. - Fallback on a simple cache-bouncing atomic counter if no synchronized fast time source is available. Basically, the idea is that having the correct event _order_ is more important than having an approximate time, because this "timestamp" is used to reorder events which are written in per-CPU buffers. Time updates can always be recorded as an event in the trace to get an idea of the kernel time flow. - LTTng trace management - netlink interface to start/stop tracing and set the buffer sizes. - Supports multiple channels (high/medium/low event rate). Metadata (marker types, list of interrupt handlers...) can be exported in low event rate channels. - Supports flight recorder mode (overwriting oldest buffer data), normal mode (writes to disk, drops events if buffer is full) or hybrid, or mixed, mode, where the high event rate buffers only are in flight recorder mode. - Data relay - Atomic buffering mechanism which does not call into kernel primitives except preempt disable. Only touches variables atomically, does not use any lock. Aims at having minimal intrusiveness and allowing the largest code coverage (thus not calling kernel code). - LTTng marker control - Currently a /proc/ltt interface with read and write operations to list markers and connect LTTng probe to individual markers, specifying in which channel to send the data (I know, should probably belong to /sys instead, comments welcome) It's not part of the core marker infrastructure because it depends both on markers and on the LTTng trace management. It's also responsible for allocating a numeric ID to a marker which is guaranteed to be unique as long as there is at least one active trace. Medium-term submission plan In LTTng patchset - Instrumentation - Userspace tracing interface - Allow userspace to declare tracepoints and/or markers - Provide a data extraction interface to collect the tracing data. - More work needed in this area. - LTTng statedump - Exports the kernel data structures to the trace buffers at trace start. List interrupts, system calls, threads, memory maps, ... It does not use /proc because : 1 - /proc has nasty races which makes the information "generally correct" but not more. 2 - /proc exports the information in text format, which is not as compact as LTTng binary format. Longer term wishlist - GCC support for static branch patching - Improvement on the immediate values for dynamic code activation A bit more information is available in the slides I just presented at OLS at : http://ltt.polymtl.ca/slides/desnoyers-talk-ols2008.pdf I'll gladly answer to questions/comments. Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 1/2] Simulate Intel cpufreq MSRs in kvm guests to influencenice priority
>From: Avi Kivity [mailto:[EMAIL PROTECTED] >Sent: 2008年7月27日 16:27 > >Tian, Kevin wrote: >>> From: Darrick J. Wong >>> Sent: 2008年7月16日 7:18 >>> >>> I envision four scenarios: >>> >>> 0. Guests that don't know about cpufreq still run at whatever >>> nice level >>> they started with. >>> >>> 1. If we have a system with a lot of idle VMs, they will all >>> run with +5 >>> nice and this patch has no effect. >>> >>> 2. If we have a system with a lot of busy VMs, they all run >>> with -5 nice >>> and this patch also has no effect. >>> >>> 3. If, however, we have a lot of idle VMs and a few busy >ones, then the >>> -5 nice of the busy VMs will get those VMs extra CPU time. >On a really >>> crummy FPU microbenchmark I have, the score goes from about >500 to 2000 >>> with the patch applied, though of course YMMV. In some >respects this >>> >> >> How many VMs did you run in this test? All the VMs are idle except >> the one where your benchmark runs? >> >> How about the actual effect when several VMs are doing some stuff? >> >> There's another scenario where some VMs don't support cpufreq while >> others do. Here is it unfair to just renice the latter when >the former is >> not 'nice' at all? >> > >I guess the solution for such issues is not to have kvm (or qemu) play >with nice levels, but instead send notifications on virtual frequency >changes on the qemu monitor. The management application can then choose >whether to ignore the information, play with nice levels, or even >propagate the frequency change to the host (useful in client-side >virtualization). > Yes, that'd be more flexible and cleaner. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-72 release
There is a boot regression in kvm-72: scsi and virtio images will not survive a "reboot" from within the guest. Only drives with if=ide survives a rebooting of the guest. That is, this will create a guest that will survive any number of reboots: qemu-system-x86_64 -M -drive file=a,if=ide,media=disk,boot=on -boot c While this will only survive the first boot: qemu-system-x86_64 -M -drive file=a,if=scsi,media=disk,boot=on -boot c OR qemu-system-x86_64 -M -drive file=a,if=virtio,media=disk,boot=on -boot c Also the extboot work done by H. Peter Anvin finally makes the newer isolinux menus to work but the older isolinux (for example the installer to ubuntu 7.10) still does not work. It no longer segfaults though but instead the guest completely hangs. Much improvement though! /Henrik Holst -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-72 release
Hi, kvm-72 does not compile with 2.6.26 kernels ( x86-64bits): ./configure && make gives : /usr/local/src/kvm-72/kernel/anon_inodes.c: In function ‘kvm_anon_inode_getfd’: /usr/local/src/kvm-72/kernel/anon_inodes.c:254: error: too many arguments to function ‘anon_inode_getfd’ Were does this "int flag" come from ?? Xavier The most noticeable change in this release, by far, is the removal of the QEMU/KVM annotation on the qemu window in favor of a new 'info kvm' monitor command. If you dig deeper, you will see improved stability for Windows guests, especially x64 variants. Changes from kvm-71: - fix ia64 build breakage (Xiantao Zhang) - ppc kvmtrace support (Christian Ehrhardt) - merge qemu-svn - fixes suspend/resume of multiple nics - adds Virtual Distributed Ethernet (vde) support - add 'push mem' to patched tpr instructions - use host kernel anon_inodes support if available - robustify signalfd() emulation - avoid losing the iothread on random signals - fix test for iothread (Jan Kiszka) - remove hypercall device (Anthony Liguori) - remove duplicate monitor command (Anthony Liguori) - remove unused function declaration (Anthony Liguori) - remove unnecessary change to TARGET_PAGE_SIZE (Anthony Liguori) - remove qemu/kvm application decoration (Anthony Liguori) - add 'info kvm' monitor command (Anthony Liguori) - s390 libkvm port (Carsten Otte) - fix compile warning (Carlo Marcelo Arenas Belon) - fix duplicate #include (Carlo Marcelo Arenas Belon) - adjust external module for 2.6.27 hosts - avoid tpr patching when the stack is not valid (Marcelo Tosatti) - fixes some variant of Windows 2003 SMP - fix extboot stomping on reserved interrupt vectors (H. Peter Anvin) - remove unused -translation option (Anthony Liguori) - fix preemption during copy_from_user_inatomic() on older hosts (Andrea Arcangeli) - fix ppc cpu initialization (Hollis Blanchard) - drop shadow ptes on memslot destruction (Marcelo Tosatti) - improve invalid shadow root page table handling (Marcelo Tosatti) - simplify mmu page zapping - simplify interrupt processing on Intel - remove redundant check for real mode (Mohammed Gamal) - add clflush emulation (Glauber Costa) - fix race setting shadow ptes on i386 - consolidate pic isr clearing into a function - consolidate exception interrupt vector #defines (Jan Kiszka) - fix interrupt reinjection in real mode (Jan Kiszka) - unify guest register save/restore code - x86 hardware task switching fixes (Marcelo Tosatti) - optimize vmx by avoiding saving the host stack pointer - fix interrupts being delayed by instruction emulation - improves Vista stability - fix reloading kvm-intel.ko while changing parameters (Sheng Yang) - fix reboot exception entry build bug (Ingo Molnar) - ignore no-op DEBUGCTL msr writes (Alexander Graf) - fixes Netware - fix irq state leak on ia64 (Julia Lawall) - s390 fixes (Carsten Otte, Christian Borntraeger, Martin Schwidefsky) - ppc guest breakpoint support (Hollis Blanchard) - optimize ppc by not saving host tlb state (Hollis Blanchard) - reduce ppc guest tlb writes (Hollis Blanchard) - avoid guest tlb flushes on guest privilege switches (Hollis Blanchard) Notes: If you use the modules bundled with kvm-72, you can use any version of Linux from 2.6.16 upwards. You may also use kvm-72 userspace with the kvm modules provided by Linux 2.6.22 or above. Some features may only be available in newer releases. http://kvm.qumranet.com -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 and PXE issues
Greg Kurtzer wrote: On Sat, Jul 26, 2008 at 1:12 AM, Avi Kivity <[EMAIL PROTECTED]> wrote: Greg Kurtzer wrote: Hello, I noticed some problems with the e1000 implementation in kvm >= 70. At first glance it seemed liked a PXE problem as it would not acknowledge the DHCP offer from the server. I tried several different Etherboot ROM images and version 5.2.6 seemed to work. That version isn't PXE compliant so I built an ELF image to boot, and it downloaded it very, very, very, very slowly (as in about 10 minutes) but it did end up working. This all worked perfectly with version 69 and previous. There are two patches to e1000 in kvm-70; can you try backing them out (patch -Rp1 < test.patch) to see which one is guilty? Candidates attached. Reverted both of these patches yet the problem remains. :( This is easy to reproduce (at least on my build). if there is a DHCP server on the network, just do a network boot on the e1000. It makes a correct DHCPDISCOVER, but never responds to the DHCPOFFER (it should do a DHCPREQUEST next). No packets are getting lost according tcpdump on the master. The console is showing: Probing pci nic... [e1000-82540em]Ethernet addr: 00:04:21:DE:99:55 Searching for server (DHCP)No IP address .No IP address .No IP address .No IP address .No IP address .No IP address .No IP address ... the same happend with us both with e1000 and rtl8139 driver and the rh guy said it's not a virt-manager problem... currently we're not able to pxe boot any kind of kvm guest with any network driver:-( -- Levente "Si vis pacem para bellum!" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-72 release
Avi Kivity wrote:
The most noticeable change in this release, by far, is the removal of
the QEMU/KVM annotation on the qemu window in favor of a new 'info
kvm' monitor command. If you dig deeper, you will see improved
stability for Windows guests, especially x64 variants.
Changes from kvm-71:
- fix ia64 build breakage (Xiantao Zhang)
- ppc kvmtrace support (Christian Ehrhardt)
- merge qemu-svn
- fixes suspend/resume of multiple nics
- adds Virtual Distributed Ethernet (vde) support
- add 'push mem' to patched tpr instructions
- use host kernel anon_inodes support if available
- robustify signalfd() emulation
- avoid losing the iothread on random signals
- fix test for iothread (Jan Kiszka)
- remove hypercall device (Anthony Liguori)
- remove duplicate monitor command (Anthony Liguori)
- remove unused function declaration (Anthony Liguori)
- remove unnecessary change to TARGET_PAGE_SIZE (Anthony Liguori)
- remove qemu/kvm application decoration (Anthony Liguori)
- add 'info kvm' monitor command (Anthony Liguori)
- s390 libkvm port (Carsten Otte)
- fix compile warning (Carlo Marcelo Arenas Belon)
- fix duplicate #include (Carlo Marcelo Arenas Belon)
- adjust external module for 2.6.27 hosts
- avoid tpr patching when the stack is not valid (Marcelo Tosatti)
- fixes some variant of Windows 2003 SMP
- fix extboot stomping on reserved interrupt vectors (H. Peter Anvin)
- remove unused -translation option (Anthony Liguori)
- fix preemption during copy_from_user_inatomic() on older hosts
(Andrea Arcangeli)
- fix ppc cpu initialization (Hollis Blanchard)
- drop shadow ptes on memslot destruction (Marcelo Tosatti)
- improve invalid shadow root page table handling (Marcelo Tosatti)
- simplify mmu page zapping
- simplify interrupt processing on Intel
- remove redundant check for real mode (Mohammed Gamal)
- add clflush emulation (Glauber Costa)
- fix race setting shadow ptes on i386
- consolidate pic isr clearing into a function
- consolidate exception interrupt vector #defines (Jan Kiszka)
- fix interrupt reinjection in real mode (Jan Kiszka)
- unify guest register save/restore code
- x86 hardware task switching fixes (Marcelo Tosatti)
- optimize vmx by avoiding saving the host stack pointer
- fix interrupts being delayed by instruction emulation
- improves Vista stability
- fix reloading kvm-intel.ko while changing parameters (Sheng Yang)
- fix reboot exception entry build bug (Ingo Molnar)
- ignore no-op DEBUGCTL msr writes (Alexander Graf)
- fixes Netware
- fix irq state leak on ia64 (Julia Lawall)
- s390 fixes (Carsten Otte, Christian Borntraeger, Martin Schwidefsky)
- ppc guest breakpoint support (Hollis Blanchard)
- optimize ppc by not saving host tlb state (Hollis Blanchard)
- reduce ppc guest tlb writes (Hollis Blanchard)
- avoid guest tlb flushes on guest privilege switches (Hollis Blanchard)
Notes:
If you use the modules bundled with kvm-72, you can use any version
of Linux from 2.6.16 upwards. You may also use kvm-72 userspace with
the kvm modules provided by Linux 2.6.22 or above. Some features may
only be available in newer releases.
http://kvm.qumranet.com
It looks like the audio driver/card selection via ./configure is still
broken.
This set of patches does the job with kvm-71 :
"[PATCH 1/2] configure: include audio list options for --help output"
und
"[PATCH 0/2] configure: add support for audio-{drv,card}-list"
Xavier
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] kvm-72 release
The most noticeable change in this release, by far, is the removal of the QEMU/KVM annotation on the qemu window in favor of a new 'info kvm' monitor command. If you dig deeper, you will see improved stability for Windows guests, especially x64 variants. Changes from kvm-71: - fix ia64 build breakage (Xiantao Zhang) - ppc kvmtrace support (Christian Ehrhardt) - merge qemu-svn - fixes suspend/resume of multiple nics - adds Virtual Distributed Ethernet (vde) support - add 'push mem' to patched tpr instructions - use host kernel anon_inodes support if available - robustify signalfd() emulation - avoid losing the iothread on random signals - fix test for iothread (Jan Kiszka) - remove hypercall device (Anthony Liguori) - remove duplicate monitor command (Anthony Liguori) - remove unused function declaration (Anthony Liguori) - remove unnecessary change to TARGET_PAGE_SIZE (Anthony Liguori) - remove qemu/kvm application decoration (Anthony Liguori) - add 'info kvm' monitor command (Anthony Liguori) - s390 libkvm port (Carsten Otte) - fix compile warning (Carlo Marcelo Arenas Belon) - fix duplicate #include (Carlo Marcelo Arenas Belon) - adjust external module for 2.6.27 hosts - avoid tpr patching when the stack is not valid (Marcelo Tosatti) - fixes some variant of Windows 2003 SMP - fix extboot stomping on reserved interrupt vectors (H. Peter Anvin) - remove unused -translation option (Anthony Liguori) - fix preemption during copy_from_user_inatomic() on older hosts (Andrea Arcangeli) - fix ppc cpu initialization (Hollis Blanchard) - drop shadow ptes on memslot destruction (Marcelo Tosatti) - improve invalid shadow root page table handling (Marcelo Tosatti) - simplify mmu page zapping - simplify interrupt processing on Intel - remove redundant check for real mode (Mohammed Gamal) - add clflush emulation (Glauber Costa) - fix race setting shadow ptes on i386 - consolidate pic isr clearing into a function - consolidate exception interrupt vector #defines (Jan Kiszka) - fix interrupt reinjection in real mode (Jan Kiszka) - unify guest register save/restore code - x86 hardware task switching fixes (Marcelo Tosatti) - optimize vmx by avoiding saving the host stack pointer - fix interrupts being delayed by instruction emulation - improves Vista stability - fix reloading kvm-intel.ko while changing parameters (Sheng Yang) - fix reboot exception entry build bug (Ingo Molnar) - ignore no-op DEBUGCTL msr writes (Alexander Graf) - fixes Netware - fix irq state leak on ia64 (Julia Lawall) - s390 fixes (Carsten Otte, Christian Borntraeger, Martin Schwidefsky) - ppc guest breakpoint support (Hollis Blanchard) - optimize ppc by not saving host tlb state (Hollis Blanchard) - reduce ppc guest tlb writes (Hollis Blanchard) - avoid guest tlb flushes on guest privilege switches (Hollis Blanchard) Notes: If you use the modules bundled with kvm-72, you can use any version of Linux from 2.6.16 upwards. You may also use kvm-72 userspace with the kvm modules provided by Linux 2.6.22 or above. Some features may only be available in newer releases. http://kvm.qumranet.com -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9][RFC] KVM virtio_net performance
Avi Kivity wrote:
Bill Davidsen wrote:
I have been discussing this (on this list) in another thread. Putting
tcpdump on the eth0 device in the VM, the br0 device in the host, and
the eth0 (physical NIC) in the host, you can see that when the VM
generates a DHCP request it shows up on the br0 in the host, but
never gets sent on the wire by eth0.
That's the point of failure, at least using RHEL5/FC6/kvm-66 as the
environment.
Does playing with the bridge forward delay ('brctl setfd') help?
Update: Redhat has a user chain in iptables shared between INPUT and
FORWARD (bad idea) which doesn't pass bootp packets by default. Adding
the following rules to that table solved the DHCP for me.
ACCEPT udp -- anywhere anywhereudp
spt:bootps dpt:bootpc
ACCEPT udp -- anywhere anywhereudp
spt:bootpc dpt:bootps
This seems to solve my problem, I just have to make it part of my "start
kvm" procedure.
--
Bill Davidsen <[EMAIL PROTECTED]>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9][RFC] KVM virtio_net performance
Avi Kivity wrote:
Bill Davidsen wrote:
Anthony Liguori wrote:
Hi Mark,
[...snip...]
I'm still seeing the same problem I saw with my patch series.
Namely, dhclient fails to get a DHCP address. Rusty noticed that RX
has a lot more packets received then it should so we're suspicious
that we're getting packet corruption.
I have been discussing this (on this list) in another thread. Putting
tcpdump on the eth0 device in the VM, the br0 device in the host, and
the eth0 (physical NIC) in the host, you can see that when the VM
generates a DHCP request it shows up on the br0 in the host, but
never gets sent on the wire by eth0.
That's the point of failure, at least using RHEL5/FC6/kvm-66 as the
environment.
Does playing with the bridge forward delay ('brctl setfd') help?
Not obviously, default value is 15, stepping from 10..30 made no
difference. It appears the bridge just doesn't forward DHCP packets. I'm
not an expert on bridge setup, and I don't see an obvious control, so I
will look at the code this afternoon and see if something jumps out at me.
--
Bill Davidsen <[EMAIL PROTECTED]>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] KVM fixes for 2.6.27-rc
Linus, please pull from repo & branch at git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git kvm-updates-2.6.27 which contains fixes for 2.6.27's KVM. These include an interrupt injection fix, corrections for the universally admired x86 hardware task switching mechanism, making unloading and reloading the vendor specific module work while changing module parameters, and s390, ppc, and ia64 fixes. Shortlog/diffstat follow. Avi Kivity (1): KVM: Avoid instruction emulation when event delivery is pending Carsten Otte (1): KVM: s390: Advertise KVM_CAP_USER_MEMORY Christian Borntraeger (4): KVM: s390: Fix guest kconfig KVM: s390: Fix program check on interrupt delivery handling KVM: s390: Fix instruction naming for lctlg KVM: s390: Fix possible host kernel bug on lctl(g) handling Hollis Blanchard (1): KVM: ppc: fix invalidation of large guest pages Joerg Roedel (1): KVM: SVM: allow enabling/disabling NPT by reloading only the architecture module Julia Lawall (1): KVM: ia64: Fix irq disabling leak in error handling code Marcelo Tosatti (3): KVM: task switch: segment base is linear address KVM: task switch: use seg regs provided by subarch instead of reading from GDT KVM: task switch: translate guest segment limit to virt-extension byte granular field Martin Schwidefsky (1): KVM: s390: Change guestaddr type in gaccess Sheng Yang (2): KVM: VMX: Fix bypass_guest_pf enabling when disable EPT in module parameter KVM: VMX: Fix undefined beaviour of EPT after reload kvm-intel.ko arch/ia64/kvm/kvm-ia64.c |5 +- arch/powerpc/kvm/44x_tlb.c|5 +- arch/powerpc/kvm/emulate.c|2 +- arch/s390/kvm/gaccess.h | 62 --- arch/s390/kvm/intercept.c | 14 -- arch/s390/kvm/interrupt.c | 21 +++- arch/s390/kvm/kvm-s390.c |9 +++- arch/s390/kvm/sigp.c |5 +- arch/x86/kvm/mmu.c|7 +++ arch/x86/kvm/svm.c| 10 +++- arch/x86/kvm/vmx.c| 22 + arch/x86/kvm/x86.c| 109 - drivers/s390/kvm/Makefile |2 +- include/asm-powerpc/kvm_ppc.h |3 +- include/asm-s390/kvm_host.h |4 +- include/asm-x86/kvm_host.h|1 + 16 files changed, 143 insertions(+), 138 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/4] Port KVM-trace to tracepoints -> LTTng ?
Mathieu Desnoyers wrote: Yes, but the userspace side would collect the format strings as well (just once) and could put them in the same file. The aggregation is portable across kernel versions. Yes, LTTng does exactly all that. [snip goodies] I'll be more than happy to answer your questions. What's the merge plan for this? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Remove --disable-cpu-emulation (v2 -- sort of)
Avi Kivity wrote: > Anthony Liguori wrote: >> This option was meant to be temporary until TCG was fixed on PowerPC >> hosts. It has been so let's get rid of it. The only issue this >> would introduce is that GCC 4 could no longer be used to build KVM >> for PowerPC. Hollis has switched to GCC 3.x for other reasons >> though so this is not a big deal. >> >> This moves us closer to QEMU and gets rid of a bit of a wart. >> >> I've compile tested this with powerpc and x86. >> > > Xiantao, Carsten, are you okay with this? As I know, there is no patch to fix TCG for ia64, so I am afraid that ia64 also needs it now . :( > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/04]Create x86 directory to hold x86-specific files.
Avi Kivity wrote: > Zhang, Xiantao wrote: >> From c8c8c5a6b3ff943cb645f9ac4ef169490f14cd08 Mon Sep 17 00:00:00 >> 2001 From: Zhang Xiantao <[EMAIL PROTECTED]> >> Date: Fri, 25 Jul 2008 16:50:30 +0800 >> Subject: [PATCH] KVM: external module: Moving x86-speicif files to >> x86 directory. >> >> Create x86 directory to hold x86-specific files. >> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]> >> > > You forgot to attach a patch; and your mailer corrupts patches, so I > can't apply this. Sorry. Attached! :) > -- > error compiling committee.c: too many arguments to function 0001-KVM-external-module-Moving-x86-speicif-files-to-x8.patch Description: 0001-KVM-external-module-Moving-x86-speicif-files-to-x8.patch
Re: [PATCH 2/2] Remove -tdf
Anthony Liguori wrote: I think there's a healthy amount of scepticism about whether tdf really is worth it. This is why I suggested that we need to better quantify exactly how much this patch set helps things. For instance, a time drift test for kvm-autotest would be perfect. tdf is ugly and deviates from how hardware works. A compelling case is needed to justify it. On real hardware, the processor won't go away randomly for lengthy periods. Since software assumes this, we must either provide a correction or live with guest time not corresponding to real time. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec/kdump of a kvm guest?
Mike Snitzer wrote: Avi indicated he seems to remember that at least kexec worked last he tried (didn't provide when/what he tried though). kexec inside a guest. Months ago. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0 of 5] PowerPC patches for 2.6.27
Hollis Blanchard wrote: Hi Avi, can these patches go upstream for 2.6.27? There's a bug fix, the addition of hardware breakpoint functionality, and three very significant performance improvements. By the way, I will be on vacation for a few weeks starting Monday, but Christian Ehrhardt should be able to take care of any technical issues. Applied all; thanks. I prefer to only merge bug fixes at this time for 2.6.27. As far as I can tell, patch 2 is independent of the rest so I'll queue that. Let me know if that works. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec/kdump of a kvm guest?
Vivek Goyal wrote: Seems that libvirt functionality isn't available yet with kvm (I'm using libvirt 0.4.2, I'll give libvirt 0.4.4 a try). cc'ing the libvirt-list to get their insight. That aside, having the crash dump collection be multi-phased really isn't workable (that is if it requires a crashed guest to be manually saved after the fact). The host system _could_ be rebooted; whereby losing the guest's core image. So automating qemu and/or libvirtd to trigger a dump would seem worthwhile (maybe its already done?). That's a good point. Ideally, one would like dump to be captured automatically if kernel crashes and then reboot back to production kernel. I am not sure what can we do to let qemu know after crash so that it can automatically save dump. We can expose a virtual pci device that when accessed, causes qemu to dump the guest's core. Ok. So first task is to fix host kexec/kdump with kvm-intel module inserted. Can you do little debugging to find out where system hangs. I generally try few things for kexec related issue debugging. 1. Specify earlyprintk= parameter for second kernel and see if control is reaching to second kernel. 2. Otherwise specify --console-serial parameter on "kexec -l" commandline and it should display a message "I am in purgatory" on serial console. This will just mean that control has reached at least till purgatory. 3. If that also does not work, then most likely first kernel itself got stuck somewhere and we need to put some printks in first kernel to find out what's wrong. kvm has a reboot notifier to turn off vmx when rebooting. See kvm_reboot_notifier and kvm_reboot(). Maybe something similar is needed for kexec? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/2] Simulate Intel cpufreq MSRs in kvm guests to influencenice priority
Tian, Kevin wrote: >> From: Darrick J. Wong >> Sent: 2008年7月16日 7:18 >> >> I envision four scenarios: >> >> 0. Guests that don't know about cpufreq still run at whatever >> nice level >> they started with. >> >> 1. If we have a system with a lot of idle VMs, they will all >> run with +5 >> nice and this patch has no effect. >> >> 2. If we have a system with a lot of busy VMs, they all run >> with -5 nice >> and this patch also has no effect. >> >> 3. If, however, we have a lot of idle VMs and a few busy ones, then the >> -5 nice of the busy VMs will get those VMs extra CPU time. On a really >> crummy FPU microbenchmark I have, the score goes from about 500 to 2000 >> with the patch applied, though of course YMMV. In some respects this >> > > How many VMs did you run in this test? All the VMs are idle except > the one where your benchmark runs? > > How about the actual effect when several VMs are doing some stuff? > > There's another scenario where some VMs don't support cpufreq while > others do. Here is it unfair to just renice the latter when the former is > not 'nice' at all? > I guess the solution for such issues is not to have kvm (or qemu) play with nice levels, but instead send notifications on virtual frequency changes on the qemu monitor. The management application can then choose whether to ignore the information, play with nice levels, or even propagate the frequency change to the host (useful in client-side virtualization). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm-userspace: fix memslot assignment
Christian Borntraeger wrote: Hello Avi, seems that I mixed up the slot initialization, instead of making the first slot always 0 I made it always 1. Lets go back to Carstens variant, since I dont like nested ifdefs. The compiler will remove the dead code anyway. Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> --- libkvm.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: libkvm/libkvm.c === --- libkvm.orig/libkvm.c +++ libkvm/libkvm.c @@ -78,7 +78,7 @@ int get_free_slot(kvm_context_t kvm) int i; int tss_ext; -#if defined(KVM_CAP_SET_TSS_ADDR) && !defined(__s390__) +#if defined(KVM_CAP_SET_TSS_ADDR) tss_ext = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR); #else tss_ext = 0; This is really a no-op, since s390 will nack a KVM_CAP_SET_TSS_ADDR query. Of course, the change is an improvement. @@ -92,8 +92,11 @@ int get_free_slot(kvm_context_t kvm) if (tss_ext > 0) i = 0; else +#if !defined(__s390__) i = 1; - +#else + i = 0; +#endif ppc and ia64 also don't care about TSS_ADDR. Care to make this depend on x86, rather than on s390? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove --disable-cpu-emulation (v2 -- sort of)
Anthony Liguori wrote: This option was meant to be temporary until TCG was fixed on PowerPC hosts. It has been so let's get rid of it. The only issue this would introduce is that GCC 4 could no longer be used to build KVM for PowerPC. Hollis has switched to GCC 3.x for other reasons though so this is not a big deal. This moves us closer to QEMU and gets rid of a bit of a wart. I've compile tested this with powerpc and x86. Xiantao, Carsten, are you okay with this? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Remove -tdf
Anthony Liguori wrote: The last time I posted the KVM patch series to qemu-devel, the -tdf patch met with some opposition. Since today we implement timer catch-up in the in-kernel PIT and the in-kernel PIT is used by default, it doesn't seem all that valuable to have timer catch-up in userspace too. Removing it will reduce our divergence from QEMU. I'd rather see the feature added to qemu (in the form of Gleb's irq notifications) rather than removed. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Fix bad merge
Anthony Liguori wrote: This option no longer exists. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Paravirt loops per jiffy calculation
Glauber Costa wrote: Hey, Over the last weeks, there has been some discussion regarding paravirt lpj calculation for kvm. Here's my shot at that. KVM hypervisor already put the right value in our pvclock structures, as part of the xen compatibility efforts. So the first patch moves the respective xen code to pvclock.c (since we'll be doing the same calculation anyway), while the second, implements functions for kvm that makes use of it. Turns out that only implementing a pv get_tsc_khz is not enough, since it will only do the right thing for cpu0, which is not what we desire. So we set preset_lpj. Recall this code is run before arch parameter setup, so if we pass lpj=xx in the command line, it'll still work. Have a good (paravirtual) time! I only have this email out of the patchset. Please resend. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9][RFC] KVM virtio_net performance
Bill Davidsen wrote:
Anthony Liguori wrote:
Hi Mark,
Mark McLoughlin wrote:
Hey,
Here's a bunch of patches attempting to improve the performance
of virtio_net. This is more an RFC rather than a patch submission
since, as can be seen below, not all patches actually improve the
perfomance measurably.
I'm still seeing the same problem I saw with my patch series.
Namely, dhclient fails to get a DHCP address. Rusty noticed that RX
has a lot more packets received then it should so we're suspicious
that we're getting packet corruption.
I have been discussing this (on this list) in another thread. Putting
tcpdump on the eth0 device in the VM, the br0 device in the host, and
the eth0 (physical NIC) in the host, you can see that when the VM
generates a DHCP request it shows up on the br0 in the host, but never
gets sent on the wire by eth0.
That's the point of failure, at least using RHEL5/FC6/kvm-66 as the
environment.
Does playing with the bridge forward delay ('brctl setfd') help?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] kvm-s390: Multiple fixes for kvm on s390
Christian Borntraeger wrote: Hello Avi, here is a number of fixes and changes to the kvm on s390 port. This also includes the resend of the Kconfig patch. The patch desription has an additional comment dealing with your comment. I think all patches are ok for 2.6.27. Patches 4 and 6 are fixing potential host BUGs. 1. Advertise KVM_CAP_USER_MEMORY 2. Fix guest kconfig 3. Change guestaddr type in gaccess 4. Fix program check on interrupt delivery handling 5. Fix instruction naming for lctlg 6. Fix possible host kernel bug on lctl(g) handling Applied all, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/04]Create x86 directory to hold x86-specific files.
Zhang, Xiantao wrote: From c8c8c5a6b3ff943cb645f9ac4ef169490f14cd08 Mon Sep 17 00:00:00 2001 From: Zhang Xiantao <[EMAIL PROTECTED]> Date: Fri, 25 Jul 2008 16:50:30 +0800 Subject: [PATCH] KVM: external module: Moving x86-speicif files to x86 directory. Create x86 directory to hold x86-specific files. Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]> You forgot to attach a patch; and your mailer corrupts patches, so I can't apply this. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
