Re: [kvm-devel] OpenSolaris 09/2007 (Sun Solaris Express)
Well done Carlo. The patch works perfectly with my OpenSolaris and kvm-53. Thx! El lun, 26-11-2007 a las 19:31 -0600, Carlo Marcelo Arenas Belon escribió: On Wed, Oct 10, 2007 at 03:53:10PM +0200, magicboiz wrote: Sun Solaris Express(9/07), does not detect the hard disk..I attach an screenshot. from the screenshot it seems that the problem is not with the hard disk but with the cdrom. attached patch to qemu (not yet committed upstream) fixed that problem for me. Carlo - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] emulation failed but !mmio_needed? rip 10000 fc 0f 01 15
Neo Jia wrote: Do we need to add a default in x86 emulator switch statement? Take a look at the code. That path is already covered. Avi, I just checkout the latest kvm.git. Please correct me if I am wrong. I don't see the explicit default in swtich (c-b) statement but I found a goto writeback. If the insn decode flag word c-d (derived from opcode_table) is zero, we return early. See the test just after the label 'done_prefixes'. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: Fix compile error caused by no defined CONFIG_X86
Sheng Yang wrote: From c050ed6225f314b86a0dabf11c7f677de097c39f Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Tue, 27 Nov 2007 14:41:06 +0800 Subject: [PATCH] KVM: Fix compile error caused by no defined CONFIG_X86 For linux/kvm.h was included by qemu, which didn't define CONFIG_X86, kvm compiles fail on x86 machines. Using __i386__ and __x86_64__ instead. For use as an exported header (installed in /usr/include) CONFIG_86 is okay, since we run unifdef. For use in development, I added -DCONFIG_X86 to the qemu flags for now. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm: qemu: Fix compile error in non-x86 arch
Sheng Yang wrote: From 5a3ca0556bb3f8b9e18d392535312c370c2dd2f7 Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Tue, 27 Nov 2007 14:51:44 +0800 Subject: [PATCH] kvm: qemu: Fix compile error in non-x86 arch This patch disable PIC/IOAPIC live migration support for non-x86 arch. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Remove build output file in user/test/x86/lib
Neo Jia wrote: From 2d054cce30ae2e837b24144195b9785a20e08c4a Mon Sep 17 00:00:00 2001 From: Neo Jia [EMAIL PROTECTED] Date: Mon, 26 Nov 2007 23:29:53 -0800 Subject: [PATCH] Remove build output file in user/test/x86/lib. This patch will remove the generated files (.*.d, *.o) in directory user/test/x86/lib under arch_clean target of file config-x86-common.mak. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Anthony Liguori wrote: Another point is that virtio still has a lot of leading zeros in its mileage counter. We need to keep things flexible and learn from others as much as possible, especially when talking about the ABI. Yes, after thinking about it over holiday, I agree that we should at least introduce a virtio-pci feature bitmask. I'm not inclined to attempt to define a hypercall ABI or anything like that right now but having the feature bitmask will at least make it possible to do such a thing in the future. No, definitely not define a hypercall ABI. The feature bit should say this device understands a hypervisor-specific way of kicking. consult your hypervisor manual and cpuid bits for further details. should you not be satisfied with this method, port io is still available. I'm wary of introducing the notion of hypercalls to this device because it makes the device VMM specific. Maybe we could have the device provide an option ROM that was treated as the device BIOS that we could use for kicking and interrupt acking? Any idea of how that would map to Windows? Are there real PCI devices that use the option ROM space to provide what's essentially firmware? Unfortunately, I don't think an option ROM BIOS would map well to other architectures. The BIOS wouldn't work even on x86 because it isn't mapped to the guest address space (at least not consistently), and doesn't know the guest's programming model (16, 32, or 64-bits? segmented or flat?) Xen uses a hypercall page to abstract these details out. However, I'm not proposing that. Simply indicate that we support hypercalls, and use some layer below to actually send them. It is the responsibility of this layer to detect if hypercalls are present and how to call them. Hey, I think the best place for it is in paravirt_ops. We can even patch the hypercall instruction inline, and the driver doesn't need to know about it. Yes, paravirt_ops is attractive for abstracting the hypercall calling mechanism but it's still necessary to figure out how hypercalls would be identified. I think it would be necessary to define a virtio specific hypercall space and use the virtio device ID to claim subspaces. For instance, the hypercall number could be (virtio_devid 16) | (call number). How that translates into a hypercall would then be part of the paravirt_ops abstraction. In KVM, we may have a single virtio hypercall where we pass the virtio hypercall number as one of the arguments or something like that. If we don't call it a hypercall, but a virtio kick operation, we don't need to worry about the hypercall number or ABI. It's just a function that takes an argument that's implemented differently by every hypervisor. The default implementation can be a pio operation. Make it appear as a pci function? (though my feeling is that multiple mounts should be different devices; we can then hotplug mountpoints). We may run out of PCI slots though :-/ Then we can start selling virtio extension chassis. :-) Do you know if there is a hard limit on the number of devices on a PCI bus? My concern was that it was limited by something stupid like an 8-bit identifier. IIRC pci slots are 8-bit, but you can have multiple buses, so effectively 16 bits of device address space (discounting functions which are likely not hot-pluggable). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Carsten Otte wrote: Avi Kivity wrote: No, definitely not define a hypercall ABI. The feature bit should say this device understands a hypervisor-specific way of kicking. consult your hypervisor manual and cpuid bits for further details. should you not be satisfied with this method, port io is still available. ...unless you're lucky enough to be on s390 where pio is not available. I don't see why we'd have two different ways to talk to a virtio device. I think we should use a hypercall for interrupt injection, without support for grumpy old soldered pci features other than HPA-style Lguest PCI bus organization. There are no devices that we want to be backward compatible with. pio is useful for qemu, for example, and as a fallback against changing hypervisor calling conventions. As Anthony points out, it makes a qemu-implemented device instantly available to Xen at no extra charge. My wording was inappropriate for s390, though. The politically correct version reads this device understands a hypervisor-specific way of kicking. consult your hypervisor manual and platform-specific way of querying hypervisor information for further details. should you not be satisfied with this method, the standard method of kicking virtio devices on your platform is still available. On s390, I imagine that the standard method is the fabled diag instruction (which, with the proper arguments, will cook your steak to the exact shade of medium-rare you desire). So you will never need to set the hypervisor-specific way of kicking bit, as your standard method is already optimal. Unfortunately, we have to care for platform differences, subarch differences (vmx/svm), hypervisor differences (with virtio), and guest differences (Linux/Windows/pvLinux, 32/64). Much care is needed when designing the ABI here. [actually thinking a bit, this is specific to the virtio pci binding; s390 will never see any of it] -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Add ifdef in irqchip struct for x86 only structures
Perhaps we could just move the declaration of kvm_irqchip to an arch
specific header instead of introducing #ifdef's?
Does ia64 have a i8259a?
Hi Anthony,
IA64 doesn't need to keep i8259 for platform virtualization, but
we still need ioapic, so I also don't think we can
use #ifdef to solve it.
Xiantao
Regards,
Anthony Liguori
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1196087575 21600
# Node ID ccf9dd8a8e0a4513090d44d52c879fb9dfbb79dd
# Parent 32d8bd91d9441d2a3655593a0aaf99f6c403d70f
Add ifdef in irqchip struct for x86 only structures.
This patch fixes a small issue where sturctures:
kvm_pic_state
kvm_ioapic_state
are defined inside x86 specific code and may or may not
be defined in anyway for other architectures. The problem
caused is one cannot compile userspace apps (ex. libkvm)
for other archs since a size cannot be determined for these
structures.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -51,8 +51,10 @@ struct kvm_irqchip {
__u32 pad;
union {
char dummy[512]; /* reserving space */
+#if defined(__i386__) || defined(__x86_64__)
struct kvm_pic_state pic;
struct kvm_ioapic_state ioapic;
+#endif
} chip;
};
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/6] virtio block driver for QEMU (v2)
Rusty Russell wrote: On Tuesday 13 November 2007 10:25:54 Anthony Liguori wrote: Dor Laor wrote: Anthony Liguori wrote: Dor Laor wrote: In general I think we need to add another feature or even version number ( I know you guys hate it). The reason is - Let's say you dont change functionality but change the irq protocol (for example the isr won't be zeroed on read), then an old guest driver wouldn't know it runs on a new host version and will have its irq line pulled up. So I suggest adding a capability of VIRTIO_ISR_CLEAR_XXX or adding a version number. Comments? I don't think we'll actually change the ISR protocol. I think it's the best that it can actually be. However, if we do need to change the ABI for some reason, I think the right thing to do is just use a new device ID (since it's effectively a new device). Regards, Anthony Liguori Changing the devid is acceptable and much more easier then backward compatibility support, I prefer it too. Note that there are some disadvantages when changing the devid - For example, if you installed an old device drivers in the guest kernel and after a while you bring the guest down, upgrade the kvm host version and bring the guest back up. If it has a new device id (and since the abi is not maintained the driver won't match VENDOR=virtio; DEVID=*), then the guest won't have a driver for the new device. In that case I think a guest agent can switch to fully virtualized device and afterwards install the driver automatically. This is what we do in our production environment. Hrm, I have to think about backwards compatibility at the virtio-pci layer. virtio-pci basically exposes two things, the first is an ABI for doing bidirectional notification and setting driver status. The second is a standard and transparent mechanism for virt_rings. I think that the first is simply enough that we don't need a feature mask or a version number. Maybe perhaps with the status bits, I don't know. For the virt_rings, if we had something more sophisticated than virt_rings down the road, that can be discovered/configured in the per-device configuration area so I don't think we need feature/version info for that. I originally had feature bits on each virtqueue for just such a reason. Used the same ack logic as the normal feature bits (ie. set corresponding bit to indicate guest wants to use the feature). Probably worth engineering this in now. I don't think a per-queue feature bit is worthwhile. What we need is feature bits for the ABI. I'd start with one feature bit for the base device ABI. We can add further bits if we add new descriptor types, new queues, or newer config features The feature bits would be explicitly named and documented, instead of I have a third virtqueue so I can use this new ABI. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Avi Kivity wrote: Unfortunately, we have to care for platform differences, subarch differences (vmx/svm), hypervisor differences (with virtio), and guest differences (Linux/Windows/pvLinux, 32/64). Much care is needed when designing the ABI here. Yea, I agree. [actually thinking a bit, this is specific to the virtio pci binding; s390 will never see any of it] You remember that we've lost the big debate around virtio in Tucson? We intend to bind our virtio devices to PCI too, so that they look the same in Linux userland across architectures. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Carsten Otte wrote: [actually thinking a bit, this is specific to the virtio pci binding; s390 will never see any of it] You remember that we've lost the big debate around virtio in Tucson? I was in the embedded BOF. We intend to bind our virtio devices to PCI too, so that they look the same in Linux userland across architectures. Ouch. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Avi Kivity wrote: We intend to bind our virtio devices to PCI too, so that they look the same in Linux userland across architectures. Ouch. That was my initial opinion too, but HPA has come up with a lean and clean PCI binding for lguest. I think we should seriously consider using that over the current qemu device emulation based thing. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ANNOUNCE] kvm-54 release
Minor improvements all around. Changes from kvm-53: - fix fpu leak on AMD (Amit Shah) - (on kvm-53, lazy fpu was disabled, so this just improves performance) - prefetch instruction bytes when emulating - implement guest page fault bypass on nonpae - should speed up some 32-bit guests - add a bunch of statistics - avoid unnecessary remote tlb flushes - improves guest smp scaling - avoid mmu reloads on guest tlb flushes - mmu code simplification - disallow using kvm after fork() - fix failures while injecting external interrupts in real mode - fixes Mandrake 9 regression - fix multiple address- and operand- size override prefix emulation - infrastructure for using host cpu features on guest (Dan Kenigsberg) - not used yet by qemu - cmps instruction emulation (Guillaume Thouvenin) - allows OpenBSD to bood - cleanups (Hollis Blanchard) - fix potential memory leak in real-mode smp (Izik Eidus) - reduce unnecessary dirtying of pages (Izik Eidus) - mark guest pages as accessed with the Linux lru (Izik Eidus) - more portability work (Jerone Young, Xiantao Zhang) - allow new vmx features even if not using in-kernel apic (Sheng Yang) - refactor shadow mmu size calculation (Xiantao Zhang) - improve testsuite - beginning of x86 emulator unit test - fix compile warnings (Carlo Marcelo Arenas Belon) - log module version in dmesg on load Notes: If you use the modules bundled with kvm-54, you can use any version of Linux from 2.6.9 upwards. If you use the modules bundled with Linux 2.6.20, you need to use kvm-12. If you use the modules bundled with Linux 2.6.21, you need to use kvm-17. Modules from Linux 2.6.22 and up will work with any kvm version from kvm-22. Some features may only be available in newer releases. For best performance, use Linux 2.6.23-rc2 or later as the host. http://kvm.qumranet.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] cross compiling kvm
Hi Jerone, On Monday 26 November 2007, Jerone Young wrote: On Mon, 2007-11-26 at 11:57 +0100, Gerd Koenig wrote: hello, Which is the first version of kvm, which is considered to be able to cross compile? It would be one of the newer versions. I started to sending cross compile stuff probably around kvm-47 timeframe (I barely remember). Definitely not kvm-28 though. thanks for the info! So I will continue to work with kvm-53. The thing is, that some people say, that it is necessary to use a patched version of KVM by using it with the realtime preemption patches. But this is an issue I will investigate after a successful installation of kvm on our target. Of course, it can be possible, that I do something totally wrong. This is my configure call: ./configure --arch=i386 --cross-prefix=/opt/crosstool/i686-pentium-linux-gnu/\ gcc-3.4.3-glibc-2.3.3/bin/i686-pentium-linux-gnu- \ --kerneldir=/home/gerdko/thinkiod_work/linux --disable-vnc-tls \ --prefix=/home/gerdko/thinkiod_work/install you might ask, why I use a cross compiler for x86? Well, I want to use kvm on an embedded device, which doesn't have local gcc installed, so I need to compile everything on another host. I have found that your going to want to add --with-patched-kernel to your command line also. Why is this so? I understood, if I want to compile the kvm package, including the kernel modules, I don't have to use the --with-patched-kernel. Am I wrong? I'm a bit puzzled at the moment, as it seems, that the --with-patched-kernel switch is incompatible with --kerneldir ?? kerneldir is a path to my patched 2.6.21.6-rt21 preemptible-kernel for our target, by the way. To solve your SDL issue you probably want to cross compile a version SDL in a directory .. then add to the --qemu-cflags option --qemu-ldflags. Same whould go for stuff like ZLib. yes, I did so. And it seems to work. But there is still a problem with the configure script, as it assumes to search for sdl-config on the development host. A minor problem though and easy to fix... I could send a patch afterwards, when I found a common solution... ./configure --arch=i386 --cross-prefix=/opt/crosstool/i686-pentium-linux-gnu/\ gcc-3.4.3-glibc-2.3.3/bin/i686-pentium-linux-gnu- \ --kerneldir=/home/gerdko/thinkiod_work/linux --disable-vnc-tls \ --prefix=/home/gerdko/thinkiod_work/install \ --with-patched-kernel \ --qemu-cflags=--static -I SDL_DIR/include -I zlib_dir/lib \ --qemu-ldflags=-L SDL_DIR/lib -L zlib_dir/include Another thing that you need to sneak in is that your going to need is adding --static flag into the qemu compilation (which I do in --qemu-cflags in the example). Cross compiling qemu is a little bit of a pain.due to the external dependencies. But it is possible. phew. yes it is ;-) Hope that helps. thank you! greetings, gerd Kontron Modular Computers GmbH Geschaeftsfuehrer / Managing Directors: Ulrich Gehrmann, Thomas Sabisch Sitz der Gesellschaft / Registered Office: Kaufbeuren, Rechtsform / Legal: GmbH Amtsgericht / Local District Court Kempten, HRB Nr. / Trade Register No. 6195 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 5/6] Remove hypercall driver (v2)
Anthony Liguori wrote: I don't think there's any plans for this driver to every be used seriously as virtio seems like the agreed upon layer. So let's remove the code from the tree so I can use the drivers/ directory for something else. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 6/6] Provide a mechanism to build virtio drivers as modules (v2)
Anthony Liguori wrote: This provides a make sync within the drivers/ directory to allow virtio drivers to be built as third-party modules much as we do with the KVM driver. We will want to ship and build guest drivers as a separate package (that's not to say that this patch is wrong; but the drivers package will need its own configure/make/install thing). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] AltGR-Key in QEmu-VNC
When using VNC Server build into qemu the AltGr-Key seems to be ignored. The alternative Ctrl-Alt seems to work but it is less comfortable to press three keys. Any idea how to fix it? Elmar - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Carsten Otte wrote: Avi Kivity wrote: We intend to bind our virtio devices to PCI too, so that they look the same in Linux userland across architectures. Ouch. That was my initial opinion too, but HPA has come up with a lean and clean PCI binding for lguest. I think we should seriously consider using that over the current qemu device emulation based thing. There are two solutions for this problem: 1. Use hypercalls and supply mechanism for hypercall patching for qemu. This way we can make s390 qemu/xen happy. 2. Have two transport mechanism for virtio. Actually this is what we have today (but not yet merged) - lguest uses the pci config space but without using Anthony's pci module. We'll have virtio host i(qemu/kernel) implementation for the shared memory and interface. We'll have pci transport for x86 that glues the above and a virtual transport for s390 and paravirt_ops. Both transports will be based on Rusty's config space. This is the idea I suggested in Tuscon: - - | 9p | | network | | block | -- - | virtio interface| --- -- | virtio_pci| OR | virtio_vbus (includes configs hypercall/portio) | --- -- --- - | virtio_ring||virtio_config| --- - Regards, Dor - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..
Zhao, Yunfeng wrote: https://sourceforge.net/tracker/?funcÞtailatid‰3831aid36905group_id05 99 Internal testing here confirms, but this is not a recent regression. When was the last time Vista x64 installed reliably for you? (here, it works, but not 100% of the time). [Yunfeng] Yes, it may not be a recent regression, and it may be a platform related issue. Before we used Harwitch /paxville to do the test, and in a period the installation test could pass without any problem. But after we switched the test machine to Dempsey/Woodcrest, the installation test always fails. Thanks, that's an interesting data point. We'll look further into this. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [GIT PULL] KVM fixes for Linux 2.6.24-rc3
Linus,
Please pull the the kvm updates in
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus
fixing some x86 emulator and AMD FPU handling regressions.
Amit Shah (2):
KVM: x86 emulator: Use emulator_write_emulated and not emulator_write_std
KVM: SVM: Fix FPU leak while emulating clts
Avi Kivity (1):
KVM: SVM: Unload guest fpu on vcpu_put()
Izik Eidus (2):
KVM: x86 emulator: fix JMP_REL
KVM: x86 emulator: fix the saving of of the eip value
drivers/kvm/kvm_main.c|3 +--
drivers/kvm/svm.c |1 +
drivers/kvm/x86_emulate.c |6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 07ae280..47c10b8 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1188,8 +1188,7 @@ int emulate_invlpg(struct kvm_vcpu *vcpu, gva_t address)
int emulate_clts(struct kvm_vcpu *vcpu)
{
- vcpu-cr0 = ~X86_CR0_TS;
- kvm_x86_ops-set_cr0(vcpu, vcpu-cr0);
+ kvm_x86_ops-set_cr0(vcpu, vcpu-cr0 ~X86_CR0_TS);
return X86EMUL_CONTINUE;
}
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 7a6eead..4e04e49 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -663,6 +663,7 @@ static void svm_vcpu_put(struct kvm_vcpu *vcpu)
wrmsrl(host_save_user_msrs[i], svm-host_user_msrs[i]);
rdtscll(vcpu-host_tsc);
+ kvm_put_guest_fpu(vcpu);
}
static void svm_vcpu_decache(struct kvm_vcpu *vcpu)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 33b1814..bd46de6 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -448,8 +448,7 @@ struct operand {
#define JMP_REL(rel) \
do {\
- _eip += (int)(rel); \
- _eip = ((op_bytes == 2) ? (uint16_t)_eip : (uint32_t)_eip); \
+ register_address_increment(_eip, rel); \
} while (0)
/*
@@ -1147,7 +1146,7 @@ done_prefixes:
}
register_address_increment(_regs[VCPU_REGS_RSP],
-dst.bytes);
- if ((rc = ops-write_std(
+ if ((rc = ops-write_emulated(
register_address(ctxt-ss_base,
_regs[VCPU_REGS_RSP]),
dst.val, dst.bytes, ctxt-vcpu)) != 0)
@@ -1359,6 +1358,7 @@ special_insn:
}
src.val = (unsigned long) _eip;
JMP_REL(rel);
+ op_bytes = ad_bytes;
goto push;
}
case 0xe9: /* jmp rel */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..
One regression: 1. Cannot install 64bit vista guests. https://sourceforge.net/tracker/?funcÞtailatid3831aid36905group_id05 99 Internal testing here confirms, but this is not a recent regression. When was the last time Vista x64 installed reliably for you? (here, it works, but not 100% of the time). [Yunfeng] Yes, it may not be a recent regression, and it may be a platform related issue. Before we used Harwitch /paxville to do the test, and in a period the installation test could pass without any problem. But after we switched the test machine to Dempsey/Woodcrest, the installation test always fails. 6 Some ltp cases fail on KVM guests https://sourceforge.net/tracker/index.php?funcÞtailaid41316group_id059 9atid3831 I checked this, and it seems invalid. Please see the notes I made in the bug tracker. [Yunfeng] I have retested it. These test cases should be able to pass on KVM. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] OpenSolaris 09/2007 (Sun Solaris Express)
magicboiz wrote: Well done Carlo. The patch works perfectly with my OpenSolaris and kvm-53. Good to know. Thx! El lun, 26-11-2007 a las 19:31 -0600, Carlo Marcelo Arenas Belon escribió: On Wed, Oct 10, 2007 at 03:53:10PM +0200, magicboiz wrote: Sun Solaris Express(9/07), does not detect the hard disk..I attach an screenshot. from the screenshot it seems that the problem is not with the hard disk but with the cdrom. attached patch to qemu (not yet committed upstream) fixed that problem for me. Has it been submitted? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] OpenSolaris 09/2007 (Sun Solaris Express)
On Tue, Nov 27, 2007 at 10:22:57PM +0200, Avi Kivity wrote: magicboiz wrote: Well done Carlo. The patch works perfectly with my OpenSolaris and kvm-53. Good to know. Also tested it with Nexenta alpha 7, and Indiana and had it added as part of my gentoo package for kvm-54 attached patch to qemu (not yet committed upstream) fixed that problem for me. Has it been submitted? yes, as can be seen in : http://lists.gnu.org/archive/html/qemu-devel/2007-11/msg00758.html no response yet, but I'll try a RESEND tomorrow Carlo - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Problem with vde/dnsmasq on CentOS 5.0
Hi, Apologies for this not being a specific KVM issue. I cannot get vde/dnsmasq working with KVM on CentOS 5.0. It works fine on FC6 basically following the instructions here https://help.ubuntu.com/community/KVM. However, when I move to CentOS 5, I constantly get the Sendto: bad file descriptor error when I try to run with a vde tap interface. The error happens when the guest tries to setup networking. Has anyone had success with vde/dnsmasq on CentOS or another RHEL clone? Is there an alternative tap-based approach other than vde? Any help or pointers are appreciated. Thanks, Cam - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] real mode emulation and memory consumption
Hi Avi, I am noticing that with SL 10.1 The QEMU process memory consumption steadily increases, up the the guest memory size and then the guest dies with unhandled vmexit. If I change the guest memory size I can see the qemu process dies accordingly, after reaching the size of allotted guest memory. Does this hint you to any issues? Thanks Regards, Nitin Linux Open Source Technology Center, Intel Corporation - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] real mode emulation and memory consumption
-Original Message- From: Kamble, Nitin A Sent: Tuesday, November 27, 2007 5:05 PM To: 'Avi Kivity' Cc: kvm-devel Subject: real mode emulation and memory consumption Hi Avi, I am noticing that with SL 10.1 The QEMU process memory consumption steadily increases, up the the guest memory size and then the guest dies with unhandled vmexit. If I change the guest memory size I can see the qemu process dies accordingly, after reaching the size of allotted guest memory. Does this hint you to any issues? BTW this is the behavior with master branch without any changes. Thanks Regards, Nitin Linux Open Source Technology Center, Intel Corporation --- - - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Should we move kvm_vcpu_ioctl_interrupt to arch?
Hi, Avi Since IA64's irqchip is always in kernel side, so we don't need kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to arch? Otherwise, we have to define two unnecessary fields(irq_summary and irq_pending) for vcpu structure for compile pass. Xiantao - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
