Re: Unable to pass multiple cores / CPUs to guests
Binarus wrote: Dear all, it seems that I am unable to pass multiple cores / CPUs to KVM guests. Whatever I do, the guests only report one CPU / core. ... /usr/bin/qemu-system-x86_64 -M pc -cpu host -smp cores=2,threads=1,sockets=1 -drive file=/dev/sda6,if=virtio,cache=none,index=0 -drive file=/dev/sdb,if=virtio,cache=none,index=1 -cdrom /dev/cdrom -pidfile ./qemu-garak.pid -boot c -k de -m 4096 -smp 1 -device pci-assign,host=01:05.0 -daemonize -usb -usbdevice tablet -name garak -net nic,vlan=0,model=virtio,macaddr=02:01:01:01:01:01 -net tap,vlan=0,ifname=virtnet1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifup -vnc :1 Remove the -smp 1. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
Arnaldo Carvalho de Melo wrote: Em Wed, Nov 09, 2011 at 11:40:01AM +0100, Gerd Hoffmann escreveu: Hi, What we want to have is to have a set of distinctive colors - just two (background, foreground) colors are not enough - we also need colors to highlight certain information - we need 5-6 colors for the output to be maximally expressive. Is there a canonical way to handle that while still adapting to user preferences automatically by taking background/foreground color scheme of the xterm into account? I suspect to fix the worst of the fallout we could add some logic to detect low contrast combinations (too low color distance) and fall back to the foreground/background colors in that case. As far I know it is pretty much impossible to figure the foreground/background colors of the terminal you are running on. You Glad to hear that, I thought I hadn't researched that much (I did). Hope somebody appears and tell us how it is done :-) In xterm, '\e]10;?\e\\' and '\e]11;?\e\\' will report the colors, e.g.: #!/bin/bash read -s -r -d \\ -p `printf '\e]10;?\e\\'` -t 1 fg [ $? -ne 0 ] fg=no response echo foreground: $fg | cat -v read -s -r -d \\ -p `printf '\e]11;?\e\\'` -t 1 bg [ $? -ne 0 ] bg=no response echo background: $bg | cat -v -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: repeatable hang with loop mount and heavy IO in guest (now in host - not KVM then..)
Antoine Martin wrote: On 02/27/2010 12:38 AM, Antoine Martin wrote: 1 0 0 98 0 1| 0 0 | 66B 354B| 0 0 | 3011 1 1 0 98 0 0| 0 0 | 66B 354B| 0 0 | 2911 From that point onwards, nothing will happen. The host has disk IO to spare... So what is it waiting for?? Moved to an AMD64 host. No effect. Disabled swap before running the test. No effect. Moved the guest to a fully up-to-date FC12 server (2.6.31.6-145.fc12.x86_64), no effect. I have narrowed it down to the guest's filesystem used for backing the disk image which is loop mounted: although it was not completely full (and had enough inodes), freeing some space on it prevents the system from misbehaving. FYI: the disk image was clean and was fscked before each test. kvm had been updated to 0.12.3 The weird thing is that the same filesystem works fine (no system hang) if used directly from the host, it is only misbehaving via kvm... So I am not dismissing the possibility that kvm may be at least partly to blame, or that it is exposing a filesystem bug (race?) not normally encountered. (I have backed up the full 32GB virtual disk in case someone suggests further investigation) Well, well. I've just hit the exact same bug on another *host* (not a guest), running stock Fedora 12. So this isn't a kvm bug after all. Definitely a loop+ext(4?) bug. Looks like you need a pretty big loop mounted partition to trigger it. (bigger than available ram?) This is what triggered it on a quad amd system with 8Gb of ram, software raid-1 partition: mount -o loop 2GB.dd source dd if=/dev/zero of=8GB.dd bs=1048576 count=8192 mkfs.ext4 -f 8GB.dd mount -o loop 8GB.dd dest rsync -rplogtD source/* dest/ umount source umount dest ^ this is where it hangs, I then tried to issue a 'sync' from another terminal, which also hung. It took more than 10 minutes to settle itself, during that time one CPU was stuck in wait state. This sounds like: https://bugzilla.kernel.org/show_bug.cgi?id=15906 https://bugzilla.redhat.com/show_bug.cgi?id=588930 -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] KVM: PPC: Be more informative on BUG
Alexander Graf wrote:
We have a condition in the ppc64 host mmu code that should never occur.
Unfortunately, it just did happen to me and I was rather puzzled on why,
because BUG_ON doesn't tell me anything useful.
So let's add some more debug output in case this goes wrong. Also change
BUG to WARN, since I don't want to reboot every time I mess something up.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/book3s_64_mmu_host.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c
b/arch/powerpc/kvm/book3s_64_mmu_host.c
index 41af12f..5bf91a7 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -231,10 +231,15 @@ int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct
kvmppc_pte *orig_pte)
vcpu-arch.mmu.esid_to_vsid(vcpu, orig_pte-eaddr SID_SHIFT, vsid);
map = find_sid_vsid(vcpu, vsid);
if (!map) {
- kvmppc_mmu_map_segment(vcpu, orig_pte-eaddr);
+ ret = kvmppc_mmu_map_segment(vcpu, orig_pte-eaddr);
+ WARN_ON(ret 0);
map = find_sid_vsid(vcpu, vsid);
}
- BUG_ON(!map);
+ if (!map) {
+ printk(KERN_ERR KVM: Segment map for 0x%llx (0x%lx) failed\n,
+ vsid, orig_pte-eaddr);
+ WARN();
Return here, otherwise dereferencing map in the next line will crash anyway...
+ }
vsid = map-host_vsid;
va = hpt_va(orig_pte-eaddr, vsid, MMU_SEGSIZE_256M);
--
1.6.0.2
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-jim
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on copy paste
Stephen Liu wrote: You can use higher level layers to handle that in the meantime. For example, I always use rdesktop to connect to my Windows guests and it supports copy and paste just fine. Hi Jim, Thanks for your advice. Host - Debian 5.0 Guest - Debian 5.0 I have rdesktop running here. But I can't connect the guest on host $ rdesktop 192.168.0.30 Autoselected keyboard map en-us ERROR: 192.168.0.30: unable to connect On VBox I run; $ rdesktop 192.168.0.30:3389 It connects. Here I don't know which port to be used. Could you please shed me some light. TIA You'll need a rdp server on the guest, try xrdp. Or you can run a vnc server on the guest and use a vnc client on the host. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on copy paste
Stephen Liu wrote: - Original Message From: Amit Shah amit.s...@redhat.com To: Stephen Liu sati...@yahoo.com Cc: kvm@vger.kernel.org Sent: Thu, April 15, 2010 9:02:53 AM Subject: Re: Question on copy paste On (Thu) Apr 15 2010 [08:45:23], Stephen Liu wrote: Hi folks, host - Debian 5.04 What will the easy way to enable copy_and_paste function between guest and hosts? Also among guests. TIA This doesn't exist yet, but something should be available in a few months. Noted and thanks You can use higher level layers to handle that in the meantime. For example, I always use rdesktop to connect to my Windows guests and it supports copy and paste just fine. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
qemu-kvm-0.12.2 hangs when booting grub, when kvm is disabled
Hi, With this small disk image: http://psy.jim.sh/~jim/tmp/diskimage.gz and the new qemu-kvm-0.12.2: $ kvm --version QEMU PC emulator version 0.12.2 (qemu-kvm-0.12.2), Copyright (c) 2003-2008 Fabrice Bellard I can successfully boot to a grub prompt with: $ kvm -drive file=diskimage,boot=on However, if kvm gets disabled: $ kvm -no-kvm -drive file=diskimage,boot=on then the boot hangs at GRUB Loading, please wait... and consumes 100% CPU. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some keys don't repeat in 64 bit Widows 7 kvm guest
Jimmy Crossley wrote: Thanks for the quick response, Gleb. You are right - we should not spend our time troubleshooting an issue with something this old. I'll try downloading all the sources and headers I need to build kvm-88. I think I'll need another Debian install, since this is a production machine and I don't want to destabilize it. Go ahead and laugh - I ran Debian stable for years before finally deciding I could risk running testing. Debian testing still has the kvm package at version 72, but the new package name qemu-kvm is at version 0.11.0 which is quite a bit newer. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows XP Bluescreen when unplugging printer
Erik Rull wrote: Jim Paris wrote: Erik Rull wrote: Hi all, I want to run an epson inkjet within my windows xp guest. my host has enabled usb 2.0, the USB flashdrive works without any problems. When I plug in the printer (works with the same drivers on a native windows xp!), it is recognized and the status monitor shows also the ink levels. Until I start printing. Then the ink level disappears and the status monitor hangs. The printer itself doesn't do anything, no LED blinks, no printing starts. When I shut down windows or unplug the printer I get a bluescreen in XP on usbuhci.sys Interesting: When I switch off USB 2.0 and enable only USB 1.x in the host BIOS, everything related to USB is SLOW (usb flash drive, too!) but the printer works (also slow, but it prints). Any ideas what could cause that behaviour? Comes up with kvm-88 and kvm-77 as well. I tested it on two different systems both the same behaviour. You might try this usb fix: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c4c0e236beabb9de5ff472f77aeb811ec5484615 It's been around for a while but hasn't made it into any qemu or kvm releases yet. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, No ideas, sorry. It might be a Windows driver problem triggered by qemu timing differences (try reinstalling the printer drivers?) You might also try enabling DEBUG in usb-linux.c and compare the output you get there with a usbmon capture on the host, and a usbsnoopy capture on the guest, to see if there are any discrepencies. Not sure what kind of thing you'd be looking for, though. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows XP Bluescreen when unplugging printer
Erik Rull wrote: Jim Paris wrote: Erik Rull wrote: Hi Jim, sorry, still a bluescreen - but another one :-) BUGCODE_USBDRIVER is its name. Any other ideas? With USB 1.1 on the host everything is fine, after enabling USB 2.0 in BIOS on the host, USB is faster within the guest, but I have the given Bluescreen problem. Best regards, No ideas, sorry. It might be a Windows driver problem triggered by qemu timing differences (try reinstalling the printer drivers?) You might also try enabling DEBUG in usb-linux.c and compare the output you get there with a usbmon capture on the host, and a usbsnoopy capture on the guest, to see if there are any discrepencies. Not sure what kind of thing you'd be looking for, though. -jim Hm, what I forgot to say: Now the bluescreen comes up directly after trying to print, before it only appeared on unplugging or shutdown. And: It seems to be a USB 2.0 issue. When I plug in a USB 1.1 printer everything is fine?? Can you recommend a usb sniffer tool? Hope this helps when getting a bluescreen :-) usbmon (e.g. with wireshark) on the Linux host should work. usbsnoopy is a tool you can use on the Windows guest side. Of course, if the guest OS is crashing it's going to be hard to get any useful data out of that after the crash. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows XP Bluescreen when unplugging printer
Erik Rull wrote: Hi all, I want to run an epson inkjet within my windows xp guest. my host has enabled usb 2.0, the USB flashdrive works without any problems. When I plug in the printer (works with the same drivers on a native windows xp!), it is recognized and the status monitor shows also the ink levels. Until I start printing. Then the ink level disappears and the status monitor hangs. The printer itself doesn't do anything, no LED blinks, no printing starts. When I shut down windows or unplug the printer I get a bluescreen in XP on usbuhci.sys Interesting: When I switch off USB 2.0 and enable only USB 1.x in the host BIOS, everything related to USB is SLOW (usb flash drive, too!) but the printer works (also slow, but it prints). Any ideas what could cause that behaviour? Comes up with kvm-88 and kvm-77 as well. I tested it on two different systems both the same behaviour. You might try this usb fix: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=c4c0e236beabb9de5ff472f77aeb811ec5484615 It's been around for a while but hasn't made it into any qemu or kvm releases yet. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm or qemu-kvm?
Avi Kivity wrote: On 10/01/2009 08:06 PM, Jim Paris wrote: That's what I do. Just as a warning, if you're using the libvirt packages from Debian unstable, make sure you also install linux-libc-dev from unstable before building qemu-kvm. Otherwise, virtio networking will fail. The reason is that qemu-kvm will be built against the Lenny linux-libc-dev which does not have IFF_VNET_HDR, while the libvirt was built against a newer linux-libc-dev that did define IFF_VNET_HDR. If they don't agree then things break. Isn't that a libvirt bug? libvirt shouldn't assume qemu supports IFF_VNET_HDR just because it sees it. Probably, but I think it has no way of knowing, because qemu doesn't report whether it supports it. http://libvirt.org/git/?p=libvirt.git;a=commit;h=b4f62abbf1191c8fbab3306b4bf2f2567e18067f However, we need to be careful to only set the flag when a) QEMU has support for this ABI and b) the value of the flag is queryable using the TUNGETIFF ioctl. It's nearly five months since kvm-74 - the first KVM release with this feature - was released. Up until now, we've not added libvirt support because there is no clean way to detect support for this in QEMU at runtime. A brief attempt to add a info capabilities monitor command to QEMU floundered. Perfect is the enemy of good enough. Probing the KVM version will suffice for now. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Modifying RAM during runtime on guest
Daniel Bareiro wrote: Hi Brian. On Tuesday, 08 September 2009 16:18:09 -0500, Brian Jackson wrote: I'm trying to modify the amount of RAM that has some of guests. Host has 2.6.30 kernel with KVM-88. In one of guest I didn't have problems when decreasing the amount of memory from 3584 MIB to 1024 MiB. This guest has 2.6.26-2-686 stock kernel. Also I was trying to decrease the amount RAM of another guest from 3584 MiB to 2048 MiB, but it didn't work. This other guest has 2.6.24-etchnhalf.1-686-bigmem stock kernel. Does Ballooning in guest require 2.6.25 or superior? I don't know, if that kernel has a virtio-balloon driver, I'd think that was all you need to balloon memory. Then can be that it is related to kernel that is using the guest: # uname -a Linux aprender01 2.6.24-etchnhalf.1-686-bigmem #1 SMP Mon Jul 27 03:56:49 UTC 2009 i686 GNU/Linux # cat config-2.6.24-etchnhalf.1-686-bigmem | grep -i virtio # Thinking that it could be an impediment related to the kernel version of guest, I tried to increase the memory of another one guest with 2.6.26-2-686 from 512 MIB to 1024 MIB, but this didn't work either. You can only grow memory up to the amount you specified on the command line if you've already ballooned down. Good. Thanks for clarifying to me this detail. So if you specify -m 1024M on the command line, then shrink it to 512, you could then balloon it back up to a max of 1024. According to the tests that I was doing in guest with kernel with support for virtio, shrinking works, but when trying to return to the amount of initial memory, seems that it fails and I lose connectivity by serial console and ssh. In the guest: # uname -a Linux central 2.6.26-2-amd64 #1 SMP Sun Jul 26 20:35:48 UTC 2009 x86_64 GNU/Linux # cat config-2.6.26-2-amd64 | grep -i virtio CONFIG_NET_9P_VIRTIO=m CONFIG_VIRTIO_BLK=m CONFIG_VIRTIO_NET=m CONFIG_HW_RANDOM_VIRTIO=m CONFIG_VIRTIO=m CONFIG_VIRTIO_RING=m CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m In the host: # telnet localhost 4045 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. QEMU 0.10.50 monitor - type 'help' for more information (qemu) (qemu) info balloon balloon: actual=512 (qemu) balloon 256 (qemu) info balloon balloon: actual=256 (qemu) (qemu) balloon 512 (qemu) info balloon balloon: actual=36 At this moment I'm unable to connect by serial console to the guest and the ssh sessions are freeze nevertheless kvm process of the guest is running. Using a VNC client I see several messages of this type in the guest: Out of memory: kill process (name) score xx or a child Killed process (name) Finally: Kernel panic - not syncing - Out of memory and no killable processes... Thanks for your reply. Hi Daniel, I noticed no-one answered this, and I just ran into the same thing myself. As Avi pointed out earlier, it is a guest bug, and upgrading the guest to 2.6.27 should fix it: http://www.mail-archive.com/kvm@vger.kernel.org/msg10849.html -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor network performance with cable modem assigned to guest
Jon Fairbairn wrote: Brian Jackson i...@theiggy.com writes: On Friday 28 August 2009 01:14:42 pm Jon Fairbairn wrote: I'm experimenting with a virtual router. I did this a few years ago with Xen and it worked well enough, but then fedora changed and it stopped working, so I gave up for a while. Now I have a machine that supports hardware virtualisation, I thought I'd try again. The setup was done through virt-manager. The network between the host and guest is a virtual bridge. What I've been trying to do is to assign a USB cable modem to the guest, This is probably your problem here. KVM only emulates a usb1.1 controller, that shouldn't be a problem as the cable modem is only a usb 1.1 device. and from all reports, it doesn't really do that very well. Not very well? We're talking about a factor of *FIFTY* slow down here. If I'd implemented the driver in a 1980s lazy functional language I would have only expected a factor of ten :-P ;-). There have been numerous reports of poor performance even for a usb1.1 device. You should check the archives to see if there was ever any kind of tips or resolution to some of those problems. I had a look, but I couldn't find anything helpful. Maybe I'm searching for the wrong things? I don't have any specific answers, but you might be able to get some more info by uncomenting the //#define DEBUG in kvm's usb-linux.c. You might also try capturing the USB traffic (e.g. with wireshark) both in the host with the modem connected directly, and in the guest with the modem passed through, to see if there are any differences other than speed (packet sizes, etc). Also try comparing the lsusb -vvv output in both guest and host? -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to remove VM (client) with command line ?
Stephen Liu wrote: Hi folks, Debian 5.0 KVM How to remove/delete VM (client) on command line instead of on Virt-manager. Ex. $ sudo virsh --connect qemu:///system virsh # list --all Id Name State -- - vm10 shut off - vm11 shut off - vm13 shut off I expect to remove vm10 and vm11. The later was cloned on the former. This is a libvirt question, not a kvm question. You should use the libvirt mailing list instead. Also, check the documentation and the help output, as it is generally good. To remove a domain completely, use undefine. Furthermore; Do I need uml-utilities ? What will be its use? You would use uml-utilities if you were using User Mode Linux. Again, not KVM related. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to highlight text with mouse
Stephen Liu wrote: Hi folks, Debian 5.0 KVM I need to copy the text on client's (VM) terminal. Please advise how to highlight the text with mouse pointer. If you are running kvm with a VNC or SDL display, it is a graphical display and you cannot select text from the host. You could run gpm or similar in the guest. You can also start kvm with -curses which will display text using curses/ncurses, instead of graphically. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
G wrote:
On Tue, Jul 21, 2009 at 1:23 AM, Jim Parisj...@jtan.com wrote:
Here's a patch to try. I'm not familiar with the code, but it looks
like this buffer might be too small versus the packet lengths that
you're seeing, and similar definitions in hw/usb-uhci.c.
-jim
diff -urN kvm-87-orig/usb-linux.c kvm-87/usb-linux.c
--- kvm-87-orig/usb-linux.c 2009-06-23 09:32:38.0 -0400
+++ kvm-87/usb-linux.c 2009-07-20 19:15:35.0 -0400
@@ -115,7 +115,7 @@
uint16_t offset;
uint8_t state;
struct usb_ctrlrequest req;
- uint8_t buffer[1024];
+ uint8_t buffer[2048];
};
typedef struct USBHostDevice {
Yes! Applying this patch makes the crash go away! Thank you!
Great!
In addition to enabling DEBUG and applying your debug printout
patches, I added a debug printout right above the memcpy()s in
usb-linux.c, and found that the memcpy() in do_token_in() is called
multiple time (since do_token_in() is called multiple times for the
1993 bytes usb packet I have in my usb sniff dumps), which I guess is
what's causing a buffer overflow as the offset is pushed beyond 1024
bytes. But I'm not sure.
Yeah, I think that's it.
I've looked at the code trying to figure out a better way to solve
this, now that the problem spot has been found. To me it seems that
malloc()ing and, when the need arises (the large 1993 bytes packets
I'm seeing), realloc()ing the buffer, instead of using a statically
sized buffer, would be the best solution.
Dynamically sizing the buffer might get tricky. It looks like
hw/usb-uhci.c will go up to 2048, while hw/usb-ohci.c and
hw/usb-musb.c could potentially go up to 8192. I think bumping it to
8192 and adding an error instead of overflowing would be good enough.
I'll try to understand the code a bit more and then spin a patch.
One could of course redefine all buffers to be 8192 bytes instead,
but that would just be a false sense of security, and perhaps some
buffers need to be of a particular size to conform to the USB
specification...
USB packets don't get that large, but the host controllers can combine
them, from what I understand. So it's more a question of what the
host controllers can do.
-jim
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
G wrote:
I'm not too familiar with valgrind output, I have only used it on
smaller programs I've written myself, so I don't know what to think of
the messages (and amount of messages; valgrind told me to use
--error-limit=no). I do get a bit nervous from all the complaints
about uninitialized values and byes, but maybe it's normal for an
application of kvm's size and type.
I'd be nervous too :) Many of the complaints look harmless, but it's
probably worth fixing them to make the real bugs stand out more.
Even though you're having problems with -no-kvm, I suspect this is an
upstream qemu issue, so you should probably try the qemu list too.
qemu-de...@nongnu.org? I'll try to figure out the -no-kvm issue first,
so I can run any commands they might want me to run.
And thanks for your help and suggestions so far, btw.
Here's a patch to try. I'm not familiar with the code, but it looks
like this buffer might be too small versus the packet lengths that
you're seeing, and similar definitions in hw/usb-uhci.c.
-jim
diff -urN kvm-87-orig/usb-linux.c kvm-87/usb-linux.c
--- kvm-87-orig/usb-linux.c 2009-06-23 09:32:38.0 -0400
+++ kvm-87/usb-linux.c 2009-07-20 19:15:35.0 -0400
@@ -115,7 +115,7 @@
uint16_t offset;
uint8_t state;
struct usb_ctrlrequest req;
-uint8_t buffer[1024];
+uint8_t buffer[2048];
};
typedef struct USBHostDevice {
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
Hi G,
I've continued my attempts to get the HASP dongle working, but with no
success:
...
Good idea. The results from three test runs after that change are in
the attached files. The third was done while also dumping the USB bus,
and the output from that dump is also attached.
The gdb output here looks questionable. Only the second trial seems
to have USB related stuff in the backtrace, so either gdb is wrong or
there's some memory corruption that is causing crashes elsewhere.
Maybe valgrind could help?
You can also add more debugging to the usb code to try to figure out
where things are going wrong. See the attached patch for some printfs
that might help.
Try again with less memory on the guest, like -m 2048, just to reduce
possible problems with the 32-bit guest and address space.
I didn't see anything obviously wrong with the usbmon dumps you sent,
or the debugging that qemu printed out, but I'm not familiar with this
code.
Even though you're having problems with -no-kvm, I suspect this is an
upstream qemu issue, so you should probably try the qemu list too.
-jim
diff -urN kvm-87/usb-linux.c kvm-87-debug/usb-linux.c
--- kvm-87/usb-linux.c 2009-06-23 09:32:38.0 -0400
+++ kvm-87-debug/usb-linux.c 2009-07-16 03:06:22.0 -0400
@@ -209,16 +209,21 @@
static AsyncURB *async_alloc(void)
{
-return (AsyncURB *) qemu_mallocz(sizeof(AsyncURB));
+AsyncURB *aurb = (AsyncURB *) qemu_mallocz(sizeof(AsyncURB));
+dprintf(husb: allocated %p\n, aurb);
+return aurb;
}
static void async_free(AsyncURB *aurb)
{
+dprintf(husb: freeing %p\n, aurb);
qemu_free(aurb);
}
static void async_complete_ctrl(USBHostDevice *s, USBPacket *p)
{
+dprintf(husb: complete ctrl, host state %d len %d\n,
+ s-ctrl.state, s-ctrl.len);
switch(s-ctrl.state) {
case CTRL_STATE_SETUP:
if (p-len s-ctrl.len)
@@ -266,6 +271,7 @@
aurb, aurb-urb.status, aurb-urb.actual_length);
if (p) {
+ dprintf(husb: p=%p\n, p);
switch (aurb-urb.status) {
case 0:
p-len = aurb-urb.actual_length;
@@ -280,11 +286,12 @@
p-len = USB_RET_NAK;
break;
}
-
+ dprintf(husb: completing, p-len=%d\n, p-len);
usb_packet_complete(p);
}
async_free(aurb);
+
}
}
Re: KVM crashes when using certain USB device
G wrote: Hello again, I've continued my attempts to get the HASP dongle working, but with no success: Downloaded kvm-72.tar.gz through kvm-87.tar.gz to find out when the problem first appear, as kvm-72 is working. Unfortunately, kvm-72 through kvm-82 fails to compile on my Debian system with kernel 2.6.30 and gcc 4.3, and kvm-83 crashes in the same way that kvm-87 crashes. I have also tested two other USB devices: a C-Pen (www.cpen.com) and a GEM card reader, both successfully. So it seems it is the HASP dongle/driver combo which is doing something naughty that makes KVM versions newer than kvm-72 crash... Anyone got any ideas what I might try out to find the cause for the crashes? You might try uncommenting //#define DEBUG at the top of usb-linux.c to get some more verbose output from qemu. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM-86 not exposing 64 bits CPU anymore, NICE
Gilles PIETRI wrote: Hi, I'm quite pissed off. I just upgraded to kvm-86 on a host that has worked nicely on kvm-78 for quite some time. But since I was fearing the qcow2 corruption issues, I wanted to upgrade kvm-86. After testing the performance, I decided to switch. How stupid that was. That was really putting too much trust in KVM. Now I can't have 64 bits CPUs on my guests. My host is running a 2.6.27.7 kernel, and is x86_64 enabled. Until the upgrade, guests were running x86_64 fine. Now, it says long mode can't be used or something like that, and I can only have 32 bits guests. Please see http://www.mail-archive.com/kvm@vger.kernel.org/msg15757.html http://www.mail-archive.com/kvm@vger.kernel.org/msg15769.html -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to manage KVM guests with libvirt ?
Javier Guerra wrote: On Mon, Jun 1, 2009 at 11:02 AM, Riccardo Veraldi riccardo.vera...@cnaf.infn.it wrote: thank you very much. How do I know all the XML tag options ?? how to convert from comand line quemu options into XML tags ? and here to put XML file ? you'll have to play around a little with a test machine before you get the hang of it. the xml options are documented on the libvirt site. put them in /etc/libvirt/qemu/blahblahblah.xml, and the libvirtd daemon will pick them at startup. With libvirt 0.6.4, you can use the virsh domxml-from-native tool to convert from QEMU arguments to XML automatically: http://libvirt.org/drvqemu.html#xmlimport about the console I used to start qemu-kvm under SCREEN program. is ther another better way to have serial console ? for that i don't have any good answer. it seems libvirt ties the qemu monitor with a pipe to its own process, so you don't have manual control anymore. i'd much prefer if it used a unix socket, so you could open it with socat or similar tools. If by serial console you mean an actual emulated serial port, use the serial tag in the XML for this. You can point it to a socket, actual device, TCP server, etc. http://libvirt.org/formatdomain.html#elementsConsole If you want access to the Qemu monitor console, Libvirt does not provide that directly (by design), but it does use Unix sockets to interact with the monitor, so you could in theory kill Libvirt and talk to Qemu directly through the monitor socket in /var/run/libvirt/qemu. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issues with virtio_net in multiple guests?
Ken Robertson wrote: Hoping someone can help me track down an issue I'm experiencing on a KVM machine I built recently. ... SIOCSIFFLAGS: Cannot assign requested address The address isn't in use or anything, so no reason I can think of why it can't assign it. It recognizes the device, however can't bring it up. All the VMs have unique MAC addresses, randomly generated. One of the ones that doesn't work is using 93:01:dc:a0:f0:57. That MAC address is not valid. The LSB of the first byte should be 0 to indicate unicast, and the second LSB of the first byte should be 1 to indicate a locally-assigned address. e.g. 92:01:dc:a0:f0:57 should work. -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issues with virtio_net in multiple guests?
Ken Robertson wrote: Jim, That was it! I didn't realize there was some significance of certain bits within the address. Changing that first byte resolved the issue. Should I be setting the 2nd bit in the LSB to 1? I started logging into all the systems I have access to and realized all of them have 00 as the first byte in the address. Should I just stick to 00 on all mine? Or by making that 2nd bit 1, does that force the card to inherit an address from libvirt or somewhere else instead of the VM configuration? I'll play around with it some more, but at least that mystery is solved. The 2nd LSB of the first byte just says it's a locally generated address rather than one of the officially-assigned OUIs. The 1st LSB of the first byte is the important one as that's what the Linux kernel checks and rejects if it's set (it also rejects an address of all zeros). -jim -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-75 release
Avi Kivity wrote: - restore option roms to their original content on reset - fixes extboot failures after reset It doesn't seem to work here: $ dmesg | grep kvm | tail -1 [1649282.904413] loaded kvm module (kvm-75) $ sudo kvm | head -1 QEMU PC emulator version 0.9.1 (kvm-75), Copyright (c) 2003-2008 Fabrice Bellard $ sudo /usr/bin/kvm -M pc -m 512 -smp 1 -name svn -boot c -drive file=/dev/mapper/raid1-svn,if=virtio,index=0,boot=on At GRUB, I hit c for a command prompt, then type reboot. At the reboot, the BIOS says: QEMU BIOS - build: 09/03/08 $Revision: 1.182 $ $Date: 2007/08/01 17:09:51 $ Options: apmbios pcibios eltorito rombios32 ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom Booting from Hard Disk... Boot from Hard Disk failed: could not read the boot disk FATAL: No bootable device. With if=ide, rebooting in this manner works fine. -jim -- 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-75 release
Avi Kivity wrote: Jim Paris wrote: Avi Kivity wrote: - restore option roms to their original content on reset - fixes extboot failures after reset It doesn't seem to work here: grub is probably booting via int 19 or jumping to the reset vector, so kvm doesn't see the reboot. You're right: ENTRY(grub_reboot) callEXT_C(prot_to_real) .code16 /* cold boot */ movw$0x0472, %di movw%ax, (%di) ljmp$0x, $0x If that's the case, we can either implement the chipset's memory control registers properly and teach the bios to program them, or add a hack in the bios to trigger the copying without the full reset. My testing was a bit flawed. With kvm-74, I noticed that reboot from Linux had the problem, and reboot from grub failed the same way. With kvm-75, I only tested reboot from grub. I can verify that reboot from Linux works fine with virtio and kvm-75, and so the current behavior is actually fine for us. Thanks, -jim -- 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
