Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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 +0000, 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


Home | Main Index | Thread Index | Old Index