KVM is currently completely broken for the !CONFIG_SMP case.
drivers/kvm/kvm_main.c: In function ‘kvm_flush_remote_tlbs’:
drivers/kvm/kvm_main.c:220: error: implicit declaration of function ‘smp_call_function_mask’
Signed-off-by: Jeff Garzik <[email protected]>
---
I hope the KVM maintainer can come up with a better solution...
diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
index 8749fa4..e35fbc6 100644
--- a/drivers/kvm/Kconfig
+++ b/drivers/kvm/Kconfig
@@ -16,7 +16,7 @@ if VIRTUALIZATION
config KVM
tristate "Kernel-based Virtual Machine (KVM) support"
- depends on X86 && EXPERIMENTAL
+ depends on X86 && EXPERIMENTAL && SMP
select PREEMPT_NOTIFIERS
select ANON_INODES
---help---
On Tue, Oct 23, 2007 at 06:36:40PM -0400, Jeff Garzik wrote:
> KVM is currently completely broken for the !CONFIG_SMP case.
>
> drivers/kvm/kvm_main.c: In function ‘kvm_flush_remote_tlbs’:
> drivers/kvm/kvm_main.c:220: error: implicit declaration of function ‘smp_call_function_mask’
>
> Signed-off-by: Jeff Garzik <[email protected]>
> ---
> I hope the KVM maintainer can come up with a better solution...
>
> diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
> index 8749fa4..e35fbc6 100644
> --- a/drivers/kvm/Kconfig
> +++ b/drivers/kvm/Kconfig
> @@ -16,7 +16,7 @@ if VIRTUALIZATION
>
> config KVM
> tristate "Kernel-based Virtual Machine (KVM) support"
> - depends on X86 && EXPERIMENTAL
> + depends on X86 && EXPERIMENTAL && SMP
>...
Assuming it won't get fixed soon, the pattern would be "(SMP || BROKEN)".
The effect is the same, but this makes it more obvious that KVM
does not depend architecturally on SMP but just broken.
Of course, the preferred solution is to simply get KVM fixed...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> On Tue, Oct 23, 2007 at 06:36:40PM -0400, Jeff Garzik wrote:
>> KVM is currently completely broken for the !CONFIG_SMP case.
>>
>> drivers/kvm/kvm_main.c: In function ‘kvm_flush_remote_tlbs’:
>> drivers/kvm/kvm_main.c:220: error: implicit declaration of function ‘smp_call_function_mask’
>>
>> Signed-off-by: Jeff Garzik <[email protected]>
>> ---
>> I hope the KVM maintainer can come up with a better solution...
>>
>> diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
>> index 8749fa4..e35fbc6 100644
>> --- a/drivers/kvm/Kconfig
>> +++ b/drivers/kvm/Kconfig
>> @@ -16,7 +16,7 @@ if VIRTUALIZATION
>>
>> config KVM
>> tristate "Kernel-based Virtual Machine (KVM) support"
>> - depends on X86 && EXPERIMENTAL
>> + depends on X86 && EXPERIMENTAL && SMP
>> ...
>
> Assuming it won't get fixed soon, the pattern would be "(SMP || BROKEN)".
>
> The effect is the same, but this makes it more obvious that KVM
> does not depend architecturally on SMP but just broken.
>
> Of course, the preferred solution is to simply get KVM fixed...
In general I agree, but I specifically avoided CONFIG_BROKEN in case it
was an intentional choice to require an SMP kernel.
Jeff
Jeff Garzik wrote:
> Adrian Bunk wrote:
>> On Tue, Oct 23, 2007 at 06:36:40PM -0400, Jeff Garzik wrote:
>>> KVM is currently completely broken for the !CONFIG_SMP case.
>>>
>>> drivers/kvm/kvm_main.c: In function ‘kvm_flush_remote_tlbs’:
>>> drivers/kvm/kvm_main.c:220: error: implicit declaration of function
>>> ‘smp_call_function_mask’
>>>
>>> Signed-off-by: Jeff Garzik <[email protected]>
>>> ---
>>> I hope the KVM maintainer can come up with a better solution...
>>>
>>> diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig
>>> index 8749fa4..e35fbc6 100644
>>> --- a/drivers/kvm/Kconfig
>>> +++ b/drivers/kvm/Kconfig
>>> @@ -16,7 +16,7 @@ if VIRTUALIZATION
>>>
>>> config KVM
>>> tristate "Kernel-based Virtual Machine (KVM) support"
>>> - depends on X86 && EXPERIMENTAL
>>> + depends on X86 && EXPERIMENTAL && SMP
>>> ...
>>
>> Assuming it won't get fixed soon, the pattern would be "(SMP ||
>> BROKEN)".
>>
>> The effect is the same, but this makes it more obvious that KVM does
>> not depend architecturally on SMP but just broken.
>>
>> Of course, the preferred solution is to simply get KVM fixed...
>
> In general I agree, but I specifically avoided CONFIG_BROKEN in case
> it was an intentional choice to require an SMP kernel.
>
Of course SMP is not required. I'll submit a patch to make
smp_call_function_mask() available on UP kernels. Andrew, please don't
apply the KVM Kconfig patch.
--
error compiling committee.c: too many arguments to function
* Avi Kivity <[email protected]> wrote:
> Of course SMP is not required. I'll submit a patch to make
> smp_call_function_mask() available on UP kernels. Andrew, please
> don't apply the KVM Kconfig patch.
i have triggered this and fixed it the right way - see the patch below.
This fixes the 2.6.24-rc1 build error.
Ingo
------------------->
Subject: kvm: fix !SMP build error
From: Ingo Molnar <[email protected]>
fix !SMP build error:
drivers/kvm/kvm_main.c: In function 'kvm_flush_remote_tlbs':
drivers/kvm/kvm_main.c:220: error: implicit declaration of function 'smp_call_function_mask'
(and also avoid unused function warning related to up_smp_call_function()
not making use of the 'func' parameter.)
Signed-off-by: Ingo Molnar <[email protected]>
---
include/linux/smp.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux/include/linux/smp.h
===================================================================
--- linux.orig/include/linux/smp.h
+++ linux/include/linux/smp.h
@@ -84,11 +84,12 @@ void smp_prepare_boot_cpu(void);
* These macros fold the SMP functionality into a single CPU system
*/
#define raw_smp_processor_id() 0
-static inline int up_smp_call_function(void)
+static inline int up_smp_call_function(void (*func)(void *), void *info)
{
return 0;
}
-#define smp_call_function(func,info,retry,wait) (up_smp_call_function())
+#define smp_call_function(func,info,retry,wait) \
+ (up_smp_call_function(func, info))
#define on_each_cpu(func,info,retry,wait) \
({ \
local_irq_disable(); \
@@ -107,6 +108,8 @@ static inline void smp_send_reschedule(i
local_irq_enable(); \
0; \
})
+#define smp_call_function_mask(mask,func,info,wait) \
+ (up_smp_call_function(func, info))
#endif /* !SMP */
* Ingo Molnar <[email protected]> wrote:
> i have triggered this and fixed it the right way - see the patch
> below. This fixes the 2.6.24-rc1 build error.
and this followup patch is needed too if my patch is applied.
Ingo
------------------->
Subject: x86: fix build error in arch/x86/kernel/cpu/mtrr/main.c
From: Ingo Molnar <[email protected]>
ipi_handler() must be available on !SMP too.
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/cpu/mtrr/main.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux/arch/x86/kernel/cpu/mtrr/main.c
@@ -139,13 +139,12 @@ struct set_mtrr_data {
mtrr_type smp_type;
};
-#ifdef CONFIG_SMP
-
static void ipi_handler(void *info)
/* [SUMMARY] Synchronisation handler. Executed by "other" CPUs.
[RETURNS] Nothing.
*/
{
+#ifdef CONFIG_SMP
struct set_mtrr_data *data = info;
unsigned long flags;
@@ -168,9 +167,8 @@ static void ipi_handler(void *info)
atomic_dec(&data->count);
local_irq_restore(flags);
-}
-
#endif
+}
static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
return type1 == MTRR_TYPE_UNCACHABLE ||
* Ingo Molnar <[email protected]> wrote:
> * Ingo Molnar <[email protected]> wrote:
>
> > i have triggered this and fixed it the right way - see the patch
> > below. This fixes the 2.6.24-rc1 build error.
>
> and this followup patch is needed too if my patch is applied.
plus the patch below is needed too in addition.
Ingo
------------->
Subject: x86: fix build error in arch/x86/kernel/nmi_32.c
From: Ingo Molnar <[email protected]>
nmi_cpu_busy() must be available on !SMP too.
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/nmi_32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/arch/x86/kernel/nmi_32.c
===================================================================
--- linux.orig/arch/x86/kernel/nmi_32.c
+++ linux/arch/x86/kernel/nmi_32.c
@@ -53,13 +53,13 @@ static int unknown_nmi_panic_callback(st
static int endflag __initdata = 0;
-#ifdef CONFIG_SMP
/* The performance counters used by NMI_LOCAL_APIC don't trigger when
* the CPU is idle. To make sure the NMI watchdog really ticks on all
* CPUs during the test make them busy.
*/
static __init void nmi_cpu_busy(void *data)
{
+#ifdef CONFIG_SMP
local_irq_enable_in_hardirq();
/* Intentionally don't use cpu_relax here. This is
to make sure that the performance counter really ticks,
@@ -69,8 +69,8 @@ static __init void nmi_cpu_busy(void *da
care if they get somewhat less cycles. */
while (endflag == 0)
mb();
-}
#endif
+}
static int __init check_nmi_watchdog(void)
{
On Wed, 24 Oct 2007 20:11:07 +0200 Ingo Molnar wrote:
>
> * Ingo Molnar <[email protected]> wrote:
>
> > * Ingo Molnar <[email protected]> wrote:
> >
> > > i have triggered this and fixed it the right way - see the patch
> > > below. This fixes the 2.6.24-rc1 build error.
> >
> > and this followup patch is needed too if my patch is applied.
>
> plus the patch below is needed too in addition.
>
> Ingo
Hi,
I'm still hitting this build error. Are these 3 patches not yet
merged??
Thanks.
> ------------->
> Subject: x86: fix build error in arch/x86/kernel/nmi_32.c
> From: Ingo Molnar <[email protected]>
>
> nmi_cpu_busy() must be available on !SMP too.
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> arch/x86/kernel/nmi_32.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux/arch/x86/kernel/nmi_32.c
> ===================================================================
> --- linux.orig/arch/x86/kernel/nmi_32.c
> +++ linux/arch/x86/kernel/nmi_32.c
> @@ -53,13 +53,13 @@ static int unknown_nmi_panic_callback(st
>
> static int endflag __initdata = 0;
>
> -#ifdef CONFIG_SMP
> /* The performance counters used by NMI_LOCAL_APIC don't trigger when
> * the CPU is idle. To make sure the NMI watchdog really ticks on all
> * CPUs during the test make them busy.
> */
> static __init void nmi_cpu_busy(void *data)
> {
> +#ifdef CONFIG_SMP
> local_irq_enable_in_hardirq();
> /* Intentionally don't use cpu_relax here. This is
> to make sure that the performance counter really ticks,
> @@ -69,8 +69,8 @@ static __init void nmi_cpu_busy(void *da
> care if they get somewhat less cycles. */
> while (endflag == 0)
> mb();
> -}
> #endif
> +}
>
> static int __init check_nmi_watchdog(void)
> {
> -
---
~Randy
* Randy Dunlap <[email protected]> wrote:
> > > and this followup patch is needed too if my patch is applied.
> >
> > plus the patch below is needed too in addition.
> >
> > Ingo
>
> Hi,
> I'm still hitting this build error. Are these 3 patches not yet
> merged??
i thought we agreed it would go in via KVM. Can send it as part of the
scheduler git tree too, these patches are working fine for me. Avi?
Ingo
Ingo Molnar wrote:
> * Randy Dunlap <[email protected]> wrote:
>
>
>>>> and this followup patch is needed too if my patch is applied.
>>>>
>>> plus the patch below is needed too in addition.
>>>
>>> Ingo
>>>
>> Hi,
>> I'm still hitting this build error. Are these 3 patches not yet
>> merged??
>>
>
> i thought we agreed it would go in via KVM. Can send it as part of the
> scheduler git tree too, these patches are working fine for me. Avi?
>
>
I thought you were handling it, as they aren't part of kvm proper. But
I can send them, sure.
--
Any sufficiently difficult bug is indistinguishable from a feature.
* Avi Kivity <[email protected]> wrote:
> I thought you were handling it, as they aren't part of kvm proper.
> But I can send them, sure.
i've got them in my queue already so i'll send them in the next
scheduler batch, ok?
Ingo
Ingo Molnar wrote:
> * Avi Kivity <[email protected]> wrote:
>
>
>> I thought you were handling it, as they aren't part of kvm proper.
>> But I can send them, sure.
>>
>
> i've got them in my queue already so i'll send them in the next
> scheduler batch, ok?
>
Thanks.
--
Any sufficiently difficult bug is indistinguishable from a feature.