On Thu, Mar 20, 2008 at 09:30:09PM -0700, Jeremy Fitzhardinge wrote:
quoted text
>Ravikiran G Thirumalai wrote:
>>- Fix the the build breakage when PARAVIRT is defined
>>  but PCI is not
>>  This fixes problem reported at:
>>	http://marc.info/?l=linux-kernel&m=120525966600698&w=2
>>- Make is_vsmp_box() available even when PARAVIRT is not defined.
>>  This is needed to determine if tsc's are reliable as a time source
>>  even when PARAVIRT is not defined.
>>- split vsmp_init to use is_vsmp_box() and set_vsmp_pv_ops()
>>  set_vsmp_pv_ops will do nothing if PCI is not enabled in the config.
>>  
>
>I'm a bit confused by all the config dependencies.  I had assumed that 
>VSMP depended on both PCI and PARAVIRT.  Is this not actually true?  You 
>can have a VSMP system without either or both of PCI/PARAVIRT?

Well, you could have a vSMPowered system without PARAVIRT, yes.  But a non
PCI vSMPowered system does not exist to my knowledge.

quoted text
>
>The structure of the code suggests that at the very least VSMP depends 
>on PCI (it never makes sense to enable VSMP on a non-PCI system), and 
>therefore a number of your config decisions can just be predicated on VSMP.

Well, vSMPowered bits in the kernel serves two objectives:
a) Internode cacheline size
b) paravirt irq ops

A vSMPowered machine can boot without either, but both affect performance.
Both these bits are not interdependent.  The paravirt ops
need the PARAVIRT infrastructure and that is all that is needed.
The internode cacheline size needs a compile time definition that's all.
CONFIG_X86_VSMP chooses both.  However, there is no reason to have paravirt
irq ops depend on the Internode cacheline size.  More so since pv ops
has the capability to detect the system type dynamically and using
appropriate pv ops.

Thanks,
Kiran
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/