Re: [kvm-devel] kvm-18 breaks Cisco VPN on WinXP SP1
Leslie Mann wrote: kvm-18 has broken use of Cisco VPN client on WinXP SP1 running on a FC6 2.6.19-1.2911 client, Intel Core Duo system. I have been running successfully from kvm-11 thru kvm-17 without issue. After upgrading to kvm-18 any attempts to connect the VPN client result in an unresponsive X11 session (still can exit with ctrl-alt-bksp). Reverting to the kvm-17 modules works fine. Any suggestions on how to troubleshoot or fix? Is there anything in dmesg? Nope. After a bit more review it appears that only qemu is hung. I can switch to a console and back but can't release input from qemu. Can you run qemu under strace -ttT? Be prepared for a long log. Also, checking with the -no-kvm option is worthwhile. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1689684 ] 64bit problem
Bugs item #1689684, was opened at 2007-03-28 10:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1689684group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: das mensch (das_mensch) Assigned to: Nobody/Anonymous (nobody) Summary: 64bit problem Initial Comment: kvm-16 and -18 tried: 64bit: kernel works, various programs work in 64bit and 32bit, but qemu dies while initializing itself in an aio-call. unfortunately I haven't had enough time to trace this completely down, it *may* depend on my local libpthread --- I will check this soon (perhaps others have similar problems?) maybe it is possible to make the kvm-device arch-compatible to run 32bit-kvm-app on 64bit kernel/module? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1689684group_id=180599 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] portability layer?
On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote: Hollis Blanchard wrote: Hi Avi, I was wondering what you think is the right abstraction layer to target for porting KVM to non-x86 architectures? To me it looks like libkvm is the answer. The kernel/userland interface is heavily x86-specific, including things like struct kvm_run. So it looks like the higher-level API of kvm_init(), kvm_create(), etc would be the right cut? struct kvm_callbacks is even reasonably portable, especially if cpuid is hidden behind an arch callback. Disclaimer: I know little about powerpc (or ia64). What I say may or may not have any connection with reality. I don't think we should be aiming at full source portability. Virtualization is inherently nonportable, and as it is mostly done in hardware, software gets to do the quirky stuff that the hardware people couldn't bother with :) instead we should be aiming at code reuse. I'm not sure I see the distinction you're making. Operating systems could also be considered inherently nonportable, yet Linux and the BSDs support an enormous range of platforms. If you're saying that we shouldn't try to run x86 MMU code on a PowerPC then I can't agree more. :) Aside from code reuse though (on which I absolutely agree), it's critical that the interface be the same, i.e. each architecture implements the same interface in different ways. With that, all the higher-level tools will work with minimal modification. (This is analogous to an OS interface like POSIX.) I think there's some potential there: - memory slot management, including the dirty log, could be mostly reused (possibly updated for multiple page sizes). possibly msrs as well. I'm not familiar with KVM's memory slots or dirty log. My first impression was that the dirty log is tied to the x86 shadow pagetable implementation, but I admit I haven't investigated further. - the vcpu management calls (get regs/set regs, vcpu_run) can be reused, but only as wrappers. The actual contents (including the kvm_run structure) would be very different. Right, each architecture would define its own, and all code that touches these data structures would be moved out of common code. I don't see a big difference between the ioctl layer and libkvm. In general, a libkvm function is an ioctl, and kvm_callback members are a decoding of kvm_run fields. If you edit kvm_run to suit your needs, you can probably reuse some of it. kvm_run as it stands is 100% x86-specific. (I doubt it could even be easily adapted for ia64, which is more similar to x86 than PowerPC.) So right now the kernel ioctl interface has an architecture-specific component, which violates the principle of identical interfaces I described earlier. That means we either a) need to change the kernel interface or b) define a higher-level interface that *is* identical. That higher-level interface would be libkvm, hence my original question. Does my original question make more sense now? If you make libkvm the official interface, you would at least need to hide the cpuid callback, since it is intimately tied to an x86 instruction. -Hollis - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] portability layer?
On Wednesday 28 March 2007, Hollis Blanchard wrote: I don't see a big difference between the ioctl layer and libkvm. In general, a libkvm function is an ioctl, and kvm_callback members are a decoding of kvm_run fields. If you edit kvm_run to suit your needs, you can probably reuse some of it. kvm_run as it stands is 100% x86-specific. (I doubt it could even be easily adapted for ia64, which is more similar to x86 than PowerPC.) So right now the kernel ioctl interface has an architecture-specific component, which violates the principle of identical interfaces I described earlier. Remember that there _is_ an equivalent of kvm_run on powerpc (not powerpc64) inside of MacOnLinux, though I could not find it now when looking through the source. That means we either a) need to change the kernel interface or b) define a higher-level interface that *is* identical. That higher-level interface would be libkvm, hence my original question. Does my original question make more sense now? If you make libkvm the official interface, you would at least need to hide the cpuid callback, since it is intimately tied to an x86 instruction. If there is going to be an architecture independent interface, it should really be able to cover s390 as well, which has yet other requirements. It's probably closer to amd64 than to powerpc64 though. Arnd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] VT-x and Performance counter interrupt in KVM mode
Avi, On Tue, Mar 27, 2007 at 07:10:58PM +0200, Avi Kivity wrote: The Performance counters (PMU) cannot be fully virtualized, they need to run on the actual MSR registers. The PMU interrupt is controlled by the local APIC. To get overflow-based sampling to work in a guest, we need to allow the PMU to interrupt. Supposing we have allowed wrmsr,rdmsr to the PMU registers, the guest perfmon will setup the virtual APIC and virtual IDT as it normally would on real HW. VT-x takes care of the IDT but not of the APIC. The guest never touches the real APIC, qemu handles this. However if the host kernel is running perfmon, it does already have the actual APIC programmed for the PMU. In this configuration, the host perfmon interrupt driver catches the PMU interrupt generated while running in non-root VMX mode. At that point, there is a VM-exit. I have now been able to track down the type of exit in this case. You have a VM-exit for an external interrupt, which is fine, however the intr_info (VM_EXIT_INTR_INFO) is 0x0, in other words, VT-x does not give you any good info as to why you exited. As soon as you leave the VM_RESUME code, you branch to the host perfmon interrupt handler. Actually it can be convinced to give the interrupt number. Right now, we program VT not to ack interrupts, so we don't know their number, and they are dispatched by the processor as soon as we enable interrupts on the host. An alternative mechanism exists. We can tell VT to ack the interrupt, in which case the vector number becomes valid, but we need to dispatch the interrupt ourselves using the 'int' instruction. Ok, I missed that control but I see it now (bit 15). As I'd rather not do that, perhaps we can program the apic to issue an nmi instead of an interrupt while in guest mode. On receipt of nmi, we can call the host perfmon handler directly to interpret the performance counters. Yes, but that would be no different from what I have now without the ack-intr. What you'd like is to catch the PMU intr right away and re-inject it without using the host perfmon interrupt handler. It seem the only way to do this is by acking intr. Unfortunately, it is an all or nothing control. The other worry in this scheme is that the injection would be done without qemu intervening. Thus you would not be able to check whether the virtual APIC LVT vector is curently masked. Its configuration may be different from the actual APIC. But that is probably ok for now. Is there a plan to move the APIC emulation into KVM? In any case, the current solution I have for this is sort of hybrid because you rely on the host APIC to be programmed correctly, and then you need communication between the host perfmon code and the KVM kernel code to be able to inject the PMU interrupt back into the guest. Another solution I have experimented is for the host perfmon to notify the user level qemu APIC code (SIGIO) which then issues the right KVM_INTERRUPT ioctl(), but that is slow and has some rce condition with the guest. That looks promising. The slowness can be addressed by (first) moving to queued signals instead of delivered signals and (later) pushing the apic emulation into the kernel. VT also has a facility to swap msrs on entry to the guest and back. Yes, I am using some of that to stop monitoring when entering KVM. It really depends on what one wants to do with the performance monitor on the guest: - if it's just to shut up the nmi watchdog, we can report a cpu model that does not have the performance monitor (which would be a classic Pentium? or maybe a 486?) No, the goal is to provide full acecss to the PMU for performance monitoring just like you would be able on bare HW. - if we want something like the nmi watchdog to run, we can emulate all counters based on cpu cycles, even if they count branches or something else. That gives an inaccurate but sort-of-working counter, which we can emulate using host timers. No, that's is my goal. I want to allow monitoring tools to run in a guest. I think people would want to assess performance of their applications when running in a guest. You can get the outside view using the host perfmon, but you also want the inside view. - if we want real performance monitoring, we need to do the msr swap. You mean if you do not want to conflict with the host using the PMU for itself? Well, the host perfmon can take care of this. -- -Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net
Re: [kvm-devel] kvm-devel Digest, Vol 6, Issue 61
I was messing around with using the perf counters a couple weeks ago as a way to get deterministic exits in the instruction stream of the guest. I used the h/w msr save/restore area to disable the counters and save the values on guest exit and restore them on entry. I also set up the LVT to deliver NMI's on overflow. This basically worked as expected, but I never got around the problem of inconsistent NMI delivery. A large majority of the time the NMI would be delivered in non-root mode and a vmexit would occur, as expected. Occasionally, though the NMI is delivered in root mode. It seems if the overflow occurs near the time a vmexit occurs for some other reason, the NMI takes long enough to propagate that it's delivered in root mode. Based on Avi's recommendation, I just hacked the host IDT to still do the necessary handling and reset the counters, but I'm interested in whether or not others have seen the same thing. If not, I'm interested in why. I'm still dealing with other synchronization issues and haven't been able to verify if my current approach to using the perf counters will work consistently, but I'd like to avoid the IDT hacking in any case. -Casey The Performance counters (PMU) cannot be fully virtualized, they need to run on the actual MSR registers. The PMU interrupt is controlled by the local APIC. To get overflow-based sampling to work in a guest, we need to allow the PMU to interrupt. Supposing we have allowed wrmsr,rdmsr to the PMU registers, the guest perfmon will setup the virtual APIC and virtual IDT as it normally would on real HW. VT-x takes care of the IDT but not of the APIC. The guest never touches the real APIC, qemu handles this. However if the host kernel is running perfmon, it does already have the actual APIC programmed for the PMU. In this configuration, the host perfmon interrupt driver catches the PMU interrupt generated while running in non-root VMX mode. At that point, there is a VM-exit. I have now been able to track down the type of exit in this case. You have a VM-exit for an external interrupt, which is fine, however the intr_info (VM_EXIT_INTR_INFO) is 0x0, in other words, VT-x does not give you any good info as to why you exited. As soon as you leave the VM_RESUME code, you branch to the host perfmon interrupt handler. Actually it can be convinced to give the interrupt number. Right now, we program VT not to ack interrupts, so we don't know their number, and they are dispatched by the processor as soon as we enable interrupts on the host. An alternative mechanism exists. We can tell VT to ack the interrupt, in which case the vector number becomes valid, but we need to dispatch the interrupt ourselves using the 'int' instruction. Ok, I missed that control but I see it now (bit 15). As I'd rather not do that, perhaps we can program the apic to issue an nmi instead of an interrupt while in guest mode. On receipt of nmi, we can call the host perfmon handler directly to interpret the performance counters. Yes, but that would be no different from what I have now without the ack-intr. What you'd like is to catch the PMU intr right away and re-inject it without using the host perfmon interrupt handler. It seem the only way to do this is by acking intr. Unfortunately, it is an all or nothing control. The other worry in this scheme is that the injection would be done without qemu intervening. Thus you would not be able to check whether the virtual APIC LVT vector is curently masked. Its configuration may be different from the actual APIC. But that is probably ok for now. Is there a plan to move the APIC emulation into KVM? In any case, the current solution I have for this is sort of hybrid because you rely on the host APIC to be programmed correctly, and then you need communication between the host perfmon code and the KVM kernel code to be able to inject the PMU interrupt back into the guest. Another solution I have experimented is for the host perfmon to notify the user level qemu APIC code (SIGIO) which then issues the right KVM_INTERRUPT ioctl(), but that is slow and has some rce condition with the guest. That looks promising. The slowness can be addressed by (first) moving to queued signals instead of delivered signals and (later) pushing the apic emulation into the kernel. VT also has a facility to swap msrs on entry to the guest and back. Yes, I am using some of that to stop monitoring when entering KVM. It really depends on what one wants to do with the performance monitor on the guest: - if it's just to shut up the nmi watchdog, we can report a cpu model that does not have the performance monitor (which would be a classic Pentium? or maybe a 486?) No, the goal is to provide full acecss to the PMU for performance monitoring just like you would be able on bare HW. - if we want something like the nmi watchdog
Re: [kvm-devel] portability layer?
On Wed, 2007-03-28 at 17:48 +0200, Avi Kivity wrote: Hollis Blanchard wrote: On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote: I don't think we should be aiming at full source portability. Virtualization is inherently nonportable, and as it is mostly done in hardware, software gets to do the quirky stuff that the hardware people couldn't bother with :) instead we should be aiming at code reuse. I'm not sure I see the distinction you're making. Operating systems could also be considered inherently nonportable, yet Linux and the BSDs support an enormous range of platforms. If you're saying that we shouldn't try to run x86 MMU code on a PowerPC then I can't agree more. :) No, I'm saying that some #ifdeffery in both libkvm and the ioctl interface is unavoidable. If by #ifdeffery you mean having per-architecture definitions of structures like kvm_regs, absolutely. If you mean literal #ifdefs in the middle a header file, I believe that can and should be avoided. Right now this is handled by qemu, which means our higher level tools are _already_ nonportable. Yes, but not *all* the higher level tools are. At some point you have a common interface, and at this point I think I've answered my own question: the qemu monitor connection is the portable interface. That means everything layered above qemu, such as libvirt and thus virt-manager, should work on all architectures +/- without changes. Lower-level software, such as GDB, would need per-architecture support. [I have a feeling we're talking a little past each other, probably due to me not knowing ppc at any level of detail. No doubt things will become clearer when the code arrives] I don't have any code for you, but you will be the first to know when I do. :) Right now I'm just trying to make sure we don't accidentally paint ourselves into a corner with a stable ABI. -Hollis - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] interrupt preemption support
Avi Kivity wrote: Gregory Haskins wrote: Hi Avi, You make good points. I will convert to a nest lock design and resubmit. Should I use two mutexes, or a mutex and spinlock? Also, do you have any suggestions on the signum I should use to IPI the running guest? Should I use one of the normal signals (SIGUSR) or should I start a block of defined signals in the RT range (32)? For a short term solution, where the apic is in userspace, we can just say ipi == signal, and not require any locking. Qemu will catch the signal and call the appropriate apic function. The signal number should be set from userspace. Note that as long as the apic code is in userspace, the sending side is also in userspace, so all the IPI related stuff doesn't touch the kernel. You can look at a working copy for the PV network code in my git tree git://kvm.qumranet.com/home/dor/src/linux-2.6, pick the pv-network-driver And the matching paravirt-network svn branch. It's working but far from perfect ;) -- error compiling committee.c: too many arguments to function --- -- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVD EV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-18 breaks Cisco VPN on WinXP SP1
Avi Kivity [EMAIL PROTECTED] writes:
Can you run qemu under strace -ttT? Be prepared for a long log.
Also, checking with the -no-kvm option is worthwhile.
Avi:
Can't run under strace. XP starts to boot then blue screens complaining of an
infinite loop in the cirrus driver. I have attached the tail of the strace log.
I have been running display at max, tried dropping resolution to 800x600, 16
bit but same problem.
Runs fine without kvm modules loaded.
Les
22:35:42.634721 --- SIGIO (I/O possible) @ 0 (0) ---
22:35:42.634772 clock_gettime(CLOCK_MONOTONIC, {5485, 85935510}) = 0 0.43
22:35:42.634886 sigreturn() = ? (mask now []) 0.42
22:35:42.635027 ioctl(6, 0xae80, 0) = -1 EINTR (Interrupted system call)
0.000605
22:35:42.635665 --- SIGIO (I/O possible) @ 0 (0) ---
22:35:42.635687 clock_gettime(CLOCK_MONOTONIC, {5485, 86832272}) = 0 0.09
22:35:42.635731 sigreturn() = ? (mask now []) 0.07
22:35:42.635804 ioctl(6, 0xae80, 0) = -1 EINTR (Interrupted system call)
0.000816
22:35:42.636674 --- SIGIO (I/O possible) @ 0 (0) ---
22:35:42.636724 clock_gettime(CLOCK_MONOTONIC, {5485, 87887434}) = 0 0.43
22:35:42.636838 sigreturn() = ? (mask now []) 0.47
22:35:42.636954 ioctl(6, 0xae80, 0) = -1 EINTR (Interrupted system call)
0.000923
22:35:42.637919 --- SIGINT (Interrupt) @ 0 (0) ---
22:35:42.669539 +++ killed by SIGINT +++
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
