Re: [PATCH 19/27] Export symbols for KVM module
Am 31.10.2009 um 05:37 schrieb Stephen Rothwell s...@canb.auug.org.au: Hi Alexander, On Fri, 30 Oct 2009 16:47:19 +0100 Alexander Graf ag...@suse.de wrote: diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ ppc_ksyms.c index c8b27bb..baf778c 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -163,11 +163,12 @@ EXPORT_SYMBOL(screen_info); #ifdef CONFIG_PPC32 EXPORT_SYMBOL(timer_interrupt); EXPORT_SYMBOL(irq_desc); -EXPORT_SYMBOL(tb_ticks_per_jiffy); EXPORT_SYMBOL(cacheable_memcpy); EXPORT_SYMBOL(cacheable_memzero); #endif +EXPORT_SYMBOL(tb_ticks_per_jiffy); Since you are moving this anyway, how about moving it into arch/powerpc/kernel/time.c where tb_ticks_per_jiffy is defined. Well the fun part is that the hrtimer conversion patch actually deprecates this change. I merely forgot to change the export back. So I suppose I'll leave things here as is and then revert this chunk in the hrtimer patch. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP blue screen with qemu-kvm-0.11.0
Ross Boylan wrote: My XP VM was working OK, and then started crashing shortly after it logged me in. There were no obvious changes at the time. I built the latest qemu-kvm, but the problem persists. I am running 32 bit XP on Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (8 cores total), Debian GNU/Linux mostly Lenny (amd64), but with some more recent stuff. In particular, the kernel is 2.6.30-8 and I pulled in the kernel-headers package to match before building kvm. However, libc6 and libc6-dev are at Lenny's 2.7-18 version. Libc is basically irrelevant here. What matters are the host kernel and kvm version. $ ./XP.sh ++ sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:12:01:00 -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl -boot c -vga std -hda /dev/turtle/XP01 -soundhw es1370 -localtime -m 1G -smp 2 arg ,vlan=1,sock=/var/run/vde2/tap0.ctl TUNGETIFF ioctl() failed: Invalid argument TUNSETOFFLOAD ioctl() failed: Bad address oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: Device or resource busy oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: Device or resource busy audio: Failed to create voice `es1370.dac2' # and more sound-related complaints Switch to alsa to get your audio working. The VM starts; I see the initial XP screen with the 4 colors; I see the background I get when I log in (it logs me in directly without prompt); and then (pretty fast) I get a blue screen. The stop code is 0x8E, and the text says to check disk space and BIOS options. What's the bios files your kvm uses? Are they by a change from some old qemu install? Does kvm deb from http://www.corpit.ru/debian/tls/kvm/ expose the same issue? -no-kvm-irqchip and -no-kvm-pit make no difference. With -no-kvm I get stop code 0x24 and a suggestion to disable anti-virus, defragmentation, and backup software. This is the one obvious change between the Lenny kvm and the one I just built; with lenny kvm (kvm 72+dfsg-5~lenny3) running with -no-kvm simply seemed to hang forever (I think I waited at least 15 minutes). This disk turtle/XP01 is a read-write snapshot on turtle/XP00. The snapshot looks healthy, with about 50% allocated to the snapshot. The snapshot volume is 10G and the original is 50G. The VM starts fine if I point it to XP00 instead of XP01. Well, that's telling, isn't it? If you change disk image and it works, the problem should be in the disk image... P.S. What are the different files in my kvm/bin directory? There's no kvm/bin directory in the source tarball of qemu-kvm-0.11.0. /mjt -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel bug in kvm_intel
On 10/30/2009 08:07 PM, Andrew Theurer wrote: I have finally bisected and isolated this to the following commit: ada3fa15057205b7d3f727bba5cd26b5912e350f http://git.kernel.org/?p=virt/kvm/kvm.git;a=commit;h=ada3fa15057205b7d3f727bba5cd26b5912e350f Merge branch 'for-linus' of git://git./linux/kernel/git/tj/percpu * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: (46 commits) powerpc64: convert to dynamic percpu allocator sparc64: use embedding percpu first chunk allocator percpu: kill lpage first chunk allocator x86,percpu: use embedding for 64bit NUMA and page for 32bit NUMA percpu: update embedding first chunk allocator to handle sparse units percpu: use group information to allocate vmap areas sparsely vmalloc: implement pcpu_get_vm_areas() vmalloc: separate out insert_vmalloc_vm() percpu: add chunk-base_addr percpu: add pcpu_unit_offsets[] percpu: introduce pcpu_alloc_info and pcpu_group_info percpu: move pcpu_lpage_build_unit_map() and pcpul_lpage_dump_cfg() upward percpu: add @align to pcpu_fc_alloc_fn_t percpu: make @dyn_size mandatory for pcpu_setup_first_chunk() percpu: drop @static_size from first chunk allocators percpu: generalize first chunk allocator selection percpu: build first chunk allocators selectively percpu: rename 4k first chunk allocator to page percpu: improve boot messages percpu: fix pcpu_reclaim() locking The previous commit (5579fd7e6aed8860ea0c8e3f11897493153b10ad) does not this problem. FYI, this problem only occurs when oprofile is active. Any idea what in this commit might be the issue? 5579 is not the preceding commit, it is the merged branch: commit ada3fa15057205b7d3f727bba5cd26b5912e350f Merge: 2f82af0 5579fd7 Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Sep 15 09:39:44 2009 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu What happens with 2f82af0? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel bug in kvm_intel
Avi Kivity wrote: On 10/30/2009 08:07 PM, Andrew Theurer wrote: I have finally bisected and isolated this to the following commit: ada3fa15057205b7d3f727bba5cd26b5912e350f http://git.kernel.org/?p=virt/kvm/kvm.git;a=commit;h=ada3fa15057205b7d3f727bba5cd26b5912e350f Merge branch 'for-linus' of git://git./linux/kernel/git/tj/percpu * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: (46 commits) powerpc64: convert to dynamic percpu allocator sparc64: use embedding percpu first chunk allocator percpu: kill lpage first chunk allocator x86,percpu: use embedding for 64bit NUMA and page for 32bit NUMA percpu: update embedding first chunk allocator to handle sparse units percpu: use group information to allocate vmap areas sparsely vmalloc: implement pcpu_get_vm_areas() vmalloc: separate out insert_vmalloc_vm() percpu: add chunk-base_addr percpu: add pcpu_unit_offsets[] percpu: introduce pcpu_alloc_info and pcpu_group_info percpu: move pcpu_lpage_build_unit_map() and pcpul_lpage_dump_cfg() upward percpu: add @align to pcpu_fc_alloc_fn_t percpu: make @dyn_size mandatory for pcpu_setup_first_chunk() percpu: drop @static_size from first chunk allocators percpu: generalize first chunk allocator selection percpu: build first chunk allocators selectively percpu: rename 4k first chunk allocator to page percpu: improve boot messages percpu: fix pcpu_reclaim() locking The previous commit (5579fd7e6aed8860ea0c8e3f11897493153b10ad) does not this problem. FYI, this problem only occurs when oprofile is active. Any idea what in this commit might be the issue? 5579 is not the preceding commit, it is the merged branch: commit ada3fa15057205b7d3f727bba5cd26b5912e350f Merge: 2f82af0 5579fd7 Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Sep 15 09:39:44 2009 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu What happens with 2f82af0? 2f82af0 is: Nicolas Pitre has a new email address Due to problems at cam.org, my n...@cam.org email address is no longer valid. FRom now on, n...@fluxnic.net should be used instead. I have not tested that, but it doesn't seem likely that it would have anything to do with the problem. Or maybe I am misunderstanding the impact of this commit? FWIW, here is the bisect log: git bisect start # good: [227423904c709a8e60245c97081bbeb4fb500655] Merge branch 'x86-pat-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip git bisect good 227423904c709a8e60245c97081bbeb4fb500655 # bad: [0f29f5871c165e346409f62d903f97cfad3894c5] Staging: rtl8192su: remove RTL8192SU ifdefs git bisect bad 0f29f5871c165e346409f62d903f97cfad3894c5 # bad: [ada3fa15057205b7d3f727bba5cd26b5912e350f] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu git bisect bad ada3fa15057205b7d3f727bba5cd26b5912e350f # bad: [ada3fa15057205b7d3f727bba5cd26b5912e350f] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu git bisect bad ada3fa15057205b7d3f727bba5cd26b5912e350f # good: [decee2e8a9538ae5476e6cb3f4b7714c92a04a2b] V4L/DVB (12485): zl10353: correct implementation of FE_READ_UNCORRECTED_BLOCKS git bisect good decee2e8a9538ae5476e6cb3f4b7714c92a04a2b # good: [0ee7e4d6d4f58c3b2d9f0ca8ad8f63abda8694b1] V4L/DVB (12694): gspca - vc032x: Change the start exchanges of the sensor hv7131r. git bisect good 0ee7e4d6d4f58c3b2d9f0ca8ad8f63abda8694b1 # good: [f58dc01ba2ca9fe3ab2ba4ca43d9c8a735cf62d8] percpu: generalize first chunk allocator selection git bisect good f58dc01ba2ca9fe3ab2ba4ca43d9c8a735cf62d8 # good: [2f82af08fcc7dc01a7e98a49a5995a77e32a2925] Nicolas Pitre has a new email address git bisect good 2f82af08fcc7dc01a7e98a49a5995a77e32a2925 # good: [cf88c79006bd6a09ad725ba0b34c0e23db20b19e] vmalloc: separate out insert_vmalloc_vm() git bisect good cf88c79006bd6a09ad725ba0b34c0e23db20b19e # good: [4518e6a0c038b98be4c480e6f4481e8676bd15dd] x86,percpu: use embedding for 64bit NUMA and page for 32bit NUMA git bisect good 4518e6a0c038b98be4c480e6f4481e8676bd15dd # good: [bcb2107fdbecef3de55d597d23453747af81ba88] sparc64: use embedding percpu first chunk allocator git bisect good bcb2107fdbecef3de55d597d23453747af81ba88 # good: [5579fd7e6aed8860ea0c8e3f11897493153b10ad] Merge branch 'for-next' into for-linus git bisect good 5579fd7e6aed8860ea0c8e3f11897493153b10ad Oh, wait, that commit was tested, in the middle of the log above. -Andrew -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel bug in kvm_intel
On 10/31/2009 06:25 PM, Andrew Theurer wrote: 5579 is not the preceding commit, it is the merged branch: commit ada3fa15057205b7d3f727bba5cd26b5912e350f Merge: 2f82af0 5579fd7 Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Sep 15 09:39:44 2009 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu What happens with 2f82af0? 2f82af0 is: Nicolas Pitre has a new email address Due to problems at cam.org, my n...@cam.org email address is no longer valid. FRom now on, n...@fluxnic.net should be used instead. I have not tested that, but it doesn't seem likely that it would have anything to do with the problem. Or maybe I am misunderstanding the impact of this commit? ada3fa15 is known broken. It is the merge of two branches: 2f82 (mainline) and 5597. Testing both branches would indicate the problem is in the merge if both test ok. Oh, wait, that commit was tested, in the middle of the log above. So the problem is the merge. Will look. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel bug in kvm_intel
On 10/31/2009 06:32 PM, Avi Kivity wrote: On 10/31/2009 06:25 PM, Andrew Theurer wrote: 5579 is not the preceding commit, it is the merged branch: commit ada3fa15057205b7d3f727bba5cd26b5912e350f Merge: 2f82af0 5579fd7 Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Sep 15 09:39:44 2009 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu What happens with 2f82af0? 2f82af0 is: Nicolas Pitre has a new email address Due to problems at cam.org, my n...@cam.org email address is no longer valid. FRom now on, n...@fluxnic.net should be used instead. I have not tested that, but it doesn't seem likely that it would have anything to do with the problem. Or maybe I am misunderstanding the impact of this commit? ada3fa15 is known broken. It is the merge of two branches: 2f82 (mainline) and 5597. Testing both branches would indicate the problem is in the merge if both test ok. Oh, wait, that commit was tested, in the middle of the log above. So the problem is the merge. Will look. Only, that merge doesn't change virt/kvm or arch/x86/kvm. Tejun, anything known bad about that merge? ada3fa15 kills kvm. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP blue screen with qemu-kvm-0.11.0
On Sat, 2009-10-31 at 15:21 +0300, Michael Tokarev wrote: Ross Boylan wrote: My XP VM was working OK, and then started crashing shortly after it logged me in. There were no obvious changes at the time. I built the latest qemu-kvm, but the problem persists. I am running 32 bit XP on Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (8 cores total), Debian GNU/Linux mostly Lenny (amd64), but with some more recent stuff. In particular, the kernel is 2.6.30-8 and I pulled in the kernel-headers package to match before building kvm. However, libc6 and libc6-dev are at Lenny's 2.7-18 version. Libc is basically irrelevant here. What matters are the host kernel and kvm version. BTW, I do not have libvirt installed. $ ./XP.sh ++ sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:12:01:00 -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl -boot c -vga std -hda /dev/turtle/XP01 -soundhw es1370 -localtime -m 1G -smp 2 arg ,vlan=1,sock=/var/run/vde2/tap0.ctl TUNGETIFF ioctl() failed: Invalid argument TUNSETOFFLOAD ioctl() failed: Bad address Are the previous 2 messages significant? Just noise from vdeq? ... The VM starts; I see the initial XP screen with the 4 colors; I see the background I get when I log in (it logs me in directly without prompt); and then (pretty fast) I get a blue screen. The stop code is 0x8E, and the text says to check disk space and BIOS options. What's the bios files your kvm uses? How do I find out? Are they by a change from some old qemu install? Does kvm deb from http://www.corpit.ru/debian/tls/kvm/ expose the same issue? I'll try the next time I'm at the machine (I've also had problems with remote use). -no-kvm-irqchip and -no-kvm-pit make no difference. With -no-kvm I get stop code 0x24 and a suggestion to disable anti-virus, defragmentation, and backup software. This is the one obvious change between the Lenny kvm and the one I just built; with lenny kvm (kvm 72+dfsg-5~lenny3) running with -no-kvm simply seemed to hang forever (I think I waited at least 15 minutes). This disk turtle/XP01 is a read-write snapshot on turtle/XP00. The snapshot looks healthy, with about 50% allocated to the snapshot. The snapshot volume is 10G and the original is 50G. The VM starts fine if I point it to XP00 instead of XP01. Well, that's telling, isn't it? If you change disk image and it works, the problem should be in the disk image... Maybe. As I said, it was working, and I get different errors with --no-kvm. Is there a way I can mount the individual partitions on XP01 to get a look at them? It took a lot of time to create this, so I'm really hoping I can salvage it. P.S. What are the different files in my kvm/bin directory? There's no kvm/bin directory in the source tarball of qemu-kvm-0.11.0. I'm referring to the installation directories: /usr/local/kvm/bin$ ls qemu-img qemu-io qemu-nbd qemu-system-x86_64 Ross -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP blue screen with qemu-kvm-0.11.0
Ross Boylan wrote: [] ++ sudo vdeq bin/qemu-system-x86_64 -net nic,vlan=1,macaddr=52:54:a0:12:01:00 -net vde,vlan=1,sock=/var/run/vde2/tap0.ctl -boot c -vga std -hda /dev/turtle/XP01 -soundhw es1370 -localtime -m 1G -smp 2 arg ,vlan=1,sock=/var/run/vde2/tap0.ctl TUNGETIFF ioctl() failed: Invalid argument TUNSETOFFLOAD ioctl() failed: Bad address Are the previous 2 messages significant? Just noise from vdeq? Not that I really know. I missed these in your original email. But again, I don't use vde, and since the argument for the -net command is a socket, I guess it gets messed up - kvm assumes it's a tun device, not a socket... The VM starts; I see the initial XP screen with the 4 colors; I see the background I get when I log in (it logs me in directly without prompt); and then (pretty fast) I get a blue screen. The stop code is 0x8E, and the text says to check disk space and BIOS options. What's the bios files your kvm uses? How do I find out? I usually use strace. Dunno really, it looks like there's no way to ask where kvm will look for bios files. [] The VM starts fine if I point it to XP00 instead of XP01. Well, that's telling, isn't it? If you change disk image and it works, the problem should be in the disk image... Maybe. As I said, it was working, and I get different errors with --no-kvm. With -no-kvm you're exposing less-tested code paths in kvm. Is there a way I can mount the individual partitions on XP01 to get a look at them? It took a lot of time to create this, so I'm really hoping I can salvage it. That's what qemu-nbd is for. Or qemu-img convert it to raw and use kpartx on it. P.S. What are the different files in my kvm/bin directory? There's no kvm/bin directory in the source tarball of qemu-kvm-0.11.0. I'm referring to the installation directories: /usr/local/kvm/bin$ ls qemu-img qemu-io qemu-nbd qemu-system-x86_64 There are manpages for each (except qemu-io which is a debugging tool). See also qemu documentation. /mjt -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Autotest] [PATCH] [RFC] KVM test: Major control file cleanup
- Ryan Harper ry...@us.ibm.com wrote: * Lucas Meneghel Rodrigues l...@redhat.com [2009-10-28 14:48]: Ryan, Michael: I absolutely agree that the ability to debug stuff is important, but the ability to make things straightforward to use from the web interface or cli is also important. A longer term goal is to have our test farm and make any developer able to schedule a job on the test farm easily and conveniently. Having the dictionaries generated on the job debug directory seems like a good compromise to me. Also we can come up with a smart way of parsing the config file generated by a given control file in a similar way we do today with kvm_config.py, it shouldn't be that hard to do it... (I hope I won't burn my tongue with this statement). If I'm understanding things, we are talking about moving the large body of kvm_tests.cfg test definitions, guest definitions into a library, and then moving the requested test config (bottom on kvm_tests.cfg) into the control file itself which means the autotest webui would be able to control which tests get run; I like this idea very well. My concern that I mentioned is that as you edit the library it can be difficult to ensure you described exactly which set of tests on which guests you want to run and kvm_config.py is invaluable in the process of getting it right. Why not have kvm_config.py , or some other wrapper generate a kvm_tests.cfg file dynamically from the library and the strings from the control file? That way we could still debug configuration via kvm_config.py? I much perfer this over queueing up jobs in the webiu, waiting for it to run, checking the results in the DEBUG dir, adjusting, repeat. I'm not sure I understand your idea: you want some program to read the control file and generate a new file (kvm_tests.cfg or something) from the control file and the library file, so that this file can be debugged with kvm_config.py? IMO this solution is dirty because the control file is python code, not our own format, so it's not nice to automatically extract stuff from it. It would be nice to do something that eases debugging, but if you ask me, I'd rather have something as clean as possible. Here's another idea, which I suggested but haven't received any feedback on: let's write a little proggie that runs the control file just like client/bin/autotest does. The proggie will supply the control file with a fake job object that has nothing but a run_test() method, but instead of running a test, that method will simply nicely print out the test params, like kvm_config.py does. So the user will be able to do something like './dry_run.py control.mine' which will list all the tests to be executed. We might also want to implement job.parallel() in addition to job.run_test() but that should be very easy (it doesn't really have to be parallel at all). Does that make any sense? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/27] Split init_new_context and destroy_context
Stephen Rothwell wrote: Hi Alexander, On Fri, 30 Oct 2009 16:47:20 +0100 Alexander Graf ag...@suse.de wrote: --- a/arch/powerpc/include/asm/mmu_context.h +++ b/arch/powerpc/include/asm/mmu_context.h @@ -23,6 +23,11 @@ extern void switch_slb(struct task_struct *tsk, struct mm_struct *mm); extern void set_context(unsigned long id, pgd_t *pgd); #ifdef CONFIG_PPC_BOOK3S_64 +extern int __init_new_context(void); +extern void __destroy_context(int context_id); +#endif + +#ifdef CONFIG_PPC_BOOK3S_64 don't add the #endif/#ifdef pair ... Any other comments? I'd like to wind up a final patch set so I can stop spamming on all those MLs :-). Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/27] Split init_new_context and destroy_context
On Sat, 2009-10-31 at 22:20 +0100, Alexander Graf wrote: Stephen Rothwell wrote: Hi Alexander, On Fri, 30 Oct 2009 16:47:20 +0100 Alexander Graf ag...@suse.de wrote: --- a/arch/powerpc/include/asm/mmu_context.h +++ b/arch/powerpc/include/asm/mmu_context.h @@ -23,6 +23,11 @@ extern void switch_slb(struct task_struct *tsk, struct mm_struct *mm); extern void set_context(unsigned long id, pgd_t *pgd); #ifdef CONFIG_PPC_BOOK3S_64 +extern int __init_new_context(void); +extern void __destroy_context(int context_id); +#endif + +#ifdef CONFIG_PPC_BOOK3S_64 don't add the #endif/#ifdef pair ... Any other comments? I'd like to wind up a final patch set so I can stop spamming on all those MLs :-). Just send an update for -that- patch to the list. Ben. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/27] Export symbols for KVM module
Am 31.10.2009 um 05:37 schrieb Stephen Rothwell s...@canb.auug.org.au: Hi Alexander, On Fri, 30 Oct 2009 16:47:19 +0100 Alexander Graf ag...@suse.de wrote: diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ ppc_ksyms.c index c8b27bb..baf778c 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -163,11 +163,12 @@ EXPORT_SYMBOL(screen_info); #ifdef CONFIG_PPC32 EXPORT_SYMBOL(timer_interrupt); EXPORT_SYMBOL(irq_desc); -EXPORT_SYMBOL(tb_ticks_per_jiffy); EXPORT_SYMBOL(cacheable_memcpy); EXPORT_SYMBOL(cacheable_memzero); #endif +EXPORT_SYMBOL(tb_ticks_per_jiffy); Since you are moving this anyway, how about moving it into arch/powerpc/kernel/time.c where tb_ticks_per_jiffy is defined. Well the fun part is that the hrtimer conversion patch actually deprecates this change. I merely forgot to change the export back. So I suppose I'll leave things here as is and then revert this chunk in the hrtimer patch. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/27] Split init_new_context and destroy_context
On Sat, 2009-10-31 at 22:20 +0100, Alexander Graf wrote: Stephen Rothwell wrote: Hi Alexander, On Fri, 30 Oct 2009 16:47:20 +0100 Alexander Graf ag...@suse.de wrote: --- a/arch/powerpc/include/asm/mmu_context.h +++ b/arch/powerpc/include/asm/mmu_context.h @@ -23,6 +23,11 @@ extern void switch_slb(struct task_struct *tsk, struct mm_struct *mm); extern void set_context(unsigned long id, pgd_t *pgd); #ifdef CONFIG_PPC_BOOK3S_64 +extern int __init_new_context(void); +extern void __destroy_context(int context_id); +#endif + +#ifdef CONFIG_PPC_BOOK3S_64 don't add the #endif/#ifdef pair ... Any other comments? I'd like to wind up a final patch set so I can stop spamming on all those MLs :-). Just send an update for -that- patch to the list. Ben. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
