Re: CVS commit: [cherry-xenmp] src/sys/arch/xen/xen
Hi Manuel, On 23 October 2011 04:12, Manuel Bouyer bou...@netbsd.org wrote: Module Name: src Committed By: bouyer Date: Sat Oct 22 22:42:21 UTC 2011 Modified Files: src/sys/arch/xen/xen [cherry-xenmp]: clock.c Log Message: More improvements: - Precise what tmutex protects - springle some KASSERT(mutex_owned(tmutex)) - the system time uses the CPU timecounter to get some precision; don't mix local CPU timecounter with VCPU0's time, it won't work well. Always use curcpu()'s time. To generate a diff of this commit: cvs rdiff -u -r1.54.6.6 -r1.54.6.7 src/sys/arch/xen/xen/clock.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Thanks for this - I'm curious to know if this fixes the clock drift that has been reported on port-xen@ Thanks, -- ~Cherry
Re: CVS commit: [cherry-xenmp] src/sys/arch
On 31/08/2011, Jean-Yves Migeon jeanyves.mig...@free.fr wrote: On 30.08.2011 14:53, Cherry G. Mathew wrote: Module Name: src Committed By:cherry Date:Tue Aug 30 12:53:46 UTC 2011 Modified Files: src/sys/arch/i386/i386 [cherry-xenmp]: machdep.c src/sys/arch/xen/x86 [cherry-xenmp]: cpu.c x86_xpmap.c Log Message: Add per-cpu mmu queues Thanks for looking into it! I do owe you a reply on tech-kern@ :-) Will get to it once I have more data! Thanks, -- ~Cherry
Re: CVS commit: [cherry-xenmp] src/sys/arch
On 30.08.2011 14:53, Cherry G. Mathew wrote: Module Name: src Committed By: cherry Date: Tue Aug 30 12:53:46 UTC 2011 Modified Files: src/sys/arch/i386/i386 [cherry-xenmp]: machdep.c src/sys/arch/xen/x86 [cherry-xenmp]: cpu.c x86_xpmap.c Log Message: Add per-cpu mmu queues Thanks for looking into it! -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: [cherry-xenmp] src/sys/arch/xen/x86
On 27 June 2011 12:23, Cherry G. Mathew che...@netbsd.org wrote: Module Name: src Committed By: cherry Date: Mon Jun 27 10:23:21 UTC 2011 Modified Files: src/sys/arch/xen/x86 [cherry-xenmp]: x86_xpmap.c Log Message: Add xpq locking around xpq-QUEUE_TLB_FLUSH() sorry, that was meant to be: Add xpq locking around xpq_queue_tlb_flush() cvs surgery done. Thanks, -- ~Cherry
Re: CVS commit: [cherry-xenmp] src/sys/arch/xen
On Sun, Jun 26, 2011 at 12:56:33PM +, Cherry G. Mathew wrote: Module Name: src Committed By: cherry Date: Sun Jun 26 12:56:33 UTC 2011 Modified Files: src/sys/arch/xen/include [cherry-xenmp]: intr.h src/sys/arch/xen/xen [cherry-xenmp]: hypervisor.c Log Message: Unbreak uniprocessor build I've asked this privately few times, but what -- if any -- is the rationale of #ifdef MULTIPROCESSOR in 2011 (for x86 MD, at least)? - Jukka.
Re: CVS commit: [cherry-xenmp] src/sys/arch/xen
On Sun, Jun 26, 2011 at 04:00:47PM +0300, Jukka Ruohonen wrote: On Sun, Jun 26, 2011 at 12:56:33PM +, Cherry G. Mathew wrote: Module Name:src Committed By: cherry Date: Sun Jun 26 12:56:33 UTC 2011 Modified Files: src/sys/arch/xen/include [cherry-xenmp]: intr.h src/sys/arch/xen/xen [cherry-xenmp]: hypervisor.c Log Message: Unbreak uniprocessor build I've asked this privately few times, but what -- if any -- is the rationale of #ifdef MULTIPROCESSOR in 2011 (for x86 MD, at least)? This is Xen, not x86. This may go away some day, but not yet - let the Xen MULTIPROCESSOR code stabilize first. Also, you seem to assume that all x86 CPUs on today's market are muticore; this is not true. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: [cherry-xenmp] src/sys/arch/xen
On Sun, Jun 26, 2011 at 05:57:37PM +0300, Jukka Ruohonen wrote: On Sun, Jun 26, 2011 at 04:39:55PM +0200, Manuel Bouyer wrote: Also, you seem to assume that all x86 CPUs on today's market are muticore; this is not true. No, I don't assume that. My reasoning is more like: this is one of those seldom tested code paths; why can't there be a single source for UP/MP x86? What disadvantages -- if any -- there are for UP running MULTIPROCESSOR? Is it worth to compile non-MULTIPROCESSOR kernel for UP systems, and why? Are there any reliability concerns involved in doing that? No reliability, but eventually bloat (and so speed). Also, MULTIPROCESSOR on Xen is the seldom tested code path, that's why I want to keep the ability to run !MULTIPROCESSOR kernels for some time. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: [cherry-xenmp] src/sys/arch/xen
On 6/26/2011 3:00 PM, Jukka Ruohonen wrote: On Sun, Jun 26, 2011 at 12:56:33PM +, Cherry G. Mathew wrote: Module Name:src Committed By: cherry Date: Sun Jun 26 12:56:33 UTC 2011 Modified Files: src/sys/arch/xen/include [cherry-xenmp]: intr.h src/sys/arch/xen/xen [cherry-xenmp]: hypervisor.c Log Message: Unbreak uniprocessor build I've asked this privately few times, but what -- if any -- is the rationale of #ifdef MULTIPROCESSOR in 2011 (for x86 MD, at least)? This has to do with the way the Xen domU kernel probes APs. In the UP case, one assumes that at least one cpu exists ( :-) ), and the attach succeeds. In the MP case, there is no way to figure out the number of configured number of vcpus, since xenstore is not accessible at that point ( see comments within the file). So we brute force, by telling Xen to bring up as many cpus as it lets us. In the case of domU, Xen will allow upto a maximum number of vcpus specified in the VM config file. The reason I've put hypervisor_vcpu_print() within the #ifdef is that it needs to be quiet, since there's no way to know if the probe succeed until the vcpu_match() function returns. So in short - it's a hack. I agree that the #ifdef should go if possible. Cherry -- Arms, drugs and spirituality – these are the three big businesses in the world ~ Javed Akhtar
