mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Glauber de Oliveira Costa <gcosta@redhat.com>,
	Andi Kleen <ak@suse.de>,
	shai@scalex86.org
Subject: Re: [patch 2/4] x86: Fix build breakage when PCI is define and PARAVIRT is not
Date: Fri, 21 Mar 2008 11:54:34 -0700	[thread overview]
Message-ID: <20080321185434.GB23139@localdomain> (raw)
In-Reply-To: <47E339D1.3080509@goop.org>

On Thu, Mar 20, 2008 at 09:30:09PM -0700, Jeremy Fitzhardinge wrote:
>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.

>
>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

  parent reply	other threads:[~2008-03-21 18:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20  7:37 [patch 0/4] x86: vSMP updates Ravikiran G Thirumalai
2008-03-20  7:39 ` [patch 1/4] x86: vSMP: Fix is_vsmp_box() Ravikiran G Thirumalai
2008-03-20  7:44   ` Yinghai Lu
2008-03-20 18:40     ` Ravikiran G Thirumalai
2008-03-21  9:11       ` Ingo Molnar
2008-03-21  9:17         ` Yinghai Lu
2008-03-21 17:59         ` Ravikiran G Thirumalai
2008-03-20  7:41 ` [patch 2/4] x86: Fix build breakage when PCI is define and PARAVIRT is not Ravikiran G Thirumalai
2008-03-21  4:30   ` Jeremy Fitzhardinge
2008-03-21  6:28     ` Yinghai Lu
2008-03-21 18:54     ` Ravikiran G Thirumalai [this message]
2008-03-22  2:19       ` Jeremy Fitzhardinge
2008-03-20  7:43 ` [patch 3/4] x86: vSMP: Use pvops only if platform has the capability to support it Ravikiran G Thirumalai
2008-03-20  7:45 ` [patch 4/4] x86: apic_is_clustered_box to indicate unsynched TSC's on multiboard vSMP systems Ravikiran G Thirumalai
2008-03-20  7:53   ` Yinghai Lu
2008-03-20 19:02     ` Ravikiran G Thirumalai
2008-03-21  9:15       ` Ingo Molnar
2008-03-21 18:52         ` Ravikiran G Thirumalai
2008-03-21 18:58           ` Ingo Molnar
2008-03-22 18:59             ` Ravikiran G Thirumalai
2008-03-22 20:02               ` Ingo Molnar
2008-03-24 21:48                 ` Ravikiran G Thirumalai
2008-03-25 15:50                   ` Ingo Molnar
2008-03-21  8:54 ` [patch 0/4] x86: vSMP updates Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080321185434.GB23139@localdomain \
    --to=kiran@scalex86.org \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=gcosta@redhat.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=shai@scalex86.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®