Re: [kvm-devel] Any plans to rebase kvm to current qemu at the moment ?
Christian Ehrhardt wrote: Hi, while working on the embedded powerpc port for kvm we have a lot of dependencies on current qemu 0.9.0 code for ppc support. Internally we currently run with a modified qemu, but eventually strive for integration with kvm-userspace. Therefor I wanted to ask if there are already detailed plans (if any) regarding the re-base of kvm-userspace to the new qemu source? I'm currently debating this. On the one hand, upstream qemu has a lot of fixes and new goodies. On the other hand, we still haven't recovered completely from the lapic merge and I don't want to rock the boat further. I'll try to merge in the next few days and see what breaks. -- 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] Any plans to rebase kvm to current qemu at the moment ?
Hi Avi, We also the similar problems, when we enable kvm/ipf. You know, Qemu doesn't work on IPF both at host and guest sides. So, we have some changes, and new-added stuffs to current Qemu code. Do you think which tree we should push them to? Qemu upstream or kvm-userspace? Thanks Xiantao Avi Kivity wrote: Christian Ehrhardt wrote: Hi, while working on the embedded powerpc port for kvm we have a lot of dependencies on current qemu 0.9.0 code for ppc support. Internally we currently run with a modified qemu, but eventually strive for integration with kvm-userspace. Therefor I wanted to ask if there are already detailed plans (if any) regarding the re-base of kvm-userspace to the new qemu source? I'm currently debating this. On the one hand, upstream qemu has a lot of fixes and new goodies. On the other hand, we still haven't recovered completely from the lapic merge and I don't want to rock the boat further. I'll try to merge in the next few days and see what breaks. - 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] Any plans to rebase kvm to current qemu at the moment ?
Zhang, Xiantao wrote: Hi Avi, We also the similar problems, when we enable kvm/ipf. You know, Qemu doesn't work on IPF both at host and guest sides. So, we have some changes, and new-added stuffs to current Qemu code. Do you think which tree we should push them to? Qemu upstream or kvm-userspace? qemu-upstream is best for changes that would benefit regular qemu. Changes that are only good for kvm should be in kvm-userspace. -- 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] Unable to handle kernel paging request
Avi Kivity wrote: Laurent Vivier wrote: (Yes, I know, it's again another bug I've introduced into KVM...) To avoid this, I suggest that Nitin and yourself review each other's patches. While I review every patch I commit, it works much better when someone who's involved daily with the code reviews the patch. I agree... Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - 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] Correct management of REP prefix
Avi Kivity wrote: Laurent Vivier wrote: This patch corrects some errors appearing when we have an emulation failure on an operation using REP prefix. When x86_emulate_insn() fails, saving EIP and ECX is not enough as emulation should have modified other registers like RSI or RDI. Moreover, the emulation can fail on the writeback, and in this case we are not able to restore registers. This patch takes another approach: at the beginning of x86_emulate_insn() we restore state we have at end of x86_decode_insn(). To do that, we store EIP in a new field in decode_cache, decode_eip. This field store the EIP as it is at the end of x86_decode_insn(); and at beginning of x86_emulate_insn(), we restore all registers as they are in vcpu. We can do that, because the x86_decode_insn() doesn't modify registers (except EIP). How about doing it slightly differently: keep c-eip at its current meaning, and add c-eip_orig to revert to? That will make the patch smaller and reduce the changes of something being missed. I didn't do like that because I was afraid to miss some points to restore orig_eip. But a patch will follow... Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - 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] [ kvm-Bugs-1805519 ] cannot add usbdevice
Bugs item #1805519, was opened at 2007-10-01 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1805519group_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: Jack.Gmi (jack.gmi) Assigned to: Nobody/Anonymous (nobody) Summary: cannot add usbdevice Initial Comment: cpu: intel-T7200 host: gentoo-2.6.22-32bit + kvm-44 guest: WinXP-Pro I can't add a usbdevice, it's a 3g modem, i think the problem is because it cointain more device. On WinVista-Business first it's view as cdrom and then it change as composite usb device. If you need more information i will give you asap. Thx Jack -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=1805519group_id=180599 - 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 behaves weird on AMD64
Tobias Brink escribió: Avi Kivity [EMAIL PROTECTED] writes: Tobias Brink wrote: I have a probably similar problem with OpenBSD 4.1 and kvm-37 and kvm-39 (didn't have time to test any further versions). Kernel is 2.6.22-gentoo-r5 and processor is Intel Core2 Quad. I use the modules from the unpatched (Gentoo) kernel. I installed OpenBSD with vanilla qemu and it works perfectly but as soon as I use kvm the OpenBSD kernel panics on boot with root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 panic: root filesystem has size 0 and then enters the debugger. With -no-kvm it works as flawlessly as in vanilla qemu. I don't have much time at the moment but I'll try to find a working kvm version. If you need further information I'll see if I can provide it as I'd really like to see OpenBSD working with kvm. I think this is fixed in the latest release. It is. Thank you very much. I'm now running OpenBSD 4.1 on kvm-43 without issues. Greetings, Tobias - 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 It also solves my installation problem. Now OpenBSD 4.1 on kvm-44 is running perfect. Thank you very much for your help. Regards, Miguel - 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] Ubuntu's gfxboot doesn't get on well with KVM
Hello all, After solving my problems installing OpenBSD 4.1 in KVM, I tried to install Ubuntu 7.04 Feisty Fawn. The problem is that it gets stuck in a black screen without having said anything at all. After some testing with other isos I thought it could be related to the graphical bootloader (gfxboot). So I regenerated an Ubuntu iso with gfxboot manually disabled. The result is that this way it enables frame buffer correctly and starts installation. I read there were some problems with this in former kvm versions (and you had to test it with miniso) but I thought it was already fixed it and I'm using kvm-44. Thanks a lot in advanced for your help. Regards Miguel - 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] can't boot just: serial0 console
hi, after i try to merge centos and fedora kvm-36 spec files and patches (ethernet qemu fix etc) and start the guests on the new kvm host the guest install. the only thing what i got in qemu vnc window: serial0 console so the guest not even start to boot. anybody has any tip? may be the bios update? or? -- Levente Si vis pacem para bellum! - 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] Ubuntu's gfxboot doesn't get on well with KVM
Miguel Araujo wrote: Hello all, After solving my problems installing OpenBSD 4.1 in KVM, I tried to install Ubuntu 7.04 Feisty Fawn. The problem is that it gets stuck in a black screen without having said anything at all. After some testing with other isos I thought it could be related to the graphical bootloader (gfxboot). So I regenerated an Ubuntu iso with gfxboot manually disabled. The result is that this way it enables frame buffer correctly and starts installation. I read there were some problems with this in former kvm versions (and you had to test it with miniso) but I thought it was already fixed it and I'm using kvm-44. https://bugs.launchpad.net/ubuntu/+source/gfxboot/+bug/140713 Regards, Anthony Liguori Thanks a lot in advanced for your help. Regards Miguel - 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
[kvm-devel] [PATCH] Allow for Cross compile of user tools
This is the first of many patches to begin to make kvm source a lot better for compiling for other architecture support (that is not x86 or x86-64). This patch makes it possible so that someone on an x86 machine can cross compile for an x86-64 machine and vice versa. So now you will have config-$(arch).mak for each architecture, with specific architecture rules. An example of this is for compiling x86-64 on an x86 machine is: make KERNELDIR=~/tmp/kvm ARCH=x86_64 This allows for someone with an x86 machine to compile for x86_64. Later patches that I will be submitting will be for ppc and will make a few more changes. What I would like though is comments on how everyone feels about this approach. We are need of something like this to start ading ppc related code. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/user/Makefile b/user/Makefile index 26eb530..aebba58 100644 --- a/user/Makefile +++ b/user/Makefile @@ -1,5 +1,12 @@ -include config.mak +ARCH ?= $(shell uname -m | sed -e s/i.86/x86/) + +KERNELDIR ?= /lib/modules/$(shell uname -r)/build/ + +DESTDIR ?= + +#include architecure specific make rules +include config-$(ARCH).mak # cc-option # Usage: OP_CFLAGS+=$(call cc-option, -falign-functions=0, -malign-functions=0) @@ -7,8 +14,8 @@ include config.mak cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null \ /dev/null 21; then echo $(1); else echo $(2); fi ;) -CFLAGS = -I $(KERNELDIR)/include $(autodepend-flags) -g -fomit-frame-pointer \ - -Wall -m$(bits) +CFLAGS += -I $(KERNELDIR)/include $(autodepend-flags) -g -fomit-frame-pointer \ + -Wall CFLAGS += $(call cc-option, -fno-stack-protector, ) CFLAGS += $(call cc-option, -fno-stack-protector-all, ) @@ -18,20 +25,6 @@ CXXFLAGS = $(autodepend-flags) autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d -DESTDIR = - -ifeq ($(shell uname -m), x86_64) -LIBDIR = /lib64 -cstart.o = test/cstart64.o -bits = 64 -ldarch = elf64-x86-64 -else -LIBDIR = /lib -cstart.o = test/cstart.o -bits = 32 -ldarch = elf32-i386 -endif - all: kvmctl libkvm.a flatfiles kvmctl: LDFLAGS += -pthread -lrt @@ -45,11 +38,7 @@ libkvm.a: kvmctl.o flatfiles-common = test/bootstrap test/vmexit.flat test/smp.flat -flatfiles-32 = - -flatfiles-64 = test/access.flat test/irq.flat test/sieve.flat test/simple.flat test/stringio.flat test/memtest1.flat - -flatfiles: $(flatfiles-common) $(flatfiles-$(bits)) +flatfiles: $(flatfiles-common) $(flatfiles) install: install -D kvmctl.h $(DESTDIR)/$(PREFIX)/include/kvmctl.h @@ -60,13 +49,13 @@ install: install -D libkvm.a $(DESTDIR)/$(PREFIX)/$(LIBDIR)/libkvm.a %.flat: %.o - gcc $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $^ + $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $^ test/bootstrap: test/bootstrap.o - gcc -nostdlib -o $@ -Wl,-T,bootstrap.lds $^ + $(CC) -nostdlib -o $@ -Wl,-T,bootstrap.lds $^ %.o: %.S - gcc $(CFLAGS) -c -nostdlib -o $@ $^ + $(CC) $(CFLAGS) -c -nostdlib -o $@ $^ test/irq.flat: test/print.o diff --git a/user/config-x86.mak b/user/config-x86.mak new file mode 100644 index 000..d2d181b --- /dev/null +++ b/user/config-x86.mak @@ -0,0 +1,7 @@ +LIBDIR = /lib +cstart.o = test/cstart.o +bits = 32 +ldarch = elf32-i386 +CFLAGS += -m32 + +flatfiles= diff --git a/user/config-x86_64.mak b/user/config-x86_64.mak new file mode 100644 index 000..19ebc46 --- /dev/null +++ b/user/config-x86_64.mak @@ -0,0 +1,7 @@ +LIBDIR = /lib64 +cstart.o = test/cstart64.o +bits = 64 +ldarch = elf64-x86-64 +CFLAGS += -m64 + +flatfiles = test/access.flat test/irq.flat test/sieve.flat test/simple.flat test/stringio.flat test/memtest1.flat - 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] What happens on an INT80 instruction
Anthony Liguori wrote: Cameron Macdonell wrote: Hi, I'm trying to understand guest virtualization at the lower levels. I have a somewhat basic question: How does KVM virtualize an int80 instruction from a guest? A pointer to an answer is just as good as an answer itself. The same thing happens as it does on normal hardware. The way VT/SVM works (at a high level), is that certain instructions and events check a special area called the VMCS/VMCB to determine whether the event should generate a vmexit which is really just a special type of trap. Thanks Anthony. Does an int80 from an application in the guest always cause a vmexit (in kvm's case at least)? Thanks, Cam There are no hooks for interrupts 32-255 so the hardware operates as it normally would. If you're interested in getting a trap for int80 within KVM, you'll have to trap sidt/lidt and virtualize the IDT. You'll need to setup a fake IDT and have the int80 handler do a hypercall. This is complicated if the guest is using a fast-syscall mechanism. It may be a little challenging finding a piece of guest memory to take over that has a valid virtual mapping. To solve this in the general case, you'll need to have the guest be aware of a memory hole. If you can limit yourself to things like Linux and Windows, you can probably just rely on some memory within the BIOS area (both Linux and Windows always have valid mappings of the BIOS memory). If you need to enforce that int80s go to you, you'll need to write-protect this memory too. Regards, Anthony Liguori Thanks, Cam - 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] What happens on an INT80 instruction
Cam Macdonell wrote: Anthony Liguori wrote: Cameron Macdonell wrote: Hi, I'm trying to understand guest virtualization at the lower levels. I have a somewhat basic question: How does KVM virtualize an int80 instruction from a guest? A pointer to an answer is just as good as an answer itself. The same thing happens as it does on normal hardware. The way VT/SVM works (at a high level), is that certain instructions and events check a special area called the VMCS/VMCB to determine whether the event should generate a vmexit which is really just a special type of trap. Thanks Anthony. Does an int80 from an application in the guest always cause a vmexit (in kvm's case at least)? No, an int80 would never generate a trap in KVM. The only way to make it generate a trap is for an int80 to trigger some other event that would generate a trap. This is what I meant by taking over the guest's IDT such that you could change the int80 handler to do a hypercall. I presume you're looking into doing a guest IDS right? Regards, Anthony Liguori Thanks, Cam There are no hooks for interrupts 32-255 so the hardware operates as it normally would. If you're interested in getting a trap for int80 within KVM, you'll have to trap sidt/lidt and virtualize the IDT. You'll need to setup a fake IDT and have the int80 handler do a hypercall. This is complicated if the guest is using a fast-syscall mechanism. It may be a little challenging finding a piece of guest memory to take over that has a valid virtual mapping. To solve this in the general case, you'll need to have the guest be aware of a memory hole. If you can limit yourself to things like Linux and Windows, you can probably just rely on some memory within the BIOS area (both Linux and Windows always have valid mappings of the BIOS memory). If you need to enforce that int80s go to you, you'll need to write-protect this memory too. Regards, Anthony Liguori Thanks, Cam - 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] What happens on an INT80 instruction
Anthony Liguori wrote: Cam Macdonell wrote: Anthony Liguori wrote: Cameron Macdonell wrote: Hi, I'm trying to understand guest virtualization at the lower levels. I have a somewhat basic question: How does KVM virtualize an int80 instruction from a guest? A pointer to an answer is just as good as an answer itself. The same thing happens as it does on normal hardware. The way VT/SVM works (at a high level), is that certain instructions and events check a special area called the VMCS/VMCB to determine whether the event should generate a vmexit which is really just a special type of trap. Thanks Anthony. Does an int80 from an application in the guest always cause a vmexit (in kvm's case at least)? No, an int80 would never generate a trap in KVM. The only way to make it generate a trap is for an int80 to trigger some other event that would generate a trap. This is what I meant by taking over the guest's IDT such that you could change the int80 handler to do a hypercall. I presume you're looking into doing a guest IDS right? Actually, I looking into doing a PhD dissertation :) I'm just trying to get a better working understanding of how kvm (and other VMMs) handle instructions like int80 that should trap into the OS, but of course in a VM need to trap into the guest OS (which is running at user-level) and not the host OS. Do traps by a guest app to the guest OS involve the VMM at all? Pardon my ignorance, what is IDS? Thanks, Cam - 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] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Sun, 30 Sep 2007 15:56:16 +0200, Avi Kivity wrote: Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. What is the spanning directories issue? Can't I build arch/powerpc/kvm/kvm-powerpc.ko and drivers/kvm/kvm.ko and let modprobe sort out the dependency? -- Hollis Blanchard IBM Linux Technology Center - 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] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Tue, 2007-10-02 at 01:19 +, Hollis Blanchard wrote: On Sun, 30 Sep 2007 15:56:16 +0200, Avi Kivity wrote: Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. What is the spanning directories issue? Can't I build arch/powerpc/kvm/kvm-powerpc.ko and drivers/kvm/kvm.ko and let modprobe sort out the dependency? Sure, but it creates a silly module. I think guest code belongs in arch/*/kvm/, but host code can be done as subdirs under drivers/kvm/. Cheers, Rusty. - 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] [PATCH] kvm-userspace: fix kzalloc macro
This was committed in 1d55c096cce99f069d9ac8e3b2195d45adce9549 on Feb 7,
and clearly never actually compiled.
---
kernel/external-module-compat.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/external-module-compat.h b/kernel/external-module-compat.h
index 2e1a9f1..8e62efb 100644
--- a/kernel/external-module-compat.h
+++ b/kernel/external-module-compat.h
@@ -126,9 +126,9 @@ static inline int smp_call_function_single2(int cpu, void
(*func)(void *info),
#define kzalloc(size,flags)\
({ \
void *__ret = kmalloc(size, flags); \
- if (__ret)
- memset(__ret, 0, size);
- __ret;
+ if (__ret) \
+ memset(__ret, 0, size); \
+ __ret; \
})
#endif
#endif
--
1.5.1.3
-
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] Allow for Cross compile of user tools
Jerone Young wrote: This is the first of many patches to begin to make kvm source a lot better for compiling for other architecture support (that is not x86 or x86-64). This patch makes it possible so that someone on an x86 machine can cross compile for an x86-64 machine and vice versa. So now you will have config-$(arch).mak for each architecture, with specific architecture rules. An example of this is for compiling x86-64 on an x86 machine is: make KERNELDIR=~/tmp/kvm ARCH=x86_64 This should be done via ./configure (I dislike ?= intensely). This allows for someone with an x86 machine to compile for x86_64. Later patches that I will be submitting will be for ppc and will make a few more changes. What I would like though is comments on how everyone feels about this approach. We are need of something like this to start ading ppc related code. No problem for user/. I'd like to see this accepted by qemu-devel as well. -- Any sufficiently difficult bug is indistinguishable from a feature. - 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
