Re: [kvm-devel] portability layer?
Hollis Blanchard wrote: >> 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. > > If it can be avoided I'm all for it. >> 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. > > Ah, _those_ higher layer tools. Each of these interfaces needs to be stabilized for different reasons: - the kernel ABI allows the kernel and userspace to be upgraded independently - libkvm is mainly for when we've merged all our changes into mainline qemu, and for the theoretical second user - the qemu monitor is for the higher level tools Note that the qemu monitor (and commandline) interface is under the control of the qemu maintainers, not us. So far it has been steadily improving. >> [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. > The stable ABI here is just the support baseline, not a freeze. We know for certain that changes are needed for smp, paravirt drivers, new hardware virtualization extensions, and new archs. And of course it only holds for x86; other archs will stabilize when they are ready. -- 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.php&p=sourceforge&CID=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
Leslie Mann wrote: > 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. > > Ah, Windows sets a timeout when loading drivers, and of course strace slows down the initial screen clear. You can try attaching strace with the '-p' option, just before connecting. This will reduce the log size greatly. I should have thought of it before. -- 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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFT] Possible fix for 32-bit guests
Attached is a patch that fixes problems with 32-bit guests on 64-bit
hosts. For example, I got damn small linux 0.4.10 to boot with this;
previously it segfaulted during init.
If you have issues with 32-bit guests, please test with this patch and
report. Even if you don't have any issues, testing your usual guests is
appreciated.
--
error compiling committee.c: too many arguments to function
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 7513cdd..daff430 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -832,10 +832,8 @@ done_prefixes:
dst.type = OP_MEM;
dst.ptr = (unsigned long *)cr2;
dst.bytes = (d & ByteOp) ? 1 : op_bytes;
- if (d & BitOp) {
- dst.ptr += src.val / BITS_PER_LONG;
- dst.bytes = sizeof(long);
- }
+ if (d & BitOp)
+ dst.ptr += src.val / (dst.bytes * 8);
if (!(d & Mov) && /* optimisation - avoid slow emulated read */
((rc = ops->read_emulated((unsigned long)dst.ptr,
&dst.val, dst.bytes, ctxt)) != 0))
-
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.php&p=sourceforge&CID=DEVDEV___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
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
Re: [kvm-devel] VT-x and Performance counter interrupt in KVM mode
Stephane Eranian wrote: > >> 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. > It is a little different, but perhaps not enough. If perfmon is the only nmi source, or if you can find out the source of the nmi, then you don't need to take the nmi but can instead call the perfmon handler. Otherwise we'd need to dispatch interrupts manually. > 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. You certainly need to go through the apic for correctness, using a signal like you outlined before might be a good interim solution. > Is there a plan to move the > APIC emulation into KVM? > > Yes. It's needed for smp and kernel-only paravirt devices. >> 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. > > Ok. I'm just glad I don't have to do it ;-) > >> - 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. > If the host wants system-wide monitoring (% cpu / tlb miss / whatever in each process, including vms) and a vm wants monitoring too, then you don't have enough resources to go round. There's a similar problem with the debug registers; if the host wants to debug a guest, which is itself debugging a process, something has to give. -- 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.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] portability layer?
Hollis Blanchard wrote: > 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. :) > No, I'm saying that some #ifdeffery in both libkvm and the ioctl interface is unavoidable. A trivial example is kvm_get_regs(). If you want to do anything other than memcpy() the result, the caller has to be nonportable. kvm_setup_cpuid() doesn't make sense on ppc, as you said. The in*/out* callbacks don't belong, and there will probably be a few callbacks that will leave me puzzled when you add them. The fact is that the "higher level tools" will emulate a powerpc when running on a powerpc, and an x86 when running on an x86. That's different from a webserver which is implementing the http protocol no matter what the underlying platform is. That's what I meant by "inherently nonportable". > 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.) > > A function like sys_read() can be made reasonably portable, but injecting an interrupt into an x86 requires peeking into a register which is aliased to an mmio location (cr8/tpr). No doubt ppc has its own wierdnesses, but they'll be different. Right now this is handled by qemu, which means our higher level tools are _already_ nonportable. >> 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 implementation is, but the interface and use is generic. The dirty log is used for two purposes: - minimization of screen updates on framebuffer changes - tracking pages which need to be re-copied during live migration Hopefully the interface and some parts of the kernel code can be reused. The memory slots thing is just a way for userspace to specify physically discontiguous memory. Each slot is contiguous within itself, but different slots may be discontiguous. It is used for the framebuffer, and for various memory holes in x86 (640KB-1MB and the pci hole). > >> 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. > Just #ifdef the x86 specific parts away, and add your own magic where necessary. > 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. > Well, libkvm is _an_ official interface. Any changes needed to make it portable are welcome. [I have a feeling we're talking a little past each other, probably due to me not knowing ppc at any level o
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.php&p=sourceforge&CID=DEVDEV __
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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1689714 ] further bug using vnc
Bugs item #1689714, was opened at 2007-03-28 10:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1689714&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: das mensch (das_mensch)
Assigned to: Nobody/Anonymous (nobody)
Summary: further bug using vnc
Initial Comment:
just started kvm-18 32bit with -no-kvm (because of kernel-oops, see #1634816,
2007-03-28 10:15), starting win2k-setup, short time later I get a segfault:
Program received signal SIGSEGV, Segmentation fault.
0x081de074 in memset ()
(gdb) up
#1 0x080b6ca7 in framebuffer_update_request (vs=0x9db1db8, incremental=0,
x_position=0, y_position=42, w=640, h=146)
at /usr/src/kernel/kvm-18/qemu/vnc.c:863
863 memset(old_row, 42, vs->ds->width * vs->depth);
(gdb) print old_row
$1 = 0xa75f9000
(gdb) print vs
$2 = (VncState *) 0x9db1db8
(gdb) print vs->ds
$3 = (DisplayState *) 0x8301060
(gdb) print vs->ds->width
$4 = 720
(gdb) print *(vs->ds)
$5 = {data = 0xa71c8008 "š", linesize = 2880, depth = 32, bgr = 0, width = 720,
height = 396, opaque = 0x9db1db8,
dpy_update = 0x80b3dd0 , dpy_resize = 0x80b3ee0
, dpy_refresh = 0x80b61f0 ,
dpy_copy = 0x80b5ba0 }
(gdb) print *(vs)
$6 = {timer = 0x9e88308, lsock = 11, csock = 16, ds = 0x8301060, need_update =
1, width = 640, height = 400, dirty_row = {{
4294967295, 8191, 0, 0} , {0, 7936, 0, 0}, {0, 7936,
0, 0}, {0, 7936, 0, 0}, {4294967295, 4294967295,
4294967295, 4294967295} }, old_data = 0xa74e2008 '*'
..., depth = 4, has_resize = 0,
has_hextile = 1, has_pointer_type_change = 0, absolute = 0, last_x = 895,
last_y = 326,
display = 0xbffc0bd9 "192.168.235.33:802", output = {capacity = 23114, offset
= 0, buffer = 0x9ee9020 ""}, input = {
capacity = 5120, offset = 10, buffer = 0x9ebd6e0 "\003"}, kbd_layout =
0x9db9f58,
write_pixels = 0x80b4030 , send_hextile_tile =
0x80b4e30 , pix_bpp = 0,
pix_big_endian = 0, red_shift = 0, red_max = 0, red_shift1 = 0, green_shift =
0, green_max = 0, green_shift1 = 0,
blue_shift = 0, blue_max = 0, blue_shift1 = 0, read_handler = 0x80b70a0
, read_handler_expect = 10,
modifiers_state = '\0' }
(gdb)
no fix yet, because I have to work on other things now...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1689714&group_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.php&p=sourceforge&CID=DEVDEV
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1689688 ] bug using vnc
Bugs item #1689688, was opened at 2007-03-28 10:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1689688&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: das mensch (das_mensch)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug using vnc
Initial Comment:
rather a qemu-bug:
after closing the vnc-window (because it doesn't resize if the guest changes
the resolution) I get this:
Program received signal SIGSEGV, Segmentation fault.
0x0805022a in main_loop_wait (timeout=165391440) at
/usr/src/kernel/kvm-18/qemu/vl.c:6203
6203ioh->fd_write(ioh->opaque);
(gdb) print ioh
$1 = (IOHandlerRecord *) 0x9e8a328
(gdb) print *ioh
$2 = {fd = 166535168, fd_read_poll = 0, fd_read = 0x80b6800 ,
fd_write = 0, opaque = 0x9db1e40, ufd = 0x0,
next = 0x9dbac50}
simple to fix:
@@ -6196,10 +6197,10 @@ void main_loop_wait(int timeout)
/* XXX: better handling of removal */
for(ioh = first_io_handler; ioh != NULL; ioh = ioh_next) {
ioh_next = ioh->next;
-if (FD_ISSET(ioh->fd, &rfds)) {
+if (FD_ISSET(ioh->fd, &rfds) && (ioh->fd_read)) {
ioh->fd_read(ioh->opaque);
}
-if (FD_ISSET(ioh->fd, &wfds)) {
+if (FD_ISSET(ioh->fd, &wfds) && (ioh->fd_write)) {
ioh->fd_write(ioh->opaque);
}
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1689688&group_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.php&p=sourceforge&CID=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=detail&atid=893831&aid=1689684&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 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=detail&atid=893831&aid=1689684&group_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.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
