Re: [PATCH 1/3] Target-microblaze: Remove unnecessary variable
05.10.2015 08:18, Markus Armbruster wrote: > Michael Tokarev <m...@tls.msk.ru> writes: > >> 25.09.2015 11:37, Shraddha Barke wrote: >>> Compress lines and remove the variable . >> >> Applied to -trivial, removing this piece of commit message: >> >> --- >>> Change made using Coccinelle script [..snip..] >> --- > > Why? I like having the semantic patch in the commit message when > there's any chance we'll want do the same mechanical change again later. > > You could save space and include it by reference, though: "Same > Coccinelle semantic patch as is commit 74c373e". git commit messages aren't good documentation for various scripts like this, this info will be lost in the noize. If it might be better to keep such scripts in a separate file where it is easier to find, or in a wiki page on the site. The key point is where to find the info, git log is difficult for that, especially when you don't know what to search for or that such a script exists in there in the first place. On the other hand, when git log is cluttered by such a long messages for such small changes, it becomes more difficult to find info which you really look in git log -- namely, which changes were made that might have introduced this regression, things like that. So to me, the shorter and cleaner the commit message is, the better. BTW, I've no idea why this email has been Cc'd to kvm@vger :) Thanks, /mjt -- 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 1/3] Target-microblaze: Remove unnecessary variable
25.09.2015 11:37, Shraddha Barke wrote: > Compress lines and remove the variable . Applied to -trivial, removing this piece of commit message: --- > Change made using Coccinelle script > > @@ > expression ret; > @@ > - if (ret) return ret; > - return 0; > + return ret; > @@ > local idexpression ret; > expression e; > @@ > - ret = e; > - return ret; > + return e; > @@ > type T; identifier i; > @@ > - T i; > ... when != i --- Thanks, /mjt -- 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 3/3] Target-ppc: Remove unnecessary variable
25.09.2015 11:37, Shraddha Barke wrote: > Compress lines and remove the variable. Applied to -trivial, removing this piece of commit message: --- > Change made using Coccinelle script > > @@ > expression ret; > @@ > - if (ret) return ret; > - return 0; > + return ret; > @@ > local idexpression ret; > expression e; > @@ > - ret = e; > - return ret; > + return e; > @@ > type T; identifier i; > @@ > - T i; > ... when != i --- Thanks, /mjt -- 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: x2apic issues with Solaris and Xen guests
20.04.2015 20:29, Jan Kiszka wrote: On 2015-04-20 19:07, Stefan Hajnoczi wrote: I wonder whether the following two x2apic issues are related: Solaris 10 U11 network doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=1040500 kvm - fails to setup timer interrupt via io-apic (Thanks to Michael Tokarev for posting this link) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528077#68 [] Has anyone looked into this? Not yet. Is there a handy reproduction guest image? Or maybe someone would like to start with tracing what the guest and the host do. The second link gives a trivial reproducer, you need just the xen hipervisor binary and some kernel. This should be easy too, because it happens right on boot. But I guess it requires some inner knowlege of xen early boot machinery. Thanks, /mjt -- 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: zapping shadow pages for mmio generation wraparound
On Tue, 23 Jul 2013 13:50:21 +0200, Paolo Bonzini wrote: ... Jul 21 00:25:32 ps kernel: kvm: zapping shadow pages for mmio generation wraparound The log message would let us correlate any reports with a new optimization (added in 3.11). We will probably downgrade it to KERN_DEBUG before 3.11 goes out (or otherwise cause it to disappear), in the meanwhile it's harmless. Hm. I just upgraded one of our heavy-kvm-usage host from 3.10 to 3.16, and it started showing these messages (hence I started searching and found this thread from 2013). Has it not been decided to downgrade this message to KERN_DEBUG for some reason? What does this message mean anyway? Why this very rare case (according to comments in arch/x86/kvm/mmu.c) happens on this machine? Thanks, /mjt -- 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: x86: add module parameter to disable periodic kvmclock sync
13.11.2014 05:44, Marcelo Tosatti wrote: The periodic kvmclock sync can be an undesired source of latencies. Shouldn't this be a per-vm property, not global host property? Maybe it's better to control frequency of syncs (with 0=disabled)? Thanks, /mjt -- 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: [Qemu-trivial] [PATCH] target-ppc: kvm: Fix memory overflow issue about strncat()
On 10/13/2014 06:47 PM, Alexander Graf wrote:
On 13.10.14 16:36, Chen Gang wrote:
strncat() will append additional '\0' to destination buffer, so need
additional 1 byte for it, or may cause memory overflow, just like other
area within QEMU have done.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
I agree with this patch. However, the code is pretty ugly - I'm sure it
must've been me who wrote it :).
Could you please instead rewrite it to use g_strdup_printf() rather than
strncat()s? That way we resolve all string pitfalls automatically - and
this code is not the fast path, so doing an extra memory allocation is ok.
I'd just use snprintf() like this:
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 9c23c6b..5eaa36c 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1794,8 +1794,7 @@ static uint64_t kvmppc_read_int_cpu_dt(const char
*propname)
return -1;
}
-strncat(buf, /, sizeof(buf) - strlen(buf));
-strncat(buf, propname, sizeof(buf) - strlen(buf));
+snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), /%s, propname);
f = fopen(buf, rb);
if (!f) {
the buffer is of size PATH_MAX, and we're looking at /proc filesystem where
names should be rather short so we're extremly unlikely to hit this prob in
practice, there's no need to dynamically allocate a buffer for this stuff.
(Or alternatively there's asprintf(), but still I think it is overkill).
I can apply the above if everyone agrees.
Thanks,
/mjt
target-ppc/kvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 9c23c6b..66e7ce5 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1794,8 +1794,8 @@ static uint64_t kvmppc_read_int_cpu_dt(const char
*propname)
return -1;
}
-strncat(buf, /, sizeof(buf) - strlen(buf));
-strncat(buf, propname, sizeof(buf) - strlen(buf));
+strncat(buf, /, sizeof(buf) - strlen(buf) - 1);
+strncat(buf, propname, sizeof(buf) - strlen(buf) - 1);
f = fopen(buf, rb);
if (!f) {
--
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] arch: x86: kvm: x86.c: Cleaning up uninitialized variables
03.06.2014 16:04, Paolo Bonzini wrote:
Il 01/06/2014 01:05, Rickard Strandqvist ha scritto:
There is a risk that the variable will be used without being initialized.
This was largely found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
No, there isn't. The full context looks like this:
longmode = is_long_mode(vcpu) cs_l == 1;
if (!longmode) {
param = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDX) 32) |
(kvm_register_read(vcpu, VCPU_REGS_RAX) 0x);
ingpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RBX) 32) |
(kvm_register_read(vcpu, VCPU_REGS_RCX) 0x);
outgpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDI) 32) |
(kvm_register_read(vcpu, VCPU_REGS_RSI) 0x);
}
#ifdef CONFIG_X86_64
else {
param = kvm_register_read(vcpu, VCPU_REGS_RCX);
ingpa = kvm_register_read(vcpu, VCPU_REGS_RDX);
outgpa = kvm_register_read(vcpu, VCPU_REGS_R8);
}
#endif
and longmode must be zero if !CONFIG_X86_64:
This is not the first time this code is attempted to be changed.
Maybe adding an additional #ifdef..endif around the longmode
assignment and the if above will solve this for good?
Or maybe something like this:
#ifdef CONFIG_X86_64
if (!(is_long_mode(vcpu) cs_l == 1)) {
#else
if (1) {
#endif
param = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDX) 32) |
(kvm_register_read(vcpu, VCPU_REGS_RAX) 0x);
ingpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RBX) 32) |
(kvm_register_read(vcpu, VCPU_REGS_RCX) 0x);
outgpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDI) 32) |
(kvm_register_read(vcpu, VCPU_REGS_RSI) 0x);
}
else {
param = kvm_register_read(vcpu, VCPU_REGS_RCX);
ingpa = kvm_register_read(vcpu, VCPU_REGS_RDX);
outgpa = kvm_register_read(vcpu, VCPU_REGS_R8);
}
, to make it all explicit and obvious?
Thanks,
/mjt
--
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: [RFC PATCH] kvm: Enable -cpu option to hide KVM
01.06.2014 20:25, Alex Williamson цкщеу: The latest Nvidia driver (337.88) specifically checks for KVM as the hypervisor and reports Code 43 for the driver in a Windows guest when found. Removing or changing the KVM signature is sufficient to allow the driver to load. Hmm.. Why does it do such thing? Is it in order to prevent the driver to work in a virtualized windows, ie to prevent vga passthough to work? If that's the case, I think it is a lost game. Because they'll be adding more, cleverer, checks in the next version. Thanks, /mjt -- 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: [RFC PATCH] kvm: Enable -cpu option to hide KVM
02.06.2014 17:30, Alex Williamson wrote: On Mon, 2014-06-02 at 14:32 +0400, Michael Tokarev wrote: 01.06.2014 20:25, Alex Williamson wrote: The latest Nvidia driver (337.88) specifically checks for KVM as the hypervisor and reports Code 43 for the driver in a Windows guest when found. Removing or changing the KVM signature is sufficient to allow the driver to load. Hmm.. Why does it do such thing? Is it in order to prevent the driver to work in a virtualized windows, ie to prevent vga passthough to work? If that's the case, I think it is a lost game. Because they'll be adding more, cleverer, checks in the next version. Then they'll be pissing off more users and driving them to AMD by doing so. In any case, having the ability to hide the hypervisor seems to stand on it's own. What if we want to test whether a guest behavior is the result of a paravirtual interface? What if a user wants to hide the hypervisor in order to further reduce the exposure surface to the VM? There are reasons beyond an arms race with Nvidia to want a feature like this. Thanks, You answer as if I were strongly against the change. I'm not. What I'm against is about the reasoning. This way you're just accepting the arm race. Thanks, /mjt -- 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: [Qemu-devel] Massive read only kvm guests when backing file was missing
27.03.2014 20:14, Alejandro Comisario wrote: Seems like virtio (kvm 1.0) doesnt expose timeout on the guest side (ubuntu 12.04 on host and guest). So, how can i adjust the tinmeout on the guest ? After a bit more talks on IRC yesterday, it turned out that the situation is _much_ more interesting than originally described. The OP claims to have 10500 guests running off an NFS server, and that after NFS server downtime, the backing files were disappeared (whatever it means), so they had to restore those files. More, the OP didn't even bother to look at the guest's dmesg, being busy rebooting all 10500 guests. This solution is the most logical one, but i cannot apply it! thanks for all the responses! I suggested the OP to actually describe the _real_ situation, instead of giving random half-pictures, and actually take a look at the actual problem as reported in various places (most importantly the guest kernel log), and reoirt _those_ hints to the list. I also mentioned that, at least for some NFS servers, if a client has a file open on the server, and this file is deleted, the server will report error to the client when client tries to access that file, and this has nothing at all to do with timeouts of any kind. Thanks, /mjt -- 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: QEMU P2P migration speed
07.02.2014 19:32, Paolo Bonzini wrote: Il 07/02/2014 14:07, Andrey Korolyov ha scritto: Ok, I will do, but looks like libvirt version(1.0.2) in not relevant - it meets criteria set by debian packagers Then Debian's qemu packaging it's wrong, QEMU 1.6 or newer should conflict with libvirt 1.2.0. I've no idea when qemu breaks libvirt. I found out - just by a chance - that qemu 1.3+ breaks libvirt 1.0, and I stated this in the deps. But the thing that 1.6 requires libvirt 1.2 is news for me. I'll add this requiriment to the debian package. At any rate, there's no libvirt 1.0 in debian. Current stable has 0.9, and current testing has 1.2.1, and this version is also available in backports for stable. 1.2 was the first version past 0.9 which were backproted to stable. There's no other versions of libvirt in debian. So whomever installed that mess did that on their own, it is definitely not supported on debian ;) Thanks, /mjt and again, 'broken state' is not relevant to the libvirt state history, it more likely to be qemu/kvm problem. It is relevant, qemu introduced a new migration status before active (setup) and libvirt doesn't recognize it. That's why you need at least 1.2.0. Paolo -- 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: Fwd: Discard is not working
07.02.2014 04:03, Paolo Bonzini wrote: Michael, can you look at this? Paolo Messaggio originale From: chickenmar...@freenet.de To: kvm@vger.kernel.org Hello, after reading the invitation for some one-off questions without subscribing excuse my disturbing, please. At first my setup of host: * in general Debian Wheezy * Kernel: 3.11-0.bpo.2-amd64 (http://packages.debian.org/wheezy-backports/linux-image-3.11-0.bpo.2-amd64) * LVM 2.02.98 (http://packages.debian.org/jessie/lvm2) * thin-provisioning-tools 0.2.8-1 (http://packages.debian.org/jessie/thin-provisioning-tools) * Qemu-KVM: 1.7.0 (http://packages.debian.org/jessie/qemu-kvm) The new kernel and dirty things from Jessie are for working thin volumes with discard on my ssd. Everything's fine up to this point. Afterwards I start a guest (also Debian Wheezy) over the following command (over libvirt) as root (for test only): kvm [...] -drive file=/dev/ssd0/sarabi,if=none,id=drive-scsi0-0-0-0,format=raw,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 [...] Neither lsblk -D nor the try of fstrim ends positive. Both say that discard is not supported. I read that guests need at least kernel 3.4 to support discard (and virtio-scsi). But the same backports kernel 3.11 did not changed anything. This is the first time I tried to deal with discard. I've no discard-capable hardware, so never bothered to even look how it works (or not). I fired up my sample linux guest here, using 3.10 kernel on host and 3.2 kernel on guest, using something similar to what your command looks like: -device megasas,id=scsi0 \ -drive file=test.raw,if=none,id=sd0,discard=unmap \ -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=sd0 Note: this is a plain file (test.raw) on an ext4 filesystem on a device without discard support (regular rotational hard drive). In the guest, I can see discard granularity (4K) for that drive in lsblk -D output. fstrim does not error out, but I don't know if it actually does something or not. The same result can be observed with 3.10 kernel in guest, and with other scsi devices/drivers (eg lsi53c895a). However, when I export the same test.raw file using virtio, like this: -drive file=test.raw,if=virtio,discard=unmap it doesn't work: guest does not see the virtio drive as discardable. Did I understand something wrong? Is the command wrong? Are any requirements not met? So I've no idea what's going on here... ;) Thanks, /mjt -- 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
3.10.25 kernel behaves unstable as a qemu/kvm guest
Hello. This is just an initial/preliminary heads-up, maybe mis-directed, about a possible issue. I upgraded 2 machines today to 3.10.25, and both shows some.. strangeness within linux guests, which are also running 3.10.25. Revering to 3.10.24 in guests (compiled by the same compiler with the same options) or using older qemu/kvm (running with 1.7 now) fixes it. All guests are using virtio-net and virtio-blk. On one machine (prod), one guest (also prod) loads okay, but the networking is not functioning: no packets are received by the guest. I weren't able to debug this further at this time, so reverted back to an older qemu/kvm (1.1). On another machine (my home workstation where I can experiment), the same combination (3.10.25 on host guest and qemu 1.7) shows rather unstable behavour: about every 1/2 boot it stalls somewhere at the initial boot, either after initializing PNP, or initializing networking, or sometimes after initializing virtio, and the rest 1/2 it boots okay. When it stalls, it consumes no CPU, qemu process is responsive, the guest just does nothing. Like this: ... NET: Registering protocol family 2 TCP: established hash table entries: 8192 (order: 5, 131072 bytes) TCP bind hash table entries: 8192 (order: 5, 131072 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP: reno registered [at this point it hanged] (after this it normally registers UDP hash tables and other net stuff) I'm not sure yet what's going on. I understand that there are no guest-related changes in 3.10.25 (compared with .24), so there should be something else. The fact that it stalls randomly suggests there's some uninitialized value somewhere. I'll try to debug it further. Just a heads-up for now. Thanks, /mjt -- 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] KVM: PPC: Add devname:kvm aliases for modules
09.12.2013 19:01, Alexander Graf wrote: [] +++ b/arch/powerpc/kvm/44x.c @@ -231,3 +231,6 @@ static void __exit kvmppc_44x_exit(void) module_init(kvmppc_44x_init); module_exit(kvmppc_44x_exit); +#include linux/miscdevice.h +MODULE_ALIAS_MISCDEV(KVM_MINOR); +MODULE_ALIAS(devname:kvm); Usual thing is to add #includes into the beginning of a source file, not at the end of it, here and in all other similar places. Thanks, /mjt -- 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] kvm tools: fix boot of guests with more than 4gb of ram
24.06.2013 05:23, Sasha Levin wrote: queue = p9dev-vqs[vq]; queue-pfn = pfn; - p = guest_flat_to_host(kvm, queue-pfn * page_size); + p = guest_flat_to_host(kvm, (u64)queue-pfn * page_size); Maybe it's worth to use a common function for this, something like guest_queue_to_host(kvm, queue) ? Thanks, /mjt -- 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: Would a DOS on dovecot running under a VM cause host to crash?
21.06.2013 02:27, Hugh Davenport wrote: Hey All, I'm just wondering whether this is what caused my server to crash. If some activity in a virtual machine causes the host to crash, it is a serious bug in qemu/kvm which should be identified fixed. Thanks, /mjt -- 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: Unable to boot from SCSI disk
28.05.2013 01:25, Michael Tokarev wrote: [] but it is wheezy, which ships with seabios 1.7.0, which does not have scsi boot support. So in order to boot from scsi, you have to use old ,boot=on device property, which has been forward-ported from older qemu-kvm version to 1.1 version used on debian, because it was the only way at that time to boot from an scsi disk without resorting to using proprietary firmware. So, boot=on as the drive property should do the trick. But I'm not sure it is supported under libvirt. A small but maybe important followup. In unstable (and testing) version of debian, there is currently a more recent version of seabios (based on 1.7.2.x), which is able to boot from an scsi device just fine, and is compatible with qemu[-kvm] 1.1. You may try installing that one (just the seabios, nothing more, it does not have any dependencies whatsoever) and things should work in regular way. I'll prepare backports of all stuff in the very near future. BTW, why are you installing stuff on scsi? Is there some particular reason for that? This question is interesting still. Thanks, /mjt -- 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: Unable to boot from SCSI disk
28.05.2013 12:55, Paolo Bonzini wrote: Il 27/05/2013 23:25, Michael Tokarev ha scritto: [] but it is wheezy, which ships with seabios 1.7.0, which does not have scsi boot support. So in order to boot from scsi, you have to use old ,boot=on device property, which has been forward-ported from older qemu-kvm version to 1.1 version used on debian, because it was the only way at that time to boot from an scsi disk without resorting to using proprietary firmware. Why don't you forward port the SCSI boot patches? That'd be back-porting, not forward-porting. Anyway, in Debian we use a bit different approach usually. Namely, instead of backporting lots of stuff resulting in a BigMess(tm), we provide more recent upstream versions of the software but compiled for previous (stable) debian release. This mechanism is named debian backports. The stable release itself does not receive any large feature updates. It receives bugfixes, but only important ones. Besides, this scsi stuff doesn't really matter much -- it helps in some very rare situations (for example, sometimes this way it's easier to migrate from vmware to qemu), but that's about it. So I don't consider doing backports especially for scsi. If the new version backported to debian _also_ fixes scsi issues, that's just a side-effect. Thanks, /mjt -- 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] qemu-kvm: fix unmatched RAM alloction/free
Um, something's wrong with the Date. Care to resend with that fixed? Thanks, /mjt 18.01.2009 02:13, Xudong Hao wrote: mmap is used in qemu_vmalloc function instead of qemu_memalign(commit 7dda5dc8), so it should change qemu_vfree to munmap to fix a unmatched issue. [...] -- 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: Unable to boot from SCSI disk
28.05.2013 00:59, Paolo Bonzini wrote: Thank you Paolo for forwarding this email to me. Il 27/05/2013 22:53, Daniel Guillermo Bareiro ha scritto: Hi all! I'm trying libvirt and virt-manager and I found that if I install a virtual machine with SCSI disks, the installation is done without problems but when it boots, it is unable to boot from these disks. If I use bus=sata or bus=virtio, this problem does not happen. The default SCSI controller is buggy. Try using a newer model if available on your qemu-kvm version, for example virtio-scsi (CCing the Debian maintainer). Well, it isn't really that lsi emulation is _that_ buggy. It is enough for some stuff. But.. What is the version of SeaBIOS? but it is wheezy, which ships with seabios 1.7.0, which does not have scsi boot support. So in order to boot from scsi, you have to use old ,boot=on device property, which has been forward-ported from older qemu-kvm version to 1.1 version used on debian, because it was the only way at that time to boot from an scsi disk without resorting to using proprietary firmware. So, boot=on as the drive property should do the trick. But I'm not sure it is supported under libvirt. BTW, why are you installing stuff on scsi? Is there some particular reason for that? Thanks, /mjt -- 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: Fwd: Booting physically installed Windows while in Arch (AHCI support in OVMF?)
06.05.2013 00:42, Evert Heylen wrote: Please, any help? I think the easiest way is to convert your existing system from UEFI back to regular bios + MBR. For that, you need to disable UEFI boot in bios and convert GPT to MBR on the HDD. This is because, as you figured, ahci support in OVMF isn't exactly working, and because generally, UEFI emulation and UEFI support as whole is a bit too young still. /mjt I'm currently in such a state I won't be able to sleep well before I make some progress on this. I've already described my situation quite precisly, if one needs even more information, just ask. I've now also tried with a separate img containing DUET, so I can use the default seabios to boot DUET, which can boot Windows in UEFI mode. However, DUET just doesn't see my disk at all, be it in IDE or AHCI mode. If I boot the same img *physically* (from a usb), I can enter DUET and I can see my physical disk (which is running in AHCI mode). So I guess this is an issue with KVM/QEMU. Any ideas would be greatly appreciated. On Sun, Apr 28, 2013 at 6:29 PM, Evert Heylen everthey...@gmail.com wrote: Hi all, My situation is the following: My PC (x64) has an UEFI capable motherboard (ASRock Z77). On my hard drive (which is GPT formatted ofc), I have Windows 7 installed on /dev/sda3 and Arch Linux on /dev/sda2. I can boot both OS'es. However, I would like to boot Windows while in Arch, using KVM. I'm using the OVMF images. I tried it right away with this command: qemu-system-x86_64 -enable-kvm -smp 4 -cpu host -m 4096 -hda /dev/sda -L /path/to/ovmf/ It doesn't work. When booting in safe mode in windows, I can see that windows fails when trying to load CLASSPNP.sys . After some googling I found out that it might be because qemu 'mounts' the drive in IDE mode, while windows expects it to be in AHCI mode (because it was installed in AHCI mode). Then, after some more googling, I tried this command, which should (correct me if I'm wrong) mount the drive in AHCI mode. qemu-system-x86_64 -enable-kvm -smp 4 -cpu host -m 4096 -L /path/to/ovmf -device ahci,id=ahci0 -drive if=none,file=/dev/sda,format=raw,id=drive-sata0-0-0 -device driver=ide-drive,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 However, with this command OVMF doesn't seem to recognise any drive at all, the 'Boot from file' screen is empty. So, I would like to know if OVMF supports AHCI, and if it doesn't, do you have any other ideas? I know it's generally not a good idea to boot a physically installed OS in a vm, but I want to try it anyway. Thanks, Evert -- 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 -- 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 save vcpupin to xml file?
16.03.2013 22:15, Anthony Acquanita wrote: I keep running vcpupin from the command line and can't seem to find out how to write this out to the XML with doing an virsh edit. [...] You're on a wrong list. Neither KVM nor Qemu has anything to do with virsh or XML. Neither _understand_ xml to start with. If you're using libvirt, ask on their list. /mjt -- 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: Win2003 disk corruption with kvm-1.0. and virtio
[Please stop top-posting. Thank you] 13.02.2013 20:03, we...@zackbummfertig.de wrote: there are known problems, WHEN I/O native and cache=writethrough. On I/O native put cache to none otherwise your data can get broken. Check Redhat Pages for that. Which problem is that? And what is I/O native ? Maybe you mean aio, not I/O ? If the talk is about aio=native, that mode does not work for regular files, it gets downgraded to aio=threads automatically. So there should be nothing to change already. Please elaborate. /mjt -- 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: BSoD, HAL.DLL
14.01.2013 21:40, Sean Kennedy wrote: I continue to get bluescreens on an XP virtual machine running on CentOS 6.3 x86_64 using VirtIO drivers. QEMU: qemu-kvm-0.12.1.2-2.295.el6.x86_64 KERNEL: Linux vmhost1 2.6.32-279.1.1.el6.x86_64 #1 SMP Tue Jul 10 13:47:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Please take this to RHEL support. Their kernel and qemu-kvm are ancient but very heavily patched, and it's nearly impossible to understand what's going on there. Thanks, /mjt -- 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: [Qemu-devel] [PATCH] kvm: Set default accelerator to kvm if the host supports it
On 02.10.2012 11:46, Markus Armbruster wrote: Daniel P. Berrange berra...@redhat.com writes: IMHO, default to KVM, fallback to TCG is the most friendly default behaviour. Friendly perhaps, generating an infinite series of questions why is my guest slow as molasses? certainly. With a warning about switching to slow emulation mode because .. printed at startup that becomes a non-issue, because there's no reason to ask more questions about why it is slow - it already said why. Yes some may try to ask what to do, which is different. Every howto nowadays mentions kvm modules and /dev/kvm device permissions. And for each instance of the question, there's an unknown number of users who give QEMU a quick try, screw up KVM unknowingly, observe the glacial speed, and conclude it's crap. This is, again, I think, unfair. With the warning message it becomes more or less obvious. If you're talking about users who run it with -daemonize argument - this is a) stupid to do when TRYING it out, so it's not a big deal to lose another stupid user, and b) qemu should init everything first and throw all warnings and fatal errors before daemonizing, if this is not the case it should be fixed in the code. And if you're talking about management software (libvirt and others), it controls all the required privileges already and explicitly requests acceleration and other stuff. So the best thing to do is what Daniel, Aurelien, Paolo and others are suggested: accel=kvm:tcg with a warning. Thanks, /mjt -- 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: Error: KVM Guest with virtio network driver loses network connectivity
On 03.10.2012 14:32, hung -cuncon wrote: Hi all, I setup Host with centos 6.0 - 64bits, Guest with centos5.3 - 64bits (kernel updated), I have installed qemu-kvm-tool http://rpmfind.net/linux/RPM/centos/updates/6.3/x86_64/Packages/qemu-kvm-tools-0.12.1.2-2.295.el6_3.1.x86_64.html with Bug Fix: 804578 Please address this to redhat support staff. It is unrealistic for people on this list to be able to deal with ancient and heavily patched kernel and qemu-kvm where only redhat knows the changes they've made. Thank you. /mjt -- 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: qemu-kvm: remove boot=on|off drive parameter compatibility
01.10.2012 17:36, Jan Kiszka wrote: On 2012-10-01 15:31, Marcelo Tosatti wrote: Default nic is rtl8139 vs. e1000. Config file (as suggested earlier on this thread). If you need to append -config bla, you can also specify the desired NIC explicitly - I see no value in the former. If we decide to mangle a qemu-kvm command line before calling QEMU binaries, we can adjust this variation there. Otherwise it's the same as with all those -kvm*: Scripts/management tools will need adjustment. I don't think there's a need to manage this rtl8139 at all at this level. Let's declare that qemu-kvm 1.3+ will switch from rtl8139 to e1000 by default as a more suitable in modern world, -- the same way as qemu did the switch earlier, and be done with that. I think. Note that this is JUST for -net nic users, which should be the minority (proper usage is -device rtl8139 or -device e1000, with explicit model). Thanks, /mjt -- 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: Can't use USB devices in their designated applications on Windows Vista guest
On 18.09.2012 09:56, Dirk Heinrichs wrote: Hi, I have a really strange problem using USB devices in a Windows Vista (32bit) guest. After adding a USB device (an Adroid phone or a GPS navigation device) to the guest, Vista starts to install the driver(s) for the new device just as it would do on real hardware. However, when it comes to actually use that device in the Windows application that came with it (for example Samsung Kies in case of the Android phone), those applications do not recognize the device and keep waiting for the device to be connected forever. This appears to be the same as https://bugs.launchpad.net/bugs/1033727 , FWIW. /mjt -- 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 slow boot
On 16.08.2012 14:47, Richard Davies wrote: http://marc.info/?l=qemu-develm=134304194329745 We have been experiencing this problem for a while now too, using qemu-kvm (currently at 1.1.1). Unfortunately, hv_relaxed doesn't seem to fix it. The following command line produces the issue: qemu-kvm -nodefaults -m 4096 -smp 8 -cpu host,hv_relaxed -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda test.img Just one question: did you try explicitly using hugepages? For that, - reserve some amount of hugepages (echo something /proc/sys/vm/nr_hugepages), - mount hugetlbfs to somewhere, like, /dev/hugetlbfs - use -mem-path=/dev/hugetlbfs qemu option This may also reduce your lock contention. Sure, hugepages have some minus sides too, but I think it is worth to try anyway - for a single VM or for whole lot of VMs (for that you'll have to reserve much more memory after host boot). /mjt -- 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: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment
On 27.08.2012 22:56, Blue Swirl wrote:
[]
+static uint32_t slow_bar_readb(void *opaque, target_phys_addr_t addr)
+{
+AssignedDevRegion *d = opaque;
+uint8_t *in = d-u.r_virtbase + addr;
Don't perform arithmetic with void pointers.
There are a few places in common qemu code which does this for a very
long time. So I guess it is safe now.
/mjt
--
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: /dev/kvm not sufficiently restricted, and in ways I didn't think were possible
On 28.08.2012 00:11, Henry Cejtin wrote: I'm completely confused about access to /dev/kvm. In particular, it looks like it is too open to access, but in a way that I don't understand. On my machine, /dev/kvm is owned by root.root and mode 660. Here is the output of ls: % ls -l /dev/kvm crw-rw+ 1 root root 10, 232 Aug 24 15:03 /dev/kvm Note the plus sign in there (+). Run getfacl on this file. Most likely it is consolekit/policykit which has a rule to add ACLs to some devices (audio etc) for a current session user. /mjt -- 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] qemu-kvm-1.2.0-rc1
On 24.08.2012 23:12, Marcelo Tosatti wrote: qemu-kvm-1.2.0-rc1 is now available. This release is based on the upstream qemu 1.2.0-rc1, plus device assignment. Is there a corresponding tag in the git tree? Thanks, /mjt -- 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: qemu-kvm 1.1.1 hangs using 100% CPU when using ES1370 emulation
Hello Mike, Vassili.
On 23.08.2012 20:16, Mike Gerber wrote:
Hi,
I'm using a KVM guest to stream audio using darkice to an icecast2 server on
the
same guest. The guest uses an emulated ES1370 sound card to capture the host's
audio input (ASUS Xonar DX) using the ALSA backend. After 1 or 2 days, the
qemu-kvm process locks up, using up 100% CPU, apparently spinning in
audio/rate_template.h (See gdb session below).
Do you have any advice on how to solve this problem?
I haven't tried the -no-kvm-* switches, please advice if that would be useful
in this case. Unfortunately it takes up to 2 days for the bug to happen, so
trying all possible configurations is a bit time-consuming.
More information here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685353
Mike, I noticed your work trying to debug the issue, and you finally
succeeded to get a usable backtrace which is good. I just weren't
able to get to you earlier.
Can you also check whenever hda emulated device also shows this issue?
Vassili, can you take a look please - the prob appears to be somehow
sound-related..
Thank you!
/mjt
cpu model: AMD Turion(tm) II Neo N40L Dual-Core Processor
qemu-kvm version: 1.1.1 (Debian package by Michael Tokarev),
happened also with 1.1.0
host: Debian wheezy, 3.2.23, x86_64
guest: Debian wheezy, 3.2.23, x86_64
/usr/bin/kvm -S -M pc-1.1 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1
-name mp3 -uuid 25d2b76c-9533-c55a-b5e2-07da213886f1 -nodefconfig
-nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/mp3.monitor,server,nowait
-mon
chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
-device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=/dev/vg_vms/lv_mp3,if=none,id=drive-virtio-disk0,format=raw -device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-netdev tap,fd=20,id=hostnet0 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b1:e7:80,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0
-vnc 127.0.0.1:0 -vga cirrus -device ES1370,id=sound0,bus=pci.0,addr=0x6
-device
i6300esb,id=watchdog0,bus=pci.0,addr=0x7 -watchdog-action reset -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
gdb output (truncated, full output at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685353)
(gdb) info threads
Id Target Id Frame
2Thread 0x7fccec446700 (LWP 19893) kvm 0x7fccf3f5fcec in
__lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
* 1Thread 0x7fccf7c8c8e0 (LWP 19892) kvm st_rate_flow
(opaque=0x7fccf9248f40, ibuf=0x7fccf9150320, obuf=0x7fccf91975b0,
isamp=isamp@entry=0x7fffe9ff6550,
osamp=osamp@entry=0x7fffe9ff6554) at
/tmp/buildd/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:75
(gdb) thread apply all bt full
Thread 2 (Thread 0x7fccec446700 (LWP 19893)):
#0 0x7fccf3f5fcec in __lll_lock_wait () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x7fccf3f5b339 in _L_lock_926 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#2 0x7fccf3f5b15b in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#3 0x7fccf7f18c29 in qemu_mutex_lock
(mutex=mutex@entry=0x7fccf8c39a80) at
/tmp/buildd/qemu-kvm-1.1.1+dfsg/qemu-thread-posix.c:54
err = optimized out
__func__ = qemu_mutex_lock
#4 0x7fccf7f729f0 in qemu_mutex_lock_iothread () at
/tmp/buildd/qemu-kvm-1.1.1+dfsg/cpus.c:897
No locals.
#5 0x7fccf7f9a0b6 in kvm_cpu_exec (env=env@entry=0x7fccf902d510) at
/tmp/buildd/qemu-kvm-1.1.1+dfsg/kvm-all.c:1268
run = 0x7fccf7d8
ret = optimized out
run_ret = 0
#6 0x7fccf7f71591 in qemu_kvm_cpu_thread_fn (arg=0x7fccf902d510) at
/tmp/buildd/qemu-kvm-1.1.1+dfsg/cpus.c:752
env = 0x7fccf902d510
r = optimized out
#7 0x7fccf3f58b50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#8 0x7fccf3ca370d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#9 0x in ?? ()
No symbol table info available.
Thread 1 (Thread 0x7fccf7c8c8e0 (LWP 19892)):
#0 st_rate_flow (opaque=0x7fccf9248f40, ibuf=0x7fccf9150320,
obuf=0x7fccf91975b0, isamp=isamp@entry=0x7fffe9ff6550,
osamp=osamp@entry=0x7fffe9ff6554)
at /tmp/buildd/qemu-kvm-1.1.1+dfsg/audio/rate_template.h:75
rate = 0x7fccf9248f40
istart = 0x7fccf9148810
iend = 0x7fccf91730c0
ostart = 0x7fccf91975b0
oend = 0x7fccf9197870
ilast = {l = -50003968, r = 171704320}
icur = optimized out
out = optimized out
Re: [Qemu-devel] x86, nops settings result in kernel crash
On 20.08.2012 21:13, Tomas Racek wrote: [] Can we trim the old, large and now not-so-relevant discussion please? ;) I can provide you with more different traces if it can help. But I thought that maybe it will be more useful for you to try it on your own. So I've prepared some minimal debian installation which you could download here (apx 163M bzipped): http://fi.muni.cz/~xracek/debian.img.bz2 Password: root/asdfgh Here is my config for guest kernel: http://fi.muni.cz/~xracek/config I use qemu-kvm -m 1500 -hda debian.img -kernel linux/arch/x86/boot/bzImage -append root=/dev/sda1 Um. I'd expect the image to be self-contained, no external kernel. I wanted to do a quick test to see if it fails on my machine too, d/loaded debian.img.bz2 but there's no kernel. So.. no quick test for you ;) After logging in just run sh runtest.sh. This leads to crash in my case (host: Intel Core i5-2540M, kernel 3.5.2-1.fc17.x86_64, qemu 1.0.1). With all the above, this runtest.sh is informationally equal to your disk image. /mjt -- 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-enabled Linux 3.2 won't boot in kvm
19.08.2012 06:04, Neal Murphy пишет: I've been using KVM for a few years now. I've had little trouble with it. But now it's got me treed. I cannot get a KVM-enabled Linux 3.2.27 kernel to boot in qemu-kvm unless I specify '-no-kvm'. I've used a similarly-built and - configured 2.6.35 kernel without trouble. The console shows Probing EDD (edd=off to disable)... ok Decompressing Linux... Parsing ELF... done. Booting the kernel. And there it hangs, the kvm program at 100% CPU usage. This is on Debian Squeeze, either using Debian's kvm package or using a freshly built kvm 1.1.1. The kernel does boot using qemu or booting on real hardware. And I've no trouble booting Linux 2.6.35. Clearly I've missed something, but I've no idea what that might be. Any ideas? You missed to provide the qemu/kvm command line you're using. As for the sympthoms, you may be hitting http://bugs.debian.org/680719 but it is difficult to say without much more details. /mjt -- 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: [Qemu-devel] TSC in qem[-kvm] 1.1+ and in-kernel irqchip
On 13.08.2012 17:07, Jan Kiszka wrote: [] The bisecion leads to this commit: commit 17ee47418e65b1593defb30edbab33ccd47fc1f8 Merge: 13b0496 5d17c0d Author: Jan Kiszka jan.kis...@siemens.com Date: Tue Apr 10 16:26:23 2012 +0200 Merge commit '5d17c0d2df4998598e6002b27b8e47e792899a0f' into queues/qemu-merge [] Cc'ing Jan for help. The short story: tsc timer calibration broke in 1.1+ with in-kernel irqchip (only) for several apps (seabios and grub are two examples), the time is ticking about 100 times faster. In grub the timer is calibrated using pit. The above commit is the result of bisection. Did the versions you tested include the commit 0cdd3d1444 (kvm: i8254: Fix conversion of in-kernel to userspace state)? While bisecting I didn't have this commit applied, since it were applied past (qemu)-1.1. It is included into qemu-kvm 1.1.0 (as 960d355dc60d9), and that version behaves _exactly_ the same - the time in grub is ticking 100 times faster. I mentioned in this thread that the problem persists in current qemu (and qemu-kvm) git too. I can repeat the bisection with this commit applied after the above bad commit. Should I? Thanks, /mjt -- 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 uq/master] kvm: i8254: Finish time conversion fix
On 13.08.2012 22:18, Jan Kiszka wrote: 0cdd3d1444 fixed reading back the counter load time from the kernel while assuming the kernel would always update its load time on writing the state. That is only true for channel 1, and so pit_get_channel_info returned wrong output pin states for high counter values. Fix this by applying the offset also on kvm_pit_put. For this purpose, we cache the clock offset in KVMPITState, only updating it on VM state changes or when we write the state while the VM is stopped. Wug. The fix (consisting of two halves) appears to be quite messy. Is it a (temporary) workaround or a real solution? And yes, this second half fixes the reported issue with grub timekeeping, and should fix the seabios problem as well (so it shouldn't be necessary to mess with timekeeping in seabios anymore). Thank you Jan! /mjt -- 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: [Qemu-devel] TSC in qem[-kvm] 1.1+ and in-kernel irqchip
On 12.08.2012 12:10, Gleb Natapov wrote:
[]
Any chance to bisect it?
The bisecion leads to this commit:
commit 17ee47418e65b1593defb30edbab33ccd47fc1f8
Merge: 13b0496 5d17c0d
Author: Jan Kiszka jan.kis...@siemens.com
Date: Tue Apr 10 16:26:23 2012 +0200
Merge commit '5d17c0d2df4998598e6002b27b8e47e792899a0f' into
queues/qemu-merge
Conflicts:
hw/pc.c
diff --cc Makefile.target
index 33a7255,1bd25a8..32c8e42
--- a/Makefile.target
+++ b/Makefile.target
@@@ -245,13 -244,8 +245,13 @@@ obj-i386-y += pci-hotplug.o smbios.o wd
obj-i386-y += debugcon.o multiboot.o
obj-i386-y += pc_piix.o
obj-i386-y += pc_sysfw.o
- obj-i386-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o
+ obj-i386-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o
kvm/i8254.o
obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+obj-i386-y += testdev.o
+obj-i386-y += acpi.o acpi_piix4.o
+
+obj-i386-y += i8254_common.o i8254.o
+obj-i386-$(CONFIG_KVM_DEVICE_ASSIGNMENT) += device-assignment.o
# shared objects
obj-ppc-y = ppc.o ppc_booke.o
diff --cc hw/pc.c
index 74c19b9,bb9867b..feb6ef3
--- a/hw/pc.c
+++ b/hw/pc.c
@@@ -1116,8 -1118,12 +1122,12 @@@ void pc_basic_device_init(ISABus *isa_b
qemu_register_boot_set(pc_boot_set, *rtc_state);
- pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq);
+ if (kvm_irqchip_in_kernel()) {
+ pit = kvm_pit_init(isa_bus, 0x40);
+ } else {
+ pit = pit_init(isa_bus, 0x40, pit_isa_irq, pit_alt_irq);
+ }
-if (hpet) {
+if (hpet !(kvm_enabled() kvm_irqchip_in_kernel())) {
/* connect PIT to output control line of the HPET */
qdev_connect_gpio_out(hpet, 0, qdev_get_gpio_in(pit-qdev, 0));
}
Note this commit itself talks about pit and irqchip.
But I don't know what does it mean.
Cc'ing Jan for help. The short story: tsc timer calibration
broke in 1.1+ with in-kernel irqchip (only) for several
apps (seabios and grub are two examples), the time is ticking
about 100 times faster. In grub the timer is calibrated
using pit. The above commit is the result of bisection.
Thanks,
/mjt
--
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: [Qemu-devel] TSC in qem[-kvm] 1.1+ and in-kernel irqchip
On 10.08.2012 11:33, Gleb Natapov wrote: On Thu, Aug 09, 2012 at 10:27:43PM +0400, Michael Tokarev wrote: As a follow-up to the patch tsc: use kvmclock for calibration. There's another problem reported by several users. The sympthom is that grub does not show boot menu, it boots default entry right away without any pause. After quite some debugging it turned out to be TSC issue. Grub uses tsc for its timeout handling. When setting timeout to some very large value (1), I can see the counter is ticking backwards at a very high speed, ticking from 1 to 0 in about 5 seconds. Running kvm -cpu host,-tsc forces grub to use rtc clocksource, and the problem goes away. Can you try -no-kvm-pit-reinjection please. It does not help. With -no-kvm-pit-reinjection, the time in grub is ticking about 1000 times faster still, just like without. The most interesting thing is that this is a problem new for qemu-kvm 1.1 (and is still present in current git), 1.0 version had no such issue. And it only happens when in-kernel irqchip is enabled -- running with -no-kvm-irqchip also fixes the grub problem, so that tsc starts counting correctly for grub again. 1.0 work on the same kernel 1.1 doesn't? Yes. This issue does not look like kernel-dependent - it happens the same way on 3.0, 3.2 and 3.5 kernels. Note that upstream qemu 1.1+ is also affected, when used with -machine pc,kernel_irqchip=on. /mjt -- 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
TSC in qem[-kvm] 1.1+ and in-kernel irqchip
As a follow-up to the patch tsc: use kvmclock for
calibration.
There's another problem reported by several users.
The sympthom is that grub does not show boot menu,
it boots default entry right away without any pause.
After quite some debugging it turned out to be
TSC issue. Grub uses tsc for its timeout handling.
When setting timeout to some very large value
(1), I can see the counter is ticking backwards
at a very high speed, ticking from 1 to 0 in
about 5 seconds.
Running kvm -cpu host,-tsc forces grub to use
rtc clocksource, and the problem goes away.
The most interesting thing is that this is a
problem new for qemu-kvm 1.1 (and is still
present in current git), 1.0 version had no
such issue. And it only happens when in-kernel
irqchip is enabled -- running with -no-kvm-irqchip
also fixes the grub problem, so that tsc starts
counting correctly for grub again.
Gerd mentioned mis-calibration of bios timer
when host is heavily loaded. I tested grub on
my workstation today which was completely idle,
no other processes running.
It smells like a bug in kvm somewhere. And it
happens when I explicitly pin kvm to a single
core, so tsc should tick correctly even if its
syncronization is broken between cores.
Current qemu also has this issue (since 1.1),
since it also has in-kernel irqchip support now.
FWIW, here's the TSC calibration routine from
grub:
/* Calibrate the TSC based on the RTC. */
static void
calibrate_tsc (void)
{
/* First calibrate the TSC rate (relative, not absolute time). */
grub_uint64_t start_tsc;
grub_uint64_t end_tsc;
start_tsc = grub_get_tsc ();
grub_pit_wait (0x);
end_tsc = grub_get_tsc ();
tsc_ticks_per_ms = grub_divmod64 (end_tsc - start_tsc, 55, 0);
}
Thanks,
/mjt
--
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: TSC in qem[-kvm] 1.1+ and in-kernel irqchip
On 10.08.2012 00:47, Marcelo Tosatti wrote:
[]
calibrate_tsc (void)
{
/* First calibrate the TSC rate (relative, not absolute time). */
grub_uint64_t start_tsc;
grub_uint64_t end_tsc;
start_tsc = grub_get_tsc ();
grub_pit_wait (0x);
end_tsc = grub_get_tsc ();
tsc_ticks_per_ms = grub_divmod64 (end_tsc - start_tsc, 55, 0);
}
Emulation of grub_pit_wait sequence by in-kernel PIT is probably broken.
This is grub_pit_wait():
#define TIMER2_REG_CONTROL 0x42
#define TIMER_REG_COMMAND 0x43
#define TIMER2_REG_LATCH0x61
#define TIMER2_SELECT 0x80
#define TIMER_ENABLE_LSB0x20
#define TIMER_ENABLE_MSB0x10
#define TIMER2_LATCH0x20
#define TIMER2_SPEAKER 0x02
#define TIMER2_GATE 0x01
void
grub_pit_wait (grub_uint16_t tics)
{
/* Disable timer2 gate and speaker. */
grub_outb (grub_inb (TIMER2_REG_LATCH) ~ (TIMER2_SPEAKER | TIMER2_GATE),
TIMER2_REG_LATCH);
/* Set tics. */
grub_outb (TIMER2_SELECT | TIMER_ENABLE_LSB | TIMER_ENABLE_MSB,
TIMER_REG_COMMAND);
grub_outb (tics 0xff, TIMER2_REG_CONTROL);
grub_outb (tics 8, TIMER2_REG_CONTROL);
/* Enable timer2 gate, keep speaker disabled. */
grub_outb ((grub_inb (TIMER2_REG_LATCH) ~ TIMER2_SPEAKER) | TIMER2_GATE,
TIMER2_REG_LATCH);
/* Wait. */
while ((grub_inb (TIMER2_REG_LATCH) TIMER2_LATCH) == 0x00);
/* Disable timer2 gate and speaker. */
grub_outb (grub_inb (TIMER2_REG_LATCH) ~ (TIMER2_SPEAKER | TIMER2_GATE),
TIMER2_REG_LATCH);
}
QEMU PIT emulation is also affected by miscalibration.
Please provide steps to reproduce.
I mean verbose on the steps (does it happen always when setting timeout=1,
how to set timeout=1, etc).
untested:
mkdir /tmp/grub
cd /tmp/grub
mkdir boot boot/grub
cat boot/grub/grub.cfg EOF
set timeout=1
menuentry 'test' {
echo booted:; read line
}
EOF
grub-mkrescue -o ../grub.iso .
kvm -cdrom ../grub.iso
This should show a menu with single entry test,
and wait for 1 seconds, with a countdown.
1 is enough to actually see it -- with reasonable
timeout it isn't easy to see that it displays the
menu, instead it immediately goes to the booting,
displaying the booted: line.
kvm -cdrom ../grub.iso -cpu host,-tsc
kvm -cdrom ../grub.iso -no-kvm-irqchip
...
-- these works fine.
Tried with grub from debian wheezy (1.99-22.1) and
from ubuntu 12.04, but i guess it should be the
same with various versions of grub.
Thanks!
/mjt
--
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
linux guest + nfsserver + virtio + vhost + vnet_hdr = tons of OOMs
I were debugging an unrelated issue today (in nfs server), and noticed that the above combination, when doing lots of read requests from an nfs client, quickly reaches OOM condition which gets triggered very often. I used a 512-Mb guest with 32bit kernel inside. By doing a cp of a large directory from it, in less than a minute, the guest starts OOMing like crazy. There's no other apps running in it, except shell and a few gettys. Removing vnet_hdr is enough to stop the OOMs from happening. I can only guess nfs server isn't a requiriment, but is an easy reproducer (a way to generate some network I/O load). This happens with 3.0 and 3.2 stable kernels (in guest). It does not happen with 2.6.32 obviously, as it lacks vhost-net. The OOMs appears to be warnings only, at least the NFS works fine without externally visible errors. Example: [ 1263.216077] nfsd: page allocation failure: order:1, mode:0x20 [ 1263.216722] Pid: 596, comm: nfsd Tainted: G S W 3.0.0-i686 #3.0.31 [ 1263.218222] Call Trace: [ 1263.218523] [c10bf6f8] ? warn_alloc_failed+0x98/0x100 [ 1263.219025] [c10c0480] ? __alloc_pages_nodemask+0x4d0/0x770 [ 1263.219025] [c10efeb7] ? cache_alloc_refill+0x2e7/0x510 [ 1263.219025] [c10f0434] ? __kmalloc+0x124/0x140 [ 1263.219025] [c1249ebe] ? pskb_expand_head+0x12e/0x210 [ 1263.219025] [c1249ebe] ? pskb_expand_head+0x12e/0x210 [ 1263.219025] [e08f2541] ? virtqueue_add_buf_gfp+0x191/0x340 [virtio_ring] [ 1263.219025] [c124a41d] ? __pskb_pull_tail+0x4d/0x2b0 [ 1263.219025] [e090f477] ? start_xmit+0x137/0x330 [virtio_net] [ 1263.219025] [c125377a] ? dev_hard_start_xmit+0x29a/0x610 [ 1263.219025] [c10b934e] ? find_get_pages_contig+0x2e/0x110 [ 1263.219025] [c111beab] ? splice_to_pipe+0xeb/0x210 [ 1263.219025] [c126a9ba] ? sch_direct_xmit+0xba/0x180 [ 1263.219025] [c1253c2c] ? dev_queue_xmit+0x13c/0x530 [ 1263.219025] [c1281735] ? ip_queue_xmit+0x55/0x3d0 [ 1263.219025] [c128200b] ? ip_finish_output+0x13b/0x310 [ 1263.219025] [c1281418] ? ip_local_out+0x18/0x20 [ 1263.219025] [c1294bc6] ? tcp_transmit_skb+0x386/0x810 [ 1263.219025] [c12971c8] ? tcp_write_xmit+0x198/0x980 [ 1263.219025] [c1297a14] ? __tcp_push_pending_frames+0x24/0x90 [ 1263.219025] [c128b2b8] ? tcp_sendpage+0x558/0x5f0 [ 1263.219025] [c111afb0] ? page_cache_pipe_buf_release+0x10/0x10 [ 1263.219025] [c128ad60] ? tcp_sendmsg+0xb50/0xb50 [ 1263.219025] [c12a9789] ? inet_sendpage+0x69/0x110 [ 1263.219025] [c111b295] ? splice_direct_to_actor+0x175/0x1e0 [ 1263.219025] [c12a9720] ? inet_dgram_connect+0x80/0x80 [ 1263.219025] [c1240f6e] ? kernel_sendpage+0x4e/0x90 [ 1263.219025] [e0a74d39] ? svc_send_common+0xc9/0x120 [sunrpc] [ 1263.219025] [e0a74df6] ? svc_sendto+0x66/0x1e0 [sunrpc] [ 1263.219025] [e0c00519] ? nfsd4_encode_read+0xf9/0x200 [nfsd] [ 1263.219025] [e0c00420] ? nfsd4_encode_readdir+0x1e0/0x1e0 [nfsd] [ 1263.219025] [e0bfa93c] ? nfsd4_encode_operation+0x5c/0x170 [nfsd] [ 1263.219025] [c110b6b4] ? dput+0x14/0x140 [ 1263.219025] [e0bfae0e] ? nfsd4_release_compoundargs+0x1e/0x50 [nfsd] [ 1263.219025] [e0bf8b58] ? nfsd4_proc_compound+0x1e8/0x490 [nfsd] [ 1263.219025] [e0bffccf] ? nfs4svc_decode_compoundargs+0x26f/0x340 [nfsd] [ 1263.219025] [e0a74ff6] ? svc_tcp_sendto+0x36/0xa0 [sunrpc] [ 1263.219025] [e0a7e278] ? svc_send+0x88/0xc0 [sunrpc] [ 1263.219025] [e0a719b8] ? svc_process+0x228/0x760 [sunrpc] [ 1263.219025] [e0be998c] ? nfsd+0xac/0x140 [nfsd] [ 1263.219025] [c1032fc0] ? complete+0x40/0x60 [ 1263.219025] [e0be98e0] ? nfsd_svc+0x1d0/0x1d0 [nfsd] [ 1263.219025] [c105d054] ? kthread+0x74/0x80 [ 1263.219025] [c105cfe0] ? kthread_worker_fn+0x160/0x160 [ 1263.219025] [c12e7b76] ? kernel_thread_helper+0x6/0xd [ 1263.219025] Mem-Info: [ 1263.219025] DMA per-cpu: [ 1263.219025] CPU0: hi:0, btch: 1 usd: 0 [ 1263.219025] CPU1: hi:0, btch: 1 usd: 0 [ 1263.219025] Normal per-cpu: [ 1263.219025] CPU0: hi: 186, btch: 31 usd: 63 [ 1263.219025] CPU1: hi: 186, btch: 31 usd: 155 [ 1263.219025] active_anon:773 inactive_anon:8 isolated_anon:0 [ 1263.219025] active_file:8114 inactive_file:114260 isolated_file:0 [ 1263.219025] unevictable:0 dirty:5 writeback:0 unstable:0 [ 1263.219025] free:1982 slab_reclaimable:940 slab_unreclaimable:1363 [ 1263.219025] mapped:713 shmem:14 pagetables:74 bounce:0 [ 1263.219025] DMA free:2312kB min:84kB low:104kB high:124kB active_anon:0kB inactive_anon:0kB active_file:16kB inactive_file:11392kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15788kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:52kB slab_unreclaimable:1880kB kernel_stack:16kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 1263.219025] lowmem_reserve[]: 0 492 492 492 [ 1263.219025] Normal free:5616kB min:2792kB low:3488kB high:4188kB active_anon:3092kB inactive_anon:32kB active_file:32440kB inactive_file:445648kB unevictable:0kB isolated(anon):0kB
Re: [Qemu-devel] [PATCH] kvm: align ram_size to page boundary
On 17.06.2012 17:14, Avi Kivity wrote:
On 06/17/2012 04:06 PM, Blue Swirl wrote:
strtosz() is much too general. We could do it in vl.c without trouble.
However, it takes away our ability to emulate a 640k should be enough
for everyone machine.
Then how about current max of target page sizes: 8k? No machine should
want less than that.
Okay by me, but I can hear the we-should-have-a-generic-mechanism crowd
charging their megaphone batteries.
So, is there some bottom line in that? I think I'll put a (temp)
fix/workaround for the debian package to require memory size to be
a multiple of 8K, and to produce a warning if that requiriment hasn't
met.
Something like this:
diff --git a/vl.c b/vl.c
index 5d9fc55..db98a4a 100644
--- a/vl.c
+++ b/vl.c
@@ -2671,7 +2675,15 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, qemu: ram size too large\n);
exit(1);
}
-ram_size = value;
+#define RAM_SIZE_GRANULARITY (8*1024)
+ram_size = value / RAM_SIZE_GRANULARITY;
+ram_size *= RAM_SIZE_GRANULARITY;
+if (ram_size != value) {
+fprintf(stderr,
+warning: requested memory size (% PRIu64
bytes)
+truncated to % PRIu64 bytes\n,
+value, (uint64_t)ram_size);
+}
break;
}
case QEMU_OPTION_mempath:
With this patch, running
qemu-system-x86_64 -m 1.4g
produces the following:
warning: requested memory size (1503238553 bytes) truncated to 1503232000 bytes
Thanks,
/mjt
--
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] qemu-kvm-1.1.0
On 03.07.2012 03:32, Marcelo Tosatti wrote: qemu-kvm-1.1.0 is now available. This release is based on the upstream qemu 1.1.0, plus kvm-specific enhancements. Please see the original QEMU 1.1.0 release announcement [1] for details. Why the recent fixes from Jan hasn't been applied? I mean these: http://www.spinics.net/lists/kvm/msg75076.html http://www.spinics.net/lists/kvm/msg75074.html Thanks, /mjt -- 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: [bug 1.1] -M pc-1.0 + vhost = SIGSEGV
02.07.2012 11:20, Jan Kiszka wrote: On 2012-07-01 17:06, Michael Tokarev wrote: When running current git version of qemu-kvm with -M pc-1.0 Just to clarify: you are talking about stable-1.1 git, not master. Yes, as the $Subject (partially) says. [] So it looks like msix isn't initialized for -M pc-1.0 ? And for earlier pc numbers too (eg -M pc-0.15). Yes, because the machine option defaults are missing here. Will send a patch. Also vhost is buggy as it depends on in-kernel irqchip but doesn't check for it. Needs to be fixed as well. And while we're at it, can we please take a look at the kernel side of this bug, mentioned in other my email? Namely, when qemu-kvm sigsegvs in this place, the (persistent) tap device becomes unusable and needs to be re-created (no packets are flowing). We've a nice reproducer now for this kernel issue. (Cc'ing mst for this) Thanks, /mjt -- 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
[bug 1.1] -M pc-1.0 + vhost = SIGSEGV
When running current git version of qemu-kvm with -M pc-1.0 and with vhost-net enabled, it crashes with SIGSEGV right when linux guest loads a virtio-net module. I haven't tried to debug this deeply. The first result is: (gdb) ru -M pc-1.0 -nodefconfig -nodefaults -rtc base=utc -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -netdev tap,ifname=tap-kvm,script=no,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b4:05:b5,bus=pci.0,addr=0x3 -vga cirrus Starting program: /build/kvm/debian/build/x86_64-softmmu/qemu-system-x86_64 -M pc-1.0 -nodefconfig -nodefaults -rtc base=utc -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -netdev tap,ifname=tap-kvm,script=no,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b4:05:b5,bus=pci.0,addr=0x3 -vga cirrus ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf65f4b70 (LWP 11245)] 0x5668b01a in virtio_pci_mask_vq (vector=vector@entry=1, vq=0x57064448, masked=masked@entry=0, dev=error reading variable: Unhandled dwarf expression opcode 0xfa) at /build/kvm/debian/hw/virtio-pci.c:546 546 int r = kvm_set_irqfd(dev-msix_irq_entries[vector].gsi, Now, my gdb can't read `dev' variable. One level up the stack this variable is shown correctly: #1 0x5668b15d in virtio_pci_mask_notifier (dev=0x57062748, vector=1, masked=0) at /build/kvm/debian/hw/virtio-pci.c:576 576 r = virtio_pci_mask_vq(dev, vector, virtio_get_queue(vdev, n), masked); (gdb) p dev-msix_irq_entries[vector].gsi Cannot access memory at address 0x10 (gdb) p dev $1 = (PCIDevice *) 0x57062748 (gdb) p dev-msix_irq_entries $4 = (KVMMsiMessage *) 0x0 So it looks like msix isn't initialized for -M pc-1.0 ? Thanks, /mjt -- 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: [bug 1.1] -M pc-1.0 + vhost = SIGSEGV
On 01.07.2012 19:06, Michael Tokarev wrote: When running current git version of qemu-kvm with -M pc-1.0 and with vhost-net enabled, it crashes with SIGSEGV right when linux guest loads a virtio-net module. And when this happens when a persistent tap device is used, that tap device becomes unusable until removed and recreated -- it works but no network packet goes on. So it looks like we've two bugs, one in userspace qemu 1.1 and another in host kernel (3.0). Thanks, /mjt -- 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
KVM internal error with some amounts of guest memory
Now that's something else. Reported by a debian user, but trivially reproducible. $ kvm -m 1.4g KVM internal error. Suberror: 1 emulation failure EAX=000e3c54 EBX= ECX= EDX=0cfd ESI= EDI= EBP= ESP=6fe8 EIP=000f309b EFL=0016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000fd3a8 0037 IDT= 000fd3e6 CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=ff ff ba 59 00 00 00 a8 10 89 d8 75 09 b9 ef 2f ff ff ff d1 eb 23 59 5b 5e e9 4a ff ff ff 31 d2 89 f0 e8 6c fa ff ff 89 c6 85 c0 79 ab c7 04 24 8c 4c This is 1.1. -m 1.5g works. -no-kvm works. What's that? :) Thanks, /mjt -- 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 internal error with some amounts of guest memory
On 14.06.2012 23:22, Michael Tokarev wrote: Now that's something else. Reported by a debian user, but trivially reproducible. $ kvm -m 1.4g KVM internal error. Suberror: 1 emulation failure EAX=000e3c54 EBX= ECX= EDX=0cfd ESI= EDI= EBP= ESP=6fe8 EIP=000f309b EFL=0016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000fd3a8 0037 IDT= 000fd3e6 CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=ff ff ba 59 00 00 00 a8 10 89 d8 75 09 b9 ef 2f ff ff ff d1 eb 23 59 5b 5e e9 4a ff ff ff 31 d2 89 f0 e8 6c fa ff ff 89 c6 85 c0 79 ab c7 04 24 8c 4c This is 1.1. Qemu 1.1 with -enable-kvm also has this very issue. Switching to qemu-devel@. -m 1.5g works. -no-kvm works. I can trivially reproduce this on two machines, both are AMD-based. I don't know if it is amd-specific or not. /mjt -- 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 internal error with some amounts of guest memory
On 14.06.2012 23:45, Michael Tokarev wrote: On 14.06.2012 23:22, Michael Tokarev wrote: Now that's something else. Reported by a debian user, but trivially reproducible. $ kvm -m 1.4g KVM internal error. Suberror: 1 emulation failure EAX=000e3c54 EBX= ECX= EDX=0cfd ESI= EDI= EBP= ESP=6fe8 EIP=000f309b EFL=0016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000fd3a8 0037 IDT= 000fd3e6 CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=ff ff ba 59 00 00 00 a8 10 89 d8 75 09 b9 ef 2f ff ff ff d1 eb 23 59 5b 5e e9 4a ff ff ff 31 d2 89 f0 e8 6c fa ff ff 89 c6 85 c0 79 ab c7 04 24 8c 4c Bisected. This is introduced by this commit: 8f6f962b994e1402935055ac7093ac977ccc9a5c is the first bad commit commit 8f6f962b994e1402935055ac7093ac977ccc9a5c Author: Avi Kivity a...@redhat.com Date: Wed Feb 29 13:22:12 2012 +0200 kvm: fix unaligned slots kvm_set_phys_mem() may be passed sections that are not aligned to a page boundary. The current code simply brute-forces the alignment which leads to an inconsistency and an abort(). Fix by aligning the start and the end of the section correctly, discarding and unaligned head or tail. This was triggered by a guest sizing a 64-bit BAR that is smaller than a page with PCI_COMMAND_MEMORY enabled and the upper dword clear. Signed-off-by: Avi Kivity a...@redhat.com :100644 100644 c4babdac0dd3335eab1a9e45371b7df2c0dd1c9c 4b7a4ae5dd6d9bd0b4cfa37159382654f0641e8d M kvm-all.c Once again, this affects both qemu-kvm and qemu (with -enable-kvm) 1.1, at least on AMD host, and the issue gets reported immediately when starting the virtual machine with -m 1.4g (no other arguments). Thanks, /mjt -- 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
1.1 release?
Are there any issues with 1.1 release of qemu-kvm? The RCs were followed qemu RCs quite closely, but the final 1.1 is still not released, anything wrong with it? Thanks! /mjt -- 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: 1.1 release?
On 07.06.2012 11:13, Avi Kivity wrote: On 06/07/2012 10:10 AM, Michael Tokarev wrote: Are there any issues with 1.1 release of qemu-kvm? [] Yes, there is a regression with IDE PIO that can hang a guest on boot. Any pointers on this? I were testing 1.1-rc with various guests and it all works more or less okay so far, but I didn't try pio mode. We don't think it's a data corruptor, but I'd rather see it fixed before a release. Yes, that'd be nice. Thanks, /mjt -- 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: Virtio network performance on Debian
On 12.04.2012 11:42, Hans-Kristian Bakke wrote: Hi For some reason I am not able to get good network performance using virtio/vhost-net on Debian KVM host (perhaps also valid for Ubuntu hosts then). The issue has been identified, after Hans-Kristian gave me access to his machine and I did alot of testing. And as usual, the root cause was very stupid... ;) In last release of debian qemu-kvm package I changed the way how debian package version string propagates to build procedure -- before it was a patch grabbing values from debian/version, but in last release I used --with-pkgversion configure flag. This resulted in the following change: - QEMU emulator version 1.0 (qemu-kvm-1.0 Debian 1.0+dfsg-8), Copyright (c) 2003-2008 Fabrice Bellard + QEMU emulator version 1.0 (Debian qemu-kvm 1.0+dfsg-9), Copyright (c) 2003-2008 Fabrice Bellard As it turns out, libvirt parses `qemu -version' output and looks for (qemu-kvm- string in there, and if it is found, libvirt enables some extra features. Important for us was setting IFF_VNET_HDR flag for a tap device, -- apparently this flag makes a HUGE difference in networking speed, especially when using vhost_net. Obviously this is a change unique to debian, and I never thought about such an.. interesting effect it may give us. This is a libvirt bug actually, since support of vnet_hdr can be determined by other means, and since upstream qemu now has almost everything from qemu-kvm, and it wants to be fast too. But since qemu[-kvm] has a long history of changing features, it is difficult to blame libvirt that much... Oh well. Thanks! /mjt -- 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: Virtio network performance on Debian
On 16.04.2012 13:01, Stefan Pietsch wrote: On 12.04.2012 09:42, Hans-Kristian Bakke wrote: Hi For some reason I am not able to get good network performance using virtio/vhost-net on Debian KVM host (perhaps also valid for Ubuntu hosts then). Disc IO is very good and the guests feels snappy so it doesn't seem like there is something really wrong, just something suboptimal with the networking. [..] I have tried: - Replacing Debian Wheezy with Debian Squeeze (stable, kernel 2.6.32-xx) - even worse results - Replacing kernel 3.2.0-2-amd64 with vanilla kernel 3.4-rc2 and config based on Debians included config - no apparent change - Extracted the kernel-config file from Fedora 17 alphas kernel and used this to compile a new kernel based on Debian Wheezys kernel source - slightly worse results - ...in addition to exchanging Debian with Fedora 17 alpha, Proxmox 1.9 and 2.0 and ESXi 5 which all have expected network performance using virtio. So, I am at a loss here. I does not seem to be kernel config related (as using Fedoras config on Debian kernel source didn't do anything good) so I think it must be either a kernel patch that red hat kernel based distros uses to make virtio/vhost much more efficient or perhaps something with Debians qemu-version, bridging or something. Hans-Kristian submitted a bugreport to Debian BTS about this, http://bugs.debian.org/668594 . In this case it turns out to be a problem with particular qemu-kvm userspace binary build, maybe the toolchain used, maybe something else - I don't yet know. This is not the first time this version is mentioned as being slow (slower) with network transfers, here's another bugreport which I merely ignored till now -- see http://bugs.debian.org/665046 . I'm working on this, or trying to anyway. I have made some tests with a Debian Squeeze KVM host running with the Linux Kernel 2.6.39 from backports and the Kernel version 2.6.32-11-pve from Proxmox. (http://download.proxmox.com/debian/dists/squeeze/pve/binary-amd64/pve-kernel-2.6.32-11-pve_2.6.32-66_amd64.deb) These are very different. Note that 2.6.32 does not have vhost-net support which is used by Hans-Kristian and speeds up network operations dramatically. Network performance between two virtual machines on the same host is significantly slower with the Debian kernel: 2.6.39-bpo.2-amd64 : 1.31 Gbits/sec 2.6.32-11-pve : 2.20 Gbits/sec Please try current debian kernel. There were a few issues with that 2.6.32 backport, but I don't know the details and don't know if these affects qemu/kvm in any way or not. And again, if you really want good networking speeds, you should use vhost-net which is is not supported by 2.6.32 kernel. iperf tests between a virtual machine and the KVM host connected to the same local bridge interface showed similar results. Are there other people who can confirm this? Thanks, /mjt -- 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] kvm-amd: Auto-load on CPUs with SVM.
On 28.03.2012 22:32, Josh Triplett wrote: Enable x86 feature-based autoloading for the kvm-amd module on CPUs with X86_FEATURE_SVM. Signed-off-by: Josh Triplett j...@joshtriplett.org It appears to work fine on my amd boxen. The only problem is that I've no idea when it will be possible to finally disable the init script (shipped in Debian and other distros) to load the module based on /proc/cpuinfo contents. It will do nothing on kernels with this (or kvm-intel) change applied, but we still need to support older kernels without that feature... :) Josh, and I'm sure you will be the first who'll file a bugreport against qemu-kvm in Debian requesting the startup script to be removed!.. ;)) Thanks, /mjt -- 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: Use getaddrinfo for migration
Not a reply to the patch but a general observation. I noticed that the tcp migration uses gethostname (or getaddrinfo after this patch) from the main thread - is it really the way to go? Note that DNS query which is done may block for a large amount of time. Is it really safe in this context? Should it resolve the name in a separate thread, allowing guest to run while it is doing that? This question is important for me because right now I'm evaluating a network-connected block device driver which should do failover, so it will have to resolve alternative name(s) at runtime (especially since list of available targets is dynamic). From one point, _usually_, the delay there is very small since it is unlikely you'll do migration or failover overseas, so most likely you'll have the answer from DNS handy. But from another point, if the DNS is malfunctioning right at that time (eg, one of the two DNS resolvers is being rebooted), the delay even from local DNS may be noticeable. Thanks, /mjt -- 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: Win 2000 driver for -vga std ?
On 14.02.2012 05:42, Reeted wrote: Hello, subject says it all The driver for windows 2000 for the -vga std should be the Anapa VBE Vesa VBEMP if I understand correctly but I cannot on earth find this executable http://navozhdeniye.narod.ru/vbemp.htm all links for download all over the world are dangling! Anybody has conserved this very important driver? This adapter works in all versions of windows with a built-in vesa driver just fine, no replacement is necessary or desired. The only problem is that some versions of windows consider that driver to be problematic somehow and mark the corresponding device with yellow exclamation sign. Go ask M$ about this. Thanks, /mjt -- 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: Unable to start a guest using qemu-kvm directly
On 29.01.2012 19:17, Vinod Chegu wrote: Dear All, I am using RHEL 6.2 + KVM on a X86_64 server. I have been able to create Linux guests using virt-install (using virto and/or pci passthrough) and am able to manage the guests using virsh and/or virt-manager for doing some basic stuff. Here is a sample guest (that I was able to create using virt-install and able to boot fine using either virsh or virt-manager) : [] Tried to start the above guest using qemu-kvm directly (so that I can in future specify different options etc). But I am getting some errors. (pl. see below). # /usr/libexec/qemu-kvm -version QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c) 2003-2008 Fabrice Bellard # /usr/libexec/qemu-kvm -S -M rhel6.2.0 -enable-kvm -m 4096 -smp 1,sockets=1,cores=1,threads=1 -name testvm2 -uuid d44e8618-e48c-531b-01c4- 80fc2a026a25 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/testvm2.monitor,server,nowait - mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown - drive file=/var/lib/libvirt/images/vmStorage/vm2.img,if=none,id=drive-virtio- disk0,format=qcow2,cache=none -device virtio-blk- pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 - drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide- drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net- ^ ^^ pci,netdev=hostnet0,id=net0,mac=52:54:00:7b:dc:d3,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb - device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x5 char device redirected to /dev/pts/5 qemu-system-x86_64: -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24: TUNGETIFF ioctl() failed: Bad file descriptor libvirt pre-configures network tap devices and pre-opens /dev/vhost-net file and passes these to qemu[-kvm] as open, ready to use file descriptors. Like you can do to redirect stdin: cat file there, cat opens file and reads it, or cat file where cat reads stdin. In particular, libvirtd has more privileges to open tap and vhost-net devices since it does that as root but spawns qemu[-kvm] as unprivileged user. [] Can someone please tell me what this means and any tips on how I can solve this? Do I have to do some other setup to make qemu-kvm happy w.r.t the -netdev options? You need to understand how to (pre-)configure networking for qemu (pre- if you want to run it as non-root), this is described in the users guide and in a lot of howtos all around the 'net. /mjt -- 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: qemu-kvm: Inconsistent vgabios reference
On 15.01.2012 16:53, Avi Kivity wrote: On 01/15/2012 02:50 PM, Jan Kiszka wrote: [] extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad Yeah, but it isn't history for people running older qemu-kvm's. We don't need extboot itself, but we do need to keep the boot option (as 2a06 does). The question is do we need to preserve its meaning too (with the seabios implementation instead of extboot's). FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff. Now, I've a question: what seabios implementation of extboot we're talking about? -option-rom which is impossible to select as a first boot device? Thanks, /mjt -- 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: qemu-kvm: Inconsistent vgabios reference
On 15.01.2012 17:18, Avi Kivity wrote: On 01/15/2012 03:10 PM, Michael Tokarev wrote: [] FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff. It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are? I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447 and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance. Now, I've a question: what seabios implementation of extboot we're talking about? -option-rom which is impossible to select as a first boot device? seabios has native support for booting from virtio-blk, and will natively support virtio-scsi as well. Ah. Well, I thought especially about lsi emulated scsi. I wasn't able to boot from it even with their bios -- once there's at least one other bootable device present (including the NIC) it refuses to boot from lsi emulated scsi drive. Thanks, /mjt -- 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] vhost-net: add module alias
On 11.01.2012 20:58, Stephen Hemminger wrote: On Wed, 11 Jan 2012 11:07:47 +0400 Michael Tokarev m...@tls.msk.ru wrote: On 11.01.2012 08:54, Stephen Hemminger wrote: By adding the a module alias, programs (or users) won't have to explicitly call modprobe. Vhost-net will always be available if built into the kernel. It does require assigning a permanent minor number for depmod to work. Choose one next to TUN since this driver is related to it. Why do you think a statically-allocated device number will do any good at all? Static /dev is gone almost completely, at least on the systems where whole virt stuff makes any sense, so you don't have pre-created vhost-net device anymore, and hence this allocation makes no sense. Just IMHO anyway. [] See also: https://lkml.org/lkml/2010/5/21/134 Aha. So udev pre-creates statically-allocated devnodes nowadays: Udev will pick up the depmod created file on startup and create all the static device nodes which the kernel modules specify, so that these modules get automatically loaded when the device node is accessed... This was the part I missed. Now it all looks logically. Thanks, /mjt -- 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] vhost-net: add module alias
On 11.01.2012 08:54, Stephen Hemminger wrote: By adding the a module alias, programs (or users) won't have to explicitly call modprobe. Vhost-net will always be available if built into the kernel. It does require assigning a permanent minor number for depmod to work. Choose one next to TUN since this driver is related to it. Why do you think a statically-allocated device number will do any good at all? Static /dev is gone almost completely, at least on the systems where whole virt stuff makes any sense, so you don't have pre-created vhost-net device anymore, and hence this allocation makes no sense. Just IMHO anyway. Thanks, /mjt -- 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: [Qemu-devel] winXP Standard PC HAL and qemu-kvm = 0.15
On 07.12.2011 13:02, Kevin Wolf wrote: Am 06.12.2011 19:21, schrieb Jan Kiszka: [] For the 0.15 .. 1.0 change, the first commit which restores the (broken in 0.15) functionality is this one: commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8 Author: Jan Kiszka jan.kis...@siemens.com Date: Fri Oct 7 09:19:45 2011 +0200 i8259: Clear ELCR on reset The ELCR is actually part of the chipset but we model it here for simplicity reasons. The PIIX3 clears the ELCR on reset, which was once broken by 4dbe19e181. Fix this by splitting up pic_init_reset from pic_reset and clearing the register in the latter. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Blue Swirl blauwir...@gmail.com Which is quite expected having in mind the commit which broke it for 0.15. Yep, makes a lot of sense. That patch should be applied to stable then (who's in charge?). Justin, I guess (CCed). Not sure if we're planning to have another 0.15.x release, though. Note that I haven't actually tested this commit alone on top of 0.15. But I already commented on this - there's no good reason - imho anyway - to fix that for 0.15. I'll try to push 1.0 to debian asap (waiting for libvirt to catch up) to close this issue there, other distros should hurry up too ;) Thanks! /mjt -- 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: winXP Standard PC HAL and qemu-kvm = 0.15
On 06.12.2011 14:32, Avi Kivity wrote: On 12/05/2011 10:19 PM, Michael Tokarev wrote: On 05.12.2011 17:28, Avi Kivity wrote: [] I haven't debugged further yet, -- because it were not easy to find out what was causing the regression and how to reproduce it, and also because I don't think it is the right HAL for qemu-kvm guest anyway. It's not, but the regression indicates we broke something. It would be good to know what that is. So today I gave it a chance with git bisect, and here's what it found: First bad commit ef390067a72fe09977bb4ac8211313e1503302ea Merge: c7b3e90 0fd542f Author: Avi Kivity a...@redhat.com Date: Sun May 15 04:48:05 2011 -0400 Merge commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df' into upstream-merge And after applying Avi's instructions here's the real bisect result: ab431c283e7055bcd6fb622f212bb29e84a6a134 is the first bad commit commit ab431c283e7055bcd6fb622f212bb29e84a6a134 Author: Isaku Yamahata yamah...@valinux.co.jp Date: Fri Apr 1 20:43:23 2011 +0900 piix_pci: optimize set irq path optimize irq routing in piix_pic.c which has been a TODO. So far piix3 tracks each pirq level and checks whether a given pic pins is asserted by seeing if each pirq is mapped into the pic pin. This is independent on irq routing, but data path is on slow path. Given that irq routing is rarely changed and asserting pic pins is on data path, the path that asserts pic pins should be optimized and chainging irq routing should be on slow path. The new behavior with this patch series is to use bitmap which is addressed by pirq and pic pins with a given irq routing. When pirq is asserted, the bitmap is set and see if the pic pins is asserted by checking the bitmaps. When irq routing is changed, rebuild the bitmap and re-assert pic pins. test: - create VM with 4 e1000 nics in different pci slots (i.e. fn=0 for each e1000) Thus those e1000's INTA are connected to each PIRQ[A-D]. - run linux as guest and saw each devices triggers interrupt by seeing /proc/interrupts. And then confirmed that each PIRQ[A-D] surely asserted interrupts. Because irq 10 and 11 are shared by 4 e1000's, it only one NIC is activated with ifconfig ethN up/down when counting interrupts. Cc: Michael S. Tsirkin m...@redhat.com Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp Signed-off-by: Michael S. Tsirkin m...@redhat.com So I'm Cc'ing the relevant people for this. For ones who didn't see the original problem, here's the thread: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82705/focus=82851 Thanks! /mjt -- 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: winXP Standard PC HAL and qemu-kvm = 0.15
On 06.12.2011 16:27, Michael S. Tsirkin wrote: On Tue, Dec 06, 2011 at 03:02:49PM +0400, Michael Tokarev wrote: [] And after applying Avi's instructions here's the real bisect result: ab431c283e7055bcd6fb622f212bb29e84a6a134 is the first bad commit commit ab431c283e7055bcd6fb622f212bb29e84a6a134 Author: Isaku Yamahata yamah...@valinux.co.jp Date: Fri Apr 1 20:43:23 2011 +0900 piix_pci: optimize set irq path Could you try with this commit reverted please? Reverting patch below. Warning: compiled only. After some discussion on IRC, here's a summary. I applied this patch on top of qemu-kvm-0.15.0. The resulting executable shows the same bad behavour with my test guest as it was without this patch. So apparently just reverting this patch isn't enough for the problem to go away. But when doing a bisection, the result is very reliable - it always points to the commit above (which we tried to revert by this patch). More data points (all against qemu-kvm-0.15.0). First, as Avi pointed out, this patch references PIC which is used by standardPC HAL and not used by ACPI HAL. So it might be something to think about, at least. Now, so far, all deviecs which are on IRQ11 are affected. When enabling USB and NIC, they both gets assigned to IRQ11 and both does not work. When enabling just one of them (either), only that device (which gets assigned to IRQ11) does not work. All other devices apparently works fine (including PS/2 Mouse on IRQ12). When using just one of NIC/USB, all IRQs in the guest becomes single-device, so IRQ sharing isn't a problem. I wasn't able to force the guest to use IRQ10 so far (to verify). Also, when booted with -no-kvm-irqchip, guest Just Works, including USB and NIC sharing IRQ11. While on IRC there was one more person who suffered from the same issue, now with Win2003. He was able to solve his guest issue by changing StandardPC HAL into ACPI HAL, using a hackish way (by replacing C:\Windows\System32\HAL.DLL into HALACPI.DLL as found on win2k3 installation CDROM). I wasn't able to replace stdhal into anything else on my test winXP machine - after changing HAL.DLL, on next reboot my guest complains about being unable to find boot device (BSOD STOP 0x7b) - despite using stdIDE and mergeide. I'll investigate the guest side further later. When in this funky mode with non-working IRQ11 (when a NIC (rtl8139) is assigned to it), winXP guest shows huge delays when trying to open My Computer properties - it freezes for 30..40 seconds after hitting Properties in the context menu. I can only guess it is trying to do something with the IRQs at that time, which does not work. I wasn't able to (quickly) find a tool for winXP to show IRQ statistics. That's about all the info so far which I know about this issue. Thanks, /mjt -- 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: [Qemu-devel] winXP Standard PC HAL and qemu-kvm = 0.15
[Added Jan Kiszka to Cc] On 06.12.2011 18:45, Michael Tokarev wrote: [complete thread: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82705] More data points (all against qemu-kvm-0.15.0). First, as Avi pointed out, this patch references PIC which is used by standardPC HAL and not used by ACPI HAL. So it might be something to think about, at least. Now, so far, all deviecs which are on IRQ11 are affected. When enabling USB and NIC, they both gets assigned to IRQ11 and both does not work. When enabling just one of them (either), only that device (which gets assigned to IRQ11) does not work. All other devices apparently works fine (including PS/2 Mouse on IRQ12). When using just one of NIC/USB, all IRQs in the guest becomes single-device, so IRQ sharing isn't a problem. I wasn't able to force the guest to use IRQ10 so far (to verify). Also, when booted with -no-kvm-irqchip, guest Just Works, including USB and NIC sharing IRQ11. While on IRC there was one more person who suffered from the same issue, now with Win2003. He was able to solve his guest issue by changing StandardPC HAL into ACPI HAL, using a hackish way (by replacing C:\Windows\System32\HAL.DLL into HALACPI.DLL as found on win2k3 installation CDROM). I wasn't able to replace stdhal into anything else on my test winXP machine - after changing HAL.DLL, on next reboot my guest complains about being unable to find boot device (BSOD STOP 0x7b) - despite using stdIDE and mergeide. I'll investigate the guest side further later. When in this funky mode with non-working IRQ11 (when a NIC (rtl8139) is assigned to it), winXP guest shows huge delays when trying to open My Computer properties - it freezes for 30..40 seconds after hitting Properties in the context menu. I can only guess it is trying to do something with the IRQs at that time, which does not work. I wasn't able to (quickly) find a tool for winXP to show IRQ statistics. That's about all the info so far which I know about this issue. It appears there are two issues here, one is fixed by 09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and another bisect leads to this commit: commit 59539c913383fdd3350681301b44f02fa7ee2757 Author: Jan Kiszka jan.kis...@siemens.com Date: Mon Jun 27 12:22:28 2011 +0200 qemu-kvm: Fix in-kernel PIC reset Lacking sync of the user space state to the kernel after system reset left the PIC behind in an undefined state. This broke IRQ delivery in some scenarios, e.g. when resetting while in the BIOS. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Avi Kivity a...@redhat.com Reverting this single commit on top of 0.15.0 fixes the guest issues described in this thread. This commit is qemu-kvm-specific (and indeed, the issue only affects qemu-kvm). Note also that as per above, -no-kvm-irqchip fixes the guest issue too. Anything wrong with this patch? Thanks, /mjt -- 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: winXP Standard PC HAL and qemu-kvm = 0.15
On 06.12.2011 20:38, Jan Kiszka wrote: On 2011-12-06 17:29, Michael Tokarev wrote: [] It appears there are two issues here, one is fixed by 09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and another bisect leads to this commit: Or 3... :) commit 59539c913383fdd3350681301b44f02fa7ee2757 Author: Jan Kiszka jan.kis...@siemens.com Date: Mon Jun 27 12:22:28 2011 +0200 qemu-kvm: Fix in-kernel PIC reset [] Anything wrong with this patch? I tend to say no. It may just reveals some issue elsewhere. To cross-check: Does this series [1] expose the same issue with vanilla QEMU when enabling that in-kernel irqchip version? I cross-checked it the other way, which really should have been done at the very beginning instead of wasting so much time of so many people at once. I just tried qemu-kvm-1.0, which I wasn't due to an unrelated issue (1.0 does not work for me in my funky 32/64bit environment). Also, since the bug has been reported especially against 0.15 version (triggering by upgrading from 0.14 to 0.15), I didn't insist on trying 1.0, which was my biggest mistake. And in qemu-kvm-1.0, the problem guest Just Works. So i t must be something else which were fixed between 0.15 and 1.0. Upstream qemu 1.0 does not have this issue too. [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82871 I'll try to verify this series in a moment, but hopefully it will work fine too :) Thanks! /mjt -- 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: winXP Standard PC HAL and qemu-kvm = 0.15
On 06.12.2011 20:57, Michael Tokarev wrote: On 06.12.2011 20:38, Jan Kiszka wrote: On 2011-12-06 17:29, Michael Tokarev wrote: [] It appears there are two issues here, one is fixed by 09de0f469c3c2a277c7874f6c60992c8b94719a9 and is 32bit-only, and another bisect leads to this commit: Or 3... :) commit 59539c913383fdd3350681301b44f02fa7ee2757 Author: Jan Kiszka jan.kis...@siemens.com Date: Mon Jun 27 12:22:28 2011 +0200 qemu-kvm: Fix in-kernel PIC reset [] Anything wrong with this patch? I tend to say no. It may just reveals some issue elsewhere. To cross-check: Does this series [1] expose the same issue with vanilla QEMU when enabling that in-kernel irqchip version? I cross-checked it the other way, which really should have been done at the very beginning instead of wasting so much time of so many people at once. I just tried qemu-kvm-1.0, which I wasn't due to an unrelated issue (1.0 does not work for me in my funky 32/64bit environment). Also, since the bug has been reported especially against 0.15 version (triggering by upgrading from 0.14 to 0.15), I didn't insist on trying 1.0, which was my biggest mistake. And in qemu-kvm-1.0, the problem guest Just Works. So i t must be something else which were fixed between 0.15 and 1.0. For the 0.15 .. 1.0 change, the first commit which restores the (broken in 0.15) functionality is this one: commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8 Author: Jan Kiszka jan.kis...@siemens.com Date: Fri Oct 7 09:19:45 2011 +0200 i8259: Clear ELCR on reset The ELCR is actually part of the chipset but we model it here for simplicity reasons. The PIIX3 clears the ELCR on reset, which was once broken by 4dbe19e181. Fix this by splitting up pic_init_reset from pic_reset and clearing the register in the latter. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Blue Swirl blauwir...@gmail.com Which is quite expected having in mind the commit which broke it for 0.15. Upstream qemu 1.0 does not have this issue too. [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82871 I'll try to verify this series in a moment, but hopefully it will work fine too :) And that turned out to be not so easy for me. Which is this series against? Is there may be a git tree with this series applied already? Thanks! /mjt -- 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: winXP Standard PC HAL and qemu-kvm = 0.15
On 06.12.2011 22:21, Jan Kiszka wrote: [] For the 0.15 .. 1.0 change, the first commit which restores the (broken in 0.15) functionality is this one: commit 86fbf97ceb4a9c46a609dd4ae053ba4262b68fe8 Author: Jan Kiszka jan.kis...@siemens.com Date: Fri Oct 7 09:19:45 2011 +0200 i8259: Clear ELCR on reset The ELCR is actually part of the chipset but we model it here for simplicity reasons. The PIIX3 clears the ELCR on reset, which was once broken by 4dbe19e181. Fix this by splitting up pic_init_reset from pic_reset and clearing the register in the latter. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Blue Swirl blauwir...@gmail.com Which is quite expected having in mind the commit which broke it for 0.15. Yep, makes a lot of sense. That patch should be applied to stable then (who's in charge?). I'm not sure it makes much sense to continue 0.15 at this stage. Upstream qemu 1.0 does not have this issue too. [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82871 I'll try to verify this series in a moment, but hopefully it will work fine too :) And that turned out to be not so easy for me. Which is this series against? Is there may be a git tree with this series applied already? Oops. It's against qemu-kvm's uq/master queue. Find a git tree at git://git.kiszka.org/qemu-kvm.git queues/kvm-irqchip This tree does not boot for me at all (on regular x86-64 setup) - it stays in bios after Booting from hard disk with 100% CPU usage. /mjt -- 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: winXP Standard PC HAL and qemu-kvm = 0.15
[Removed some people from the Cc list]
On 06.12.2011 22:45, Michael Tokarev wrote:
[]
git://git.kiszka.org/qemu-kvm.git queues/kvm-irqchip
This tree does not boot for me at all (on regular x86-64 setup) -
it stays in bios after Booting from hard disk with 100% CPU
usage.
This happens since
commit 1ae1cec76a205446e6b4e5600ad0af450f7c0b5e
Author: Jan Kiszka jan.kis...@siemens.com
Date: Sun Oct 16 19:38:22 2011 +0200
ioapic: Introduce backend/frontend infrastructure for KVM reuse
Also, with this
commit 063e1bea9b0c79bda48c9e82552c5c6c83d03cf7
Author: Jan Kiszka jan.kis...@siemens.com
Date: Sat Oct 15 11:49:47 2011 +0200
kvm: Introduce core services for in-kernel irqchip support
the whole thing segfaults at startup:
(gdb) ru -monitor stdio -m 1G -netdev
type=tap,ifname=tap-kvm1,script=no,downscript=no,id=n -device
rtl8139,netdev=n,mac=52:54:00:12:34:57 -drive
file=/stage/win/dist/t.raw,if=ide,cache=unsafe -vga std -usbdevice tablet
-enable-kvm
...
Program received signal SIGSEGV, Segmentation fault.
0x75670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x75670c7a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x557abb3d in ioapic_init (dev=0x56849f60)
at /build/kvm/git/hw/ioapic_common.c:92
#2 0x556a0a85 in sysbus_device_init (dev=0x56849f60,
base=0x55be7200) at /build/kvm/git/hw/sysbus.c:133
#3 0x556df670 in qdev_init (dev=0x56849f60)
at /build/kvm/git/hw/qdev.c:293
#4 0x556dfa8a in qdev_init_nofail (dev=0x56849f60)
at /build/kvm/git/hw/qdev.c:387
#5 0x557f9bc2 in ioapic_init (gsi_state=0x5683ff70)
at /build/kvm/git/hw/pc_piix.c:63
#6 0x557f9f76 in pc_init1 (system_memory=0x5641a1b0,
system_io=0x5641a2b0, ram_size=1073741824,
boot_device=0x7fffea30 cad, kernel_filename=0x0,
kernel_cmdline=0x5586fbff , initrd_filename=0x0, cpu_model=0x0,
pci_enabled=1, kvmclock_enabled=1) at /build/kvm/git/hw/pc_piix.c:166
#7 0x557fa425 in pc_init_pci (ram_size=1073741824,
boot_device=0x7fffea30 cad, kernel_filename=0x0,
kernel_cmdline=0x5586fbff , initrd_filename=0x0, cpu_model=0x0)
at /build/kvm/git/hw/pc_piix.c:245
#8 0x556b99ca in main (argc=16, argv=0x7fffeb58,
envp=0x7fffebe0) at /build/kvm/git/vl.c:3351
(gdb) frame 1
#1 0x557abb3d in ioapic_init (dev=0x56849f60)
at /build/kvm/git/hw/ioapic_common.c:92
92 if (strcmp(b-name, s-backend_name) == 0) {
(gdb) p b-name
$1 = 0x5588588d QEMU
(gdb) p s-backend_name
$2 = 0x0
(gdb) _
Thanks!
/mjt
--
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: [Qemu-devel] winXP Standard PC HAL and qemu-kvm = 0.15
On 07.12.2011 01:12, Jan Kiszka wrote: On 2011-12-06 21:58, Jan Kiszka wrote: [] How embarrassing. Messed something up, maybe during rebase, and forgot to retest non-irqchip mode. Will fix and repost. Was even worse, a simple -ENOTTESTED case. Pushed an update at the same location. Ok, with the updated series everything works correctly. Guests boots, qemu does not segfault at startup anymore, WinXP with StdPC HAL works, even coroutines on mixed 32/64 environment breaks exactly the same way as with qemu-kvm/master ;) Tested both -enable-kvm and -machine pc,accel=kvm,kernel_irqchip=on - both behaves equally (I wasnt' able to spot a difference). What is the target syntax -- I assume it is the more verbose one, with -machine, so that -enable-kvm will be dropped at some point, right? Thanks! /mjt -- 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
winXP Standard PC HAL and qemu-kvm = 0.15
As it turned out, a windowsXP machine does not work in qemu-kvm = 0.15 (it loses network and USB entirely) if it is using Standard PC HAL. In 0.14 it worked fine, but not in 0.14 (I haven't tried any in-between versions yet). There are several HAL types available in winXP: these are Uniprocessor PC with MPS (or Multiprocessor), also two ACPI types, and Standard PC. All the other HAL types appears to work fine, but not Standard PC. I haven't debugged further yet, -- because it were not easy to find out what was causing the regression and how to reproduce it, and also because I don't think it is the right HAL for qemu-kvm guest anyway. So, if anybody have some thoughts about this issue, and especially if you know a way to switch winXP HAL type to some ACPI variant without reinstalling, please speak up.. ;) Debian bugreport for a reference: http://bugs.debian.org/647312 Reproducer: install a winXP guest on kvm with -no-acpi so it chooses an Uniprocessor with MPS HAL. Switch it to Standard PC in device manager, reboot -- in 0.15+ it does not work anymore, while in 0.14 it continues to work fine. Thank you! /mjt -- 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: winXP Standard PC HAL and qemu-kvm = 0.15
On 05.12.2011 17:28, Avi Kivity wrote: [] I haven't debugged further yet, -- because it were not easy to find out what was causing the regression and how to reproduce it, and also because I don't think it is the right HAL for qemu-kvm guest anyway. It's not, but the regression indicates we broke something. It would be good to know what that is. So today I gave it a chance with git bisect, and here's what it found: First bad commit ef390067a72fe09977bb4ac8211313e1503302ea Merge: c7b3e90 0fd542f Author: Avi Kivity a...@redhat.com Date: Sun May 15 04:48:05 2011 -0400 Merge commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df' into upstream-merge * commit '0fd542fb7d13ddf12f897bb27c5950f31638b1df': cpu: add set_memory flag to request dirty logging piix_pci: load path clean up piix_pci: optimize set irq path piix_pci: eliminate PIIX3State::pci_irq_levels pci: add accessor function to get irq levels cirrus_vga: remove unneeded reset Conflicts: exec.c Signed-off-by: Avi Kivity a...@redhat.com And just like with the 32/64bit lockup issue, this is a merge commit, which is not exactly useful. Any guesses? :) The problem is that so far, there's no known way to change to use proper hal type in winXP (except of reinstalling the guest), and there's no known workaround on the kvm side, so users are stuck with older versions. So, if anybody have some thoughts about this issue, and especially if you know a way to switch winXP HAL type to some ACPI variant without reinstalling, please speak up.. ;) I remember doing it somewhere in device manager, perhaps in the processor entry. But it was years since I last did this. As I already mentioned, changing HAL type works from anything to Standard PC, but not back. I'll try to investigate. Debian bugreport for a reference: http://bugs.debian.org/647312 Reproducer: install a winXP guest on kvm with -no-acpi so it chooses an Uniprocessor with MPS HAL. Switch it to Standard PC in device manager, reboot -- in 0.15+ it does not work anymore, while in 0.14 it continues to work fine. Most likely non-ACPI interrupt routing. The commit it bisected to talks about piix -- may it be related? Thanks, /mjt -- 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: What are the rules for hyperthreaded CPUs?
On 05.12.2011 05:26, Todd And Margo Chester wrote: Hi All, My host has an i7-960 processor (4 cores, 8 hypterthreaded cores.) /proc/cpuinfo on my host shows 8 processors. On my Fedora Core 16 guest, /proc/cpuinfo shows 4 processors. Question: what is the maximum number of processors I can assign to my guest? 4 or 8? What are the rules for Hyperthreading? Many thanks, -T Figured it out. The max cores is the number of hyperthreaded cores (eight in my case). The maximum number of guest vCPUs is unlimited - you can assign, say, 100 cores - each vCPU core is just a thread on host, it does not correspond to any physical characteristics of your host. /mjt -- 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: cannot create VM with image on zfs filesystem (zfsonlinux)
On 07.11.2011 17:57, Peter Lees wrote: when trying to create a VM using a RAW image on a zfs filesystem, i get an invalid argument error. [] qemu: could not open disk image /space/vm_store/elveros_001.raw: Invalid argument Please run qemu under strace to show what exactly it is doing. /mjt -- 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: virtio localdisk performance
On 13.10.2011 13:05, benoit ROUSSELLE wrote: Hello, Can someone running with virtio tell me if this is normal to have such a difference with dd between host and guest machine ? host dd is 500MB/s guest dd is 150MB/s All other questions are optionnal for now :D Well, one question is mandatory: what is your kvm command line? Without it, there's no way to answer any other questions. /mjt -- 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 got slow after adding more physical memory to host - SOLVED
On 06.09.2011 23:22, Nikola Ciprich wrote: Hello guys, thanks to both of You for Your replies. The problem is solved, exactly as Avi said, the DMA in windows got somehow disabled. So this certainly was not related to adding the memory... anyways, note for further generations: in windows XP, the DMA usage can be checked in Device Manager-IDE ATA/ATAPI Controllers - Properties-Advanced Settings Current Transfer Mode must be Multi-Word DMA2 or something similar, NOT PIO! The way I enabled this, was to uninstall both primary and secondary controller in device controller, then also uninstall Intel controller, and THEN rebooting (NOT sooner!) after reboot, controllers got detected and installed again, with DMA properly enabled. Note that when controller is in PIO mode, this is really a patience test, switching to DMA took me like half an hour to complete, so slow the system was :-/ You can open regedit and search for NoIDE - it should find one key with that name, with value 1 or yes - just delete it, there's no need to go that route with removing/reinstalling device drivers. The reason why it has been disabled is - most likely - due to some timeout while handling i/o -- eg, when your host was loaded too much or were swapping - you should be able to find something about that in windows event log. /mjt -- 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
0.15: is glib actually needed?
Each time I build qemu-kvm, my build script complains that it is needlessly linked against libglib-2.0 without using any symbols from that library. So is glib really needed for qemu-kvm? How it's different from qemu-0.15? Thanks, /mjt -- 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: network boot always enabled with 0.15.0
11.08.2011 17:59, Gleb Natapov wrote: On Thu, Aug 11, 2011 at 01:57:04PM +, Dietmar Maurer wrote: [] Another possibility to disable network boot would be to avoid loading the pxe-XXX.rom network boot ROMs. Or is that a bad idea? Ah yeah. Don't see anything bad if you do not what to boot from net. Actually this is a very good idea, to stop loading pxe bootrom if no network booting is requested. This way it will be possible to use standard PXE code from ipxe -- compiled with all default options, including the 2-second boot delay... Thanks, /mjt -- 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] init: Support mounting devices from kernel command line
18.07.2011 15:55, Pekka Enberg wrote: On Mon, Jul 18, 2011 at 12:06 PM, Sasha Levin levinsasha...@gmail.com wrote: This patch adds support to mounting devices using a kernel parameter. Such feature is usefull for virtual guests. It allows easily automating mounts without having to change the base image (which can be read-only). In /tools/kvm we are interested in such feature to allow us to automatically mount user home directory using virtio-9p from the host to the guest filesystem under '/hostfs'. Can't the same be done within initramfs just as easy? Long time ago when initramfs first appeared the plan was to, more or less, move all that mounting and root= handling functionality to userspae, and here we're adding more to kernel. To me that sounds backwards... Thanks, /mjt -- 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: guest suspend/resume virtio: vring errors
09.07.2011 13:17, Gleb Natapov wrote: On Fri, Jul 08, 2011 at 11:02:54PM +0400, Michael Tokarev wrote: I tried suspend/resume cycle for a linux guest today, with 100% failure result. There are 2 Good. It works as expect :) Linux virtio drivers do not support PM. This means that neither in-guest suspend/resume nor qemu-kvm migrate-to-file (which fails for a different reason I'm trying to debug now) works. Which is very unfortunate. With e1000 instead of virtio-net-pci, the suspend does not complete - guest kernel freezes after the message Suspending console(s) and does not respond (but does not eat 100% CPU either) - the same as for older guest kernel. Has anyone succeeded suspend/resume cycle? Yes, but Linux and suspend/resume are not best friends. Sometimes it works by mistake, but next merged patch fixes it and suspend/resume returns to its normal broken state. Lovelylovely. It does not work with any version of windows I tried, too (which is winXP, win7 32 and win7 64bits). Windows enters an endless loop with a black screen during suspend (eating 100% CPU time). What's wrong/broken in linux? Can it be fixed? Thanks, /mjt -- 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: guest suspend/resume virtio: vring errors
09.07.2011 13:55, Gleb Natapov wrote: On Sat, Jul 09, 2011 at 01:47:25PM +0400, Michael Tokarev wrote: 09.07.2011 13:17, Gleb Natapov wrote: This means that neither in-guest suspend/resume nor qemu-kvm migrate-to-file (which fails for a different reason I'm trying to debug now) works. Which is very unfortunate. Migration to file should work, or, at least, is a different problem. It does not require guest cooperation. Sure, that's why I said different reason. That's what prompted me to try in-guest migration - because I weren't able to use migrate-to-file, but I needed to replace the qemu-kvm binary after a security fix. It does not work with any version of windows I tried, too (which is winXP, win7 32 and win7 64bits). Windows enters an endless loop with a black screen during suspend (eating 100% CPU time). Heh. Is this S4 or S3 suspend resume? Looks like recent breakage. The only knows problem to me is in win7/2008 S3 resume + net. How can I know if it's S3 or S4? And I can't say it's recent: 0.14.1 works (or actually does not work) exactly the same in this respect as current git: suspend/resume is equally broken. What's wrong/broken in linux? Can it be fixed? Complete lack of regression testing. Hm. You wrote: Yes, but Linux and suspend/resume are not best friends. Sometimes it works by mistake, but next merged patch fixes it and suspend/resume returns to its normal broken state. So regression testing should detect and raise an alarm when it works by mistake. But can it be fixed to work by design instead, after which regression testing gets entrirely new meaning ? :) Thanks, /mjt -- 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: guest suspend/resume virtio: vring errors
09.07.2011 14:36, Gleb Natapov wrote: On Sat, Jul 09, 2011 at 02:09:46PM +0400, Michael Tokarev wrote: Heh. Is this S4 or S3 suspend resume? Looks like recent breakage. The only knows problem to me is in win7/2008 S3 resume + net. How can I know if it's S3 or S4? And I can't say it's recent: S3 is suspend to memory, S4 is suspend to disk. Don't remember how different version of Windows call them. Actually win7 disables S3 when running on qemu with cirrus adapter, so you are probably doing S4. Ahh, yes, I remember now. Yes I used suspend-to-disk aka hybernation on windows. And actually there's no error in there - it works. I thought it is stuck in an endless loop, but it actually did suspending and it completes eventially. The only problem is that it does not show anything at all, no progress, no messages, no nothing - the screen is completely blank. That's with -vga std which I usually use. I just retried with cirrus and the effect is the same -- blank guest screen and 100% cpu usage, but it takes much much longer to complete for some reason - several minutes instead of ~30s. It also takes lots of time when resuming, and the thing is less reliable too -- I've seen ~50/50 failure ratio at resuming with -vga cirrus. 0.14.1 works (or actually does not work) exactly the same in this respect as current git: suspend/resume is equally broken. Suspend to disk worked flawlessly for me with Windows. There is nothing special qemu should do for it to work. I haven't checked it on upstream for a long time though. Can you check 0.12? It looks like 0.12 works the same way - at least the behavour is very similar. I also tried current qemu-kvm git and there, things are the same. What's wrong/broken in linux? Can it be fixed? Complete lack of regression testing. Hm. You wrote: Yes, but Linux and suspend/resume are not best friends. Sometimes it works by mistake, but next merged patch fixes it and suspend/resume returns to its normal broken state. So regression testing should detect and raise an alarm when it works by mistake. But can it be fixed to work by design instead, after which regression testing gets entrirely new meaning ? :) Well S4/S3 is pet peeve of mine, so I little bit exaggerated :) Design is not enough. Testing is needed. On Windows a driver that can't properly handle S3/S4 will not pass WHQL, will not be signed by MS and will never be loaded by the OS. So I'm completely confused. Is virtio designed to work or to fail on suspend/resume cycle? If the former, regression testing will help. If the latter, the design should be fixed first... ;) According to your words above it's designed to fail, so to say. Also, as far as I can see, it should be fixed on the guest side, ie, in linux virtio drivers, not in qemu/kvm (which appears to work with windows guests), right? Thanks, /mjt -- 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
guest suspend/resume virtio: vring errors
I tried suspend/resume cycle for a linux guest today, with 100% failure result. There are 2 possible scenarious after resume (you need pretty recent guest kernel for it to work at all, earlier kernels, incl. early 2.6.32, just stops somewhere at the start of suspend cycle, but 2.6.32.42 and 3.0-rc6 works), both are in the same place but different viewpoint. It is either guest complains virtio_net virtio0: input:id 2 is not a head! and enters an endless loop eating 100% CPU, or qemu-kvm exits (aborts) with the message: kvm: Guest moved used index from 1 to 0 this is when trying to use virtio-net. The same happens when disabling network entirely: it complains about virtio-blk in the same way, for example kvm: Guest moved used index from 1 to 49285 qemu-kvm is of version 0.14.1 so far, I'll try a git version later. With e1000 instead of virtio-net-pci, the suspend does not complete - guest kernel freezes after the message Suspending console(s) and does not respond (but does not eat 100% CPU either) - the same as for older guest kernel. Has anyone succeeded suspend/resume cycle? Thanks! /mjt -- 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
[heads-up] bridge in kernel 3.0~ and dhcp from kvm guest on tap device
The combination in $subject apparently stopped working -- I'm running 3.0-rc6 kernel on host where it doesn't work. The setup is -- a bridge, br0, to which host eth0 and guest tap devices are connected. When KVM guest boots, it tries to send DHCP requests to its ethernet device (it does not matter which device it uses - be it virtio or e1000 or rtl8139, all work the same). These requests appears (can be seen) on the tap device, but they never propagate to bridge. Example of a packet as seen on the tap device from a windows7 guest: # tcpdump -npvi tap-kvm port bootpc tcpdump: WARNING: tap-kvm: no IPv4 address assigned tcpdump: listening on tap-kvm, link-type EN10MB (Ethernet), capture size 65535 bytes 13:38:21.435032 IP (tos 0x0, ttl 128, id 109, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:12:34:56, length 300, xid 0xdc8f28b1, secs 7168, Flags [Broadcast] Client-Ethernet-Address 52:54:00:12:34:56 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 52:54:00:12:34:56 Hostname Option 12, length 7: mjt-006 Vendor-Class Option 60, length 8: MSFT 5.0 Parameter-Request Option 55, length 12: Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Vendor-Option Exactly the same thing happens with 4 different DHCP clients: it's ipxe boot rom (network booting of a KVM guest), win7 built-in DHCP client, udhcpc and dhcp3. All other traffic - so far anyway - works correcty. Right now I don't have time to debug the issue, will try to bisect later. But if anyone have pointers or thoughts, please shot away ;) Thanks! /mjt -- 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 monitor socket - connection refused
29.06.2011 19:20, Iordan Iordanov wrote: On 06/28/11 18:29, Michael Tokarev wrote: The process listening on this socket no longer exist, it finished. With this command line it should stay in foreground till finished (there's no -daemonize etc), so you should see error messages if any. The kvm command was backgrounded, not -daemonize(d). It was still running, and I was accessing the VM via VNC. So kvm was running at the time you tried to access the mointor. How about checking who is actually listening on this socket before asking? I thought it's the kvm process that listens on the socket. I haven't seen other processes spun off by kvm until now. Is that not the case? It is the kvm process that listens on the socket, it spawns no other processes. The only other explanation I can think of is that you tried to run two instances of kvm, and when second instance initialized it re-created the monitor socket but failed later (eg, when initin network or something else) and exited, but left the stray socket (JFYI, you can remove a unix-domain socket where some process is listening, and create another - that one will really be different socket, even if named the same way, -- just like you can re-create a plain file the same way). In any way, there hasn't been any problems/bugs in that area for ages. /mjt -- 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 monitor socket - connection refused
28.06.2011 23:20, Iordan Iordanov wrote: Hello, We are using KVM on Debian Squeeze (QEMU 0.12.5). Yesterday, I started a virtual machine and let it run overnight. I don't recall doing anything out of the ordinary to it. This morning, I wanted to issue some commands to it through the control socket, but socat is unable to connect to it. Usually, I am able to connect to the control socket this way. # ls -l total 1744816 -rw-r--r-- 1 iordan iordan 4195352576 Jun 28 14:54 disk.img srwxrwxr-x 1 root root0 Jun 28 12:35 monitor # socat - UNIX-CONNECT:./monitor 2011/06/28 15:13:53 socat[4564] E connect(3, AF=1 ./monitor, 11): Connection refused # kvm was run thus: kvm -runas iordan -drive file=./disk.img -enable-kvm -vnc localhost:200,vnc,password -usbdevice tablet -monitor unix:./monitor,server,nowait The process listening on this socket no longer exist, it finished. With this command line it should stay in foreground till finished (there's no -daemonize etc), so you should see error messages if any. # file monitor monitor: socket Is this a known issue with this version of Qemu? Has anybody else experienced this, and if so knows why it happens? How about checking who is actually listening on this socket before asking? /mjt -- 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: 2.6.32 guest with paravirt clock enabled hangs on 2.6.37.6 host (w qemu-kvm-0.13.0)
08.05.2011 22:33, Nikola Ciprich wrote: Hello everyboy, while installing new virt machine today, I noticed that 2.6.32 x86_64 SMP guests are hanging if they have paravirt-clock enabled... There were about 10 bugfixes pushed to 2.6.32.y stable series, some of them were for kvm-clock, and some were for problems which manifested itself like you described. You may actually take a look which guests you're booting. FWIW. /mjt -- 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: update from 0.12.5 to 0.14 goes headless
30.04.2011 16:24, Jerry Geis wrote: After updating when I start up no I am headless. How do I get headed back by default? my command is: qemu-system-x86_64 -net nic,model=rtl8139 -net user -hda $1 -no-acpi -m 2048 -usb $2 $3 $4 $5 $6 -vga std This works for me just fine with 0.14 - it displays the usual SDL X window. This is now stating qemu-kvm in headless mode. it tells me to use VNC 5901 to connect. But when I explicitly disable SDL when compiling, it does this: it allocates next free VNC display. So you may check how you built it. /mjt -- 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 v2 9/9] qemu-kvm: hpet: Add MSI support for in-kernel irqchip mode
26.04.2011 17:19, Jan Kiszka wrote:
hw/hpet.c | 71
-
+static int modifying_bit(uint64_t old, uint64_t new, uint64_t mask)
+{
+return (old ^ new) mask;
+}
Such constructs always look suspicious. I'm not even sure anymore
(after using C for over 20 years ;) that this works... how about
return (old ^ new) mask ? 1 : 0;
instead, or something along this? I mean, if sizeof(int)==4, how
`return 1ULL32' will be interpreted in this context? Tiny test
program tells me it will return 0...
/mjt
--
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
[PATCH] fix long-standing crash in 32bit migration
This change fixes a long-standing immediate crash (memory corruption
and abort in glibc malloc code) in migration on 32bits.
The bug is present since this commit:
commit 692d9aca97b865b0f7903565274a52606910f129
Author: Bruce Rogers brog...@novell.com
Date: Wed Sep 23 16:13:18 2009 -0600
qemu-kvm: allocate correct size for dirty bitmap
The dirty bitmap copied out to userspace is stored in a long array,
and gets copied out to userspace accordingly. This patch accounts
for that correctly. Currently I'm seeing kvm crashing due to writing
beyond the end of the alloc'd dirty bitmap memory, because the buffer
has the wrong size.
Signed-off-by: Bruce Rogers
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned long phys_addr,
-buf = qemu_malloc((slots[i].len / 4096 + 7) / 8 + 2);
+buf = qemu_malloc(BITMAP_SIZE(slots[i].len));
r = kvm_get_map(kvm, KVM_GET_DIRTY_LOG, i, buf);
BITMAP_SIZE is now open-coded in that function, like this:
size = ALIGN(((mem-memory_size) TARGET_PAGE_BITS), HOST_LONG_BITS) / 8;
The problem is that HOST_LONG_BITS in 32bit userspace is 32
but it's 64 in 64bit kernel. So userspace aligns this to
32, and kernel to 64, but since no length is passed from
userspace to kernel on ioctl, kernel uses its size calculation
and copies 4 extra bytes to userspace, corrupting memory.
Here's how it looks like during migrate execution:
our=20, kern=24
our=4, kern=8
...
our=4, kern=8
our=4064, kern=4064
our=512, kern=512
our=4, kern=8
our=20, kern=24
our=4, kern=8
...
our=4, kern=8
our=4064, kern=4064
*** glibc detected *** ./x86_64-softmmu/qemu-system-x86_64: realloc(): invalid
next size: 0x08f20528 ***
(our is userspace size above, kern is the size as calculated
by the kernel).
Fix this by always aligning to 64 in a hope that no platform will
have sizeof(long)8 any time soon, and add a comment describing it
all. It's a small price to pay for bad kernel design.
Alternatively it's possible to fix that in the kernel by using
different size calculation depending on the current process.
But this becomes quite ugly.
Special thanks goes to Stefan Hajnoczi for spotting the fundamental
cause of the issue, and to Alexander Graf for his support in #qemu.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
CC: Bruce Rogers brog...@novell.com
---
kvm-all.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 7e407f0..3e75e9e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -382,7 +382,19 @@ static int
kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
break;
}
-size = ALIGN(((mem-memory_size) TARGET_PAGE_BITS), HOST_LONG_BITS)
/ 8;
+ /* XXX bad kernel interface alert
+ * For dirty bitmap, kernel allocates array of size aligned to
+ * bits-per-long. But for case when the kernel is 64bits and
+ * the userspace is 32bits, userspace can't align to the same
+ * bits-per-long, since sizeof(long) is different between kernel
+ * and user space. This way, userspace will provide buffer which
+ * may be 4 bytes less than the kernel will use, resulting in
+ * userspace memory corruption (which is not detectable by valgrind
+ * too, in most cases).
+ * So for now, let's align to 64 instead of HOST_LONG_BITS here, in
+ * a hope that sizeof(long) wont become 8 any time soon.
+ */
+size = ALIGN(((mem-memory_size) TARGET_PAGE_BITS),
/*HOST_LONG_BITS*/ 64) / 8;
if (!d.dirty_bitmap) {
d.dirty_bitmap = qemu_malloc(size);
} else if (size allocated_size) {
--
1.7.2.5
--
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: openbsd system_powerdown: KVM internal error. Suberror: 1
21.03.2011 12:43, Avi Kivity wrote: On 03/17/2011 10:18 PM, Michael Tokarev wrote: [] 47965.428791: kvm_exit: reason npf rip 0xd020203a 47965.428791: kvm_page_fault: address bfff0 error_code 4 47965.428792: kvm_emulate_insn: 0:d020203a: 5a (prot32) 47965.428792: kvm_mmio: mmio unsatisfied-read len 4 gpa 0xbfff0 val 0x0 47965.428793: kvm_mmio: mmio read len 4 gpa 0xbfff0 val 0xb100 47965.428794: kvm_entry: vcpu 0 47965.428795: kvm_exit: reason npf rip 0xd020203b 47965.428795: kvm_page_fault: address bfff4 error_code 4 47965.428795: kvm_emulate_insn: 0:d020203b: 59 (prot32) 47965.428796: kvm_mmio: mmio unsatisfied-read len 4 gpa 0xbfff4 val 0x0 47965.428797: kvm_mmio: mmio read len 4 gpa 0xbfff4 val 0x0 47965.428797: kvm_entry: vcpu 0 47965.428798: kvm_exit: reason npf rip 0xd020203c 47965.428798: kvm_page_fault: address bfff8 error_code 4 47965.428799: kvm_emulate_insn: 0:d020203c: 58 (prot32) That's a POP instruction. So openbsd mapped the stack into the framebuffer, and kvm has to emulate everything. Please post a complete binary trace from bootup until the host_state_reload issue appears. http://95.84.243.119:8000/tmp/kvm-obsd/ -- that's the whole thing. There, trace.dat.gz and trace.txt.gz are the complete traces from trace-cmd from the beginning to the login prompt. I don't think it's easy to catch the place when host_state_reloads starts increasing - it happens during boot before userspace takes control, while in kernel (during this time the text on the screen - bootup progress - in on a strange background color). The difficulty is because during that time there are lots of other activity on kvm side - number of exits and emulations for example. Also, obsd4.8-32bit.qcow2.xz is the disk image of openbsd install which I used for all these tests - it's 112 Mb compressed, about 600Mb uncompressed, 2Gb virtual size. This is here in order for me to stop acting as a broken phone (but I can continue doing so just fine - I just think it's a bit less productive this way :) I've shown this file to Gleb Natapov (Cc'd) before too (who tried to debug the insane amount of host_state_reload issue. This is a default openbsd install from their current installation cdrom, so anyone can create their own disk image too, obviously. I run it just like kvm -hda obsd4.8-32bit.qcow2 -snapshot -net none (and it can use rtl8139 NIC). Root password is 12, but there's no need to login since all the problems happens before login. In order to trigger the error in $subject, wait till it's idle (which happens right after login: prompt) and send system_powerdown command (I use -monitor stdio) - in about 5 seconds from there it'll error out. In order to catch this error it's better to use kvm 0.12 (it works with current seabios under freebsd since graphics mode isn't used) -- current 0.14 behaves badly after KVM internal error (which needs to be improved a bit too, I think) 47965.428799: kvm_mmio: mmio unsatisfied-read len 4 gpa 0xbfff8 val 0x0 47965.428801: kvm_mmio: mmio read len 4 gpa 0xbfff8 val 0x30 47965.428801: kvm_entry: vcpu 0 47965.428802: kvm_exit: reason vintr rip 0xd0202041 47965.428802: kvm_inj_virq: irq 81 47965.428802: kvm_inj_virq: irq 81 47965.428803: kvm_entry: vcpu 0 47965.428803: kvm_exit: reason npf rip 0xd0202041 47965.428804: kvm_page_fault: address bfffc error_code 6 47965.428804: kvm_emulate_insn: 0:d0202041: cf (prot32) 47965.428805: kvm_emulate_insn: 0:d0202041: cf (prot32) failed We don't emulate IRET-with-mmio-stack. Note that the whole this story - two issues with OpenBSD - is pure my luck - I don't use openbsd, never used it before, and don't actually plan to use in a near future. We debugged an unrelated problem (a bug in linux nfs server) and tried to perform various interoperability tests (installing various operating systems in kvm), and found out that OpenBSD behaves somewhat.. unexpectedly in kvm. So I went on and performed a few tests locally (installing OpenBSD for the first time ever), which resulted in 2 my bugreports. I'm not sure how important OpenBSD support for kvm is, and if it's something which better be done in OpenBSD itself instead of kvm. (This all is not to say I wont help resolving these issues - quite the opposite, I'm willing to help, but I think my help in a form of broken phone isn't of much value :) Thanks! /mjt -- 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 lock contention on 48 core AMD machine
21.03.2011 20:12, Eric Dumazet wrote: Le lundi 21 mars 2011 à 19:02 +0200, Avi Kivity a écrit : Any ideas on how to fix it? We could pre-allocate IDs and batch them in per-cpu caches, but it seems like a lot of work. Hmm, I dont know what syscalls kvm do, but even a timer_gettime() has to lock this idr_lock. I wonder why my testcase - 160 kvm guests on a 2-core AMD AthlonII CPU - shows no contention of that sort, not at all... Yes sure, all these (linux) guests are idling at login: prompt, but I'd expect at least some gettimeofday() and some load average, -- everything stays close to zero. /mjt -- 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: openbsd system_powerdown: KVM internal error. Suberror: 1
17.03.2011 20:52, Marcelo Tosatti wrote: [] iret emulation is only partially implemented. Why is iret faulting in the first place i don't know. Can you enable tracing with echo kvm /$debugfs/tracing/set_event And save the tail of the log, including events at $RIP? Something like the one below (with the error at the end)? What do you mean events at $RIP ? I see 2 patterns here with references to $RIP. Many like this: kvm-0.12.5-1301 [001] 47965.427622: kvm_page_fault: address fee00080 error_code 6 kvm-0.12.5-1301 [001] 47965.427622: kvm_emulate_insn: 0:d0202002: 89 1d 80 00 99 d0 (prot32) kvm-0.12.5-1301 [001] 47965.427623: kvm_mmio: mmio write len 4 gpa 0xfee00080 val 0x30 kvm-0.12.5-1301 [001] 47965.427623: kvm_apic: apic_write APIC_TASKPRI = 0x30 kvm-0.12.5-1301 [001] 47965.427624: kvm_entry: vcpu 0 kvm-0.12.5-1301 [001] 47965.427625: kvm_exit: reason vintr rip 0xd0202041 kvm-0.12.5-1301 [001] 47965.427625: kvm_inj_virq: irq 81 kvm-0.12.5-1301 [001] 47965.427625: kvm_inj_virq: irq 81 kvm-0.12.5-1301 [001] 47965.427626: kvm_entry: vcpu 0 kvm-0.12.5-1301 [001] 47965.427627: kvm_exit: reason npf rip 0xd02024f1 kvm-0.12.5-1301 [001] 47965.427627: kvm_page_fault: address fee00080 error_code 4 which are repeated without changes over and over again. And at the end, several like this: kvm-0.12.5-1301 [001] 47965.428634: kvm_entry: vcpu 0 kvm-0.12.5-1301 [001] 47965.428635: kvm_exit: reason npf rip 0xd020203a kvm-0.12.5-1301 [001] 47965.428635: kvm_page_fault: address bfffc error_code 4 kvm-0.12.5-1301 [001] 47965.428635: kvm_emulate_insn: 0:d020203a: 5a (prot32) kvm-0.12.5-1301 [001] 47965.428636: kvm_mmio: mmio unsatisfied-read len 4 gpa 0xbfffc val 0x0 kvm-0.12.5-1301 [001] 47965.428637: kvm_mmio: mmio read len 4 gpa 0xbfffc val 0xb100 kvm-0.12.5-1301 [001] 47965.428637: kvm_entry: vcpu 0 kvm-0.12.5-1301 [001] 47965.428638: kvm_exit: reason vintr rip 0xd0202041 kvm-0.12.5-1301 [001] 47965.428638: kvm_inj_virq: irq 81 kvm-0.12.5-1301 [001] 47965.428638: kvm_inj_virq: irq 81 kvm-0.12.5-1301 [001] 47965.428639: kvm_entry: vcpu 0 kvm-0.12.5-1301 [001] 47965.428640: kvm_exit: reason npf rip 0xd02024cc kvm-0.12.5-1301 [001] 47965.428640: kvm_page_fault: address bfffc error_code 6 kvm-0.12.5-1301 [001] 47965.428640: kvm_emulate_insn: 0:d02024cc: 6a 03 (prot32) kvm-0.12.5-1301 [001] 47965.428641: kvm_mmio: mmio write len 4 gpa 0xbfffc val 0x3 (with different kvm_emulate_insn each time), which finally ends with kvm-0.12.5-1301 [001] 47965.428804: kvm_emulate_insn: 0:d0202041: cf (prot32) kvm-0.12.5-1301 [001] 47965.428805: kvm_emulate_insn: 0:d0202041: cf (prot32) failed Note it's the same openbsd which triggers insane amount of host_state_reloads, so the trace is quite, well, large :) Thanks! /mjt $ kvm-0.12.5 -drive file=obsd.raw,snapshot=on -net none -monitor stdio QEMU 0.12.5 monitor - type 'help' for more information (qemu) system_powerdown (qemu) KVM internal error. Suberror: 1 rax 0030 rbx rcx rdx b100 rsi d0201fc6 rdi d0ac1ad4 rsp d438d004 rbp d4492e1c r8 r9 r10 r11 r12 r13 r14 r15 rip d0202041 rflags 0292 cs 0050 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) ds 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0058 (d0ac1aa0/03db p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) tr 0078 (d4491000/0333 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0018 (d0a31580/0087 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt d42b1000/ idt d0a31620/7ff cr0 8001003b cr2 8adaa850 cr3 737 cr4 780 cr8 3 efer 0 emulation failure, check dmesg for details (qemu) x/20i 0xd0202036 0xd0202036: pop%edi 0xd0202037: pop%esi 0xd0202038: pop%ebp 0xd0202039: pop%ebx 0xd020203a: pop%edx 0xd020203b: pop%ecx 0xd020203c: pop%eax 0xd020203d: sti 0xd020203e: add$0x8,%esp 0xd0202041: iret 0xd0202042: mov%esi,%esi 0xd0202044: mov$0x70,%eax 0xd0202049: mov%eax,0xd0990080 0xd020204e: sti 0xd020204f: push $0x2 0xd0202051: call 0xd0570470 0xd0202056: add$0x4,%esp 0xd0202059: jmp*%esi 0xd020205b: nop 0xd020205c: mov$0x40,%eax (qemu) q # tail -500 /sys/kernel/debug/tracing/trace | sed 's|^.*\] ||'
Re: *insane* amount of host_state_reloads for openbsd guest in 0.14
16.03.2011 22:48, Marcelo Tosatti wrote: On Fri, Mar 11, 2011 at 03:02:33PM +0300, Michael Tokarev wrote: I tried Openbsd 4.8 in kvm today and immediately noticed that it is running _very_ slow, boot takes several minutes to complete to the login: prompt. After investigating I found that kvm does really insane amount of host_state_reloads. Here are typical kvm_stats: During bootup while checking/mounting filesystems etc: host_state_reload 13782074 671689 exits 24071297 45751 insn_emulation21707073 45353 io_exits 6900215 288 [] After booting, idle guest sitting at login: prompt: host_state_reload 28675531 44171 exits 251841083379 insn_emulation227844903266 irq_injections 54139 200 [] So I played with various options for a bit and found that: o 0.14 -no-kvm-irqchip gets rid of host_state_reloads, making them to be the same (+/-100) as insn_emulations, and speeds up guest significantly (and lowers CPU usage on host during guest idle time). o 0.14 -no-kvm makes the guest *faster* than w/o any additional options, reducing boot time for about 50% (but increasing host CPU usage to maximum) o 0.12 without any options is the fastest, and it keeps number of reloads to be within 3k/sec range during all time. here's typical kvm_stats of idle guest with 0.12: Perhaps OpenBSD is accessing the HPET frequently, which is emulated in userspace. Try disabling it with -no-hpet. -no-hpet makes no visible difference, exactly the same thing as above: host_state_reload 21310655 43968 exits 250075993573 insn_emulation226352013469 Thanks! /mjt -- 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: openbsd system_powerdown: KVM internal error. Suberror: 1
16.03.2011 22:44, Marcelo Tosatti wrote: On Fri, Mar 11, 2011 at 02:54:00PM +0300, Michael Tokarev wrote: Hello. I installed an openbsd 4.8 image today to play with, and noticed that when issuing system_powerdown in kvm monitor, in about 5 seconds, qemu-kvm spews this message in a tight loop: KVM internal error. Suberror: 1 emulation failure KVM internal error. Suberror: 1 emulation failure ad infinitum, until interrupted. I verified the issue exists in 0.14 and 0.12 qemu-kvm, both 32 and 64bits. Freebsd does not trigger this behavour, it is running normally. kvm-0.12.5 behaves somewhat more sane in this case too, it prints some more information: KVM internal error. Suberror: 1 rax 0030 rbx rcx rdx b100 rsi d0201fc6 rdi d0ac1ad4 rsp d9651004 rbp d9759a38 r8 r9 r10 r11 r12 r13 r14 r15 rip d0202041 rflags 0292 [] Can you stop the guest and issue: x/10i 0xd0202041 (qemu) KVM internal error. Suberror: 1 rax 0030 rbx rcx d0a3200c rdx rsi d0201fc6 rdi d0ac1ad4 rsp d438d008 rbp d4495f08 r8 r9 r10 r11 r12 r13 r14 r15 rip d0202041 rflags 0282 cs 0050 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) ds 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0058 (d0ac1aa0/03db p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) tr 0078 (d4494000/0333 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0018 (d0a31580/0087 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt d42b1000/ idt d0a31620/7ff cr0 8001003b cr2 3c0029b0 cr3 71d8000 cr4 780 cr8 3 efer 0 emulation failure, check dmesg for details (qemu) x/20i 0xd0202036 0xd0202036: pop%edi 0xd0202037: pop%esi 0xd0202038: pop%ebp 0xd0202039: pop%ebx 0xd020203a: pop%edx 0xd020203b: pop%ecx 0xd020203c: pop%eax 0xd020203d: sti 0xd020203e: add$0x8,%esp 0xd0202041: iret 0xd0202042: mov%esi,%esi 0xd0202044: mov$0x70,%eax 0xd0202049: mov%eax,0xd0990080 0xd020204e: sti 0xd020204f: push $0x2 0xd0202051: call 0xd0570470 0xd0202056: add$0x4,%esp 0xd0202059: jmp*%esi 0xd020205b: nop 0xd020205c: mov$0x40,%eax The guest stops automatically after that message, so no need to stop it. The address (rip) is the same as before, so it's repeatable. I was using 0.12.5 for this, with 0.14 it's impossible to do anything after the Emulation error anymore, it spews these error messages too fast. What interesting is that there's some race condition somewhere there: I tried 4 times, first the guest just suddenly rebooted right after system_powerdown (not shut down, it was a sudden reboot), next it went into the above situation, next (after restart) it rebooted again, also suddenly, next it come into emulation error. It can do one or another, more or less randomly, but the above emulation error is quite a bit more common. Thanks! /mjt -- 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
openbsd system_powerdown: KVM internal error. Suberror: 1
Hello. I installed an openbsd 4.8 image today to play with, and noticed that when issuing system_powerdown in kvm monitor, in about 5 seconds, qemu-kvm spews this message in a tight loop: KVM internal error. Suberror: 1 emulation failure KVM internal error. Suberror: 1 emulation failure ad infinitum, until interrupted. I verified the issue exists in 0.14 and 0.12 qemu-kvm, both 32 and 64bits. Freebsd does not trigger this behavour, it is running normally. kvm-0.12.5 behaves somewhat more sane in this case too, it prints some more information: KVM internal error. Suberror: 1 rax 0030 rbx rcx rdx b100 rsi d0201fc6 rdi d0ac1ad4 rsp d9651004 rbp d9759a38 r8 r9 r10 r11 r12 r13 r14 r15 rip d0202041 rflags 0292 cs 0050 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) ds 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0058 (d0ac1aa0/03db p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) tr 0078 (d9758000/0333 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0018 (d0a31580/0087 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt d9575000/ idt d0a31620/7ff cr0 8001003b cr2 dcd cr3 1f202000 cr4 780 cr8 3 efer 0 emulation failure, check dmesg for details As far as I can see, this is just a one-time message in 0.12. Dmesg (on host) is completely silent. -no-kvm-irqchip does not help either (I tried it for a different reason but decided to check this case too, while at it). Host kernel is 2.6.37-2 (with e5d135f80b98b0 + 2607b0533353c applied after yesterdays freebsd issues), 64bit, running on amd AthlonII CPU. In all cases guests were with -smp 1, and without any fancy options (just -hda -m). Openbsd 4.8 32bit. I see two issues here: one is the emulation failure and another is the erratic behavour of kvm-0.14 - issuing that error message in a tight loop. Thanks! /mjt -- 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
*insane* amount of host_state_reloads for openbsd guest in 0.14
I tried Openbsd 4.8 in kvm today and immediately noticed that it is running _very_ slow, boot takes several minutes to complete to the login: prompt. After investigating I found that kvm does really insane amount of host_state_reloads. Here are typical kvm_stats: During bootup while checking/mounting filesystems etc: host_state_reload 13782074 671689 exits 24071297 45751 insn_emulation21707073 45353 io_exits 6900215 288 mmio_exits 20057 226 irq_injections6533 223 pf_fixed 9801 176 mmu_pte_write17781 111 irq_exits 6490 20 fpu_reload 133 1 halt_exits 422 0 mmu_cache_miss 333 0 halt_wakeup 30 0 mmu_shadow_zapped 358 0 remote_tlb_flush 3 0 signal_exits 1 0 After booting, idle guest sitting at login: prompt: host_state_reload 28675531 44171 exits 251841083379 insn_emulation227844903266 irq_injections 54139 200 mmio_exits 52748 122 mmu_pte_write41584 100 halt_exits 22731 99 irq_exits 9220 12 io_exits 6912620 9 fpu_reload 765 1 pf_fixed 12419 0 mmu_shadow_zapped 358 0 mmu_cache_miss 339 0 halt_wakeup 38 0 remote_tlb_flush 3 0 signal_exits 1 0 So I played with various options for a bit and found that: o 0.14 -no-kvm-irqchip gets rid of host_state_reloads, making them to be the same (+/-100) as insn_emulations, and speeds up guest significantly (and lowers CPU usage on host during guest idle time). o 0.14 -no-kvm makes the guest *faster* than w/o any additional options, reducing boot time for about 50% (but increasing host CPU usage to maximum) o 0.12 without any options is the fastest, and it keeps number of reloads to be within 3k/sec range during all time. here's typical kvm_stats of idle guest with 0.12: kvm 0.12 and idle guest: exits 259756003329 insn_emulation235552723229 host_state_reload 18985753117 irq_injections 13125 200 mmio_exits 26603 122 mmu_pte_write61515 100 halt_exits5173 100 irq_exits 6927 1 fpu_reload 499 1 io_exits 7058999 1 pf_fixed 11902 0 mmu_shadow_zapped 634 0 mmu_cache_miss 558 0 halt_wakeup166 0 remote_tlb_flush 2 0 signal_exits 1 0 Again, running on the same AthlonII machine with 2.6.37 host kernel, freshly installed openbsd 4.3 32bit guest (with all defaults). FreeBSD does not show this behavour. What it can be? Thanks! /mjt -- 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
FreeBSD boot hangs on qemu-kvm on AMD host
Hello. Dominik Klein (Cc'd) reported on irc that current FreeBSD release hangs at boot in qemu-kvm. It is trivially verifiable by d/loading the bootonly FreeBSD 8.2 CD image from ftp.freebsd.org and running kvm -cdrom FreeBSD-8.2-RELEASE-amd64-bootonly.iso. The guest unpacks kernel, draws a menu (apparently in real kernel already, not in the boot loader) and starts a 10-second countdown. At this point it just stops (either at 10 or 9, ie, right at the beginning of the cycle) and kvm process starts using 100% of the CPU core given to it. With this typical kvm_stats from qemu-kvm 0.14: kvm statistics exits 43397783 1400960 halt_exits42862622 1400769 irq_exits 5487 172 host_state_reload 300074 101 io_exits292212 18 irq_injections 768 18 halt_wakeup257 3 mmu_pte_write 7702163 0 insn_emulation 378273 0 mmio_exits 15786 0 pf_fixed 4817 0 mmu_shadow_zapped 170 0 mmu_cache_miss 151 0 remote_tlb_flush 2 0 signal_exits 1 0 fpu_reload 1 0 I tried i386 and amd64 guest images, and tried the same thing with qemu-kvm 0.12.5 and 0.14.0 - the effect is exactly the same. So far the 3 affected systems where we tried this are all AMD machines. My home box is AthlonII, my work box is PhenomI 9750, and Dominik tries it on Opteron 6174. Running it with -no-kvm lets the guest to go (but obviously very slow). Using -no-kvm-irqchip helps too. Any guess what it can be? Thanks! /mjt -- 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
