SANDISK PENDRIVES
Get today an 8-GB Portable Sandisk Cruzer Blade USB flashdrive,on offer @ Ksh 1,600/= only... It has a stylish, compact design and generous capacity. The Cruzer Blade USB Flash Drive makes it easy to back up, transfer, and share your files. Available in capacities up to 64GB** , this USB drive lets you carry your photos, movies, music, and personal data wherever you go. Drives up to 64GB can hold your most important data.Sandisk Flashdiks comes handy,with features like: - SanDisk Secure Access software PASSWORD PROTECTS ** your files - Includes up to 2GB of online backup** with Yuu Waa - Transports important personal files, music, and video We also have16gb @ 2,800kshs,32gb@4,800kshs and 500gb External Portable Hard Drive @ 7,500kshs. Phone and Camera's Memory Cards in Stock too! We offer FREE DELIVERY within Nairobi Area.. Make your order now We only Sell SANDISK GENUINE PRODUCTS..WARRANTY 1 YEAR Looking Forward to receiving your order now !! Regards, Jimmy Cell: 0721-946602 Nairobi -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: SVM: fix cr8 intercept window
2014-03-11 22:05-0300, Marcelo Tosatti:
On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.
Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.
Cc: sta...@vger.kernel.org
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 64d9bb9..f676c18 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3003,10 +3003,8 @@ static int cr8_write_interception(struct vcpu_svm
*svm)
u8 cr8_prev = kvm_get_cr8(svm-vcpu);
/* instruction emulation calls kvm_set_cr8() */
r = cr_interception(svm);
- if (irqchip_in_kernel(svm-vcpu.kvm)) {
- clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+ if (irqchip_in_kernel(svm-vcpu.kvm))
return r;
- }
if (cr8_prev = kvm_get_cr8(svm-vcpu))
return r;
kvm_run-exit_reason = KVM_EXIT_SET_TPR;
@@ -3568,6 +3566,8 @@ static void update_cr8_intercept(struct kvm_vcpu
*vcpu, int tpr, int irr)
if (is_guest_mode(vcpu) (vcpu-arch.hflags HF_VINTR_MASK))
return;
+ clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+
if (irr == -1)
return;
Shouldnt IRR be injected if TPR IRR ? (via KVM_REQ_EVENT).
1) IRR has interrupt 10.
2) TPR now 9 due to CR8 write.
3) 10 should be injected.
Definitely should, and we will set KVM_REQ_EVENT through kvm_set_cr8()
if we lower the TPR.
(I checked that the bug isn't in apic_update_ppr().)
Also not clearing the intercept can cause continuous CR8 writes to
exit until KVM_REQ_EVENT ?
It is intended, I suppose this is because we run with V_INTR_MASKING, so
writes to CR8 only affect V_TPR register; guest then raises it once more
and APIC incorrectly gives us low priority interrupt.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enhancement for PLE handler in KVM
Thanks, Paolo for the comments Understand the requirement to fix it for all guest OSes. I will investigate the new hypercall KVM_HC_HALT_AND_YIELD_TO_CPU that takes an APIC id, donates the quantum to that CPU, and puts the originating CPU in halted state. Regards Bin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.13: BUG: soft lockup - CPU#1 stuck for 22s! [qemu-kvm:2653]
Il 11/03/2014 21:01, Jason S. Wagner ha scritto: Hi all, Over the weekend, Linux 3.13.6 was installed on my machine. When I started gnome-boxes on Monday morning, my VM halted during boot. Only a portion of the VESA BIOS init output was displayed on-screen before the halt. Backtraces occasionally appeared in dmesg (http://pastebin.com/uUiNLmJ6). Some other programs were prevented from performing some tasks while the VM was running. While investigating, I was directed to an earlier KVM bug report (https://lkml.org/lkml/2014/2/11/487). I downgraded to Linux 3.12.9 and rebooted, and now my VM is starting. Unfortunately, I'm very new to Linux, so I'm not sure what the next steps would be. Yeah, it's quite likely this is the issue you're facing. And the author of the report at http://www.spinics.net/lists/kvm/msg100196.html also told me privately that 64-bit kernel made it go away, so it's also likely to be the same thing. Thomas, do you also see a soft lockup message? Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: SVM: fix cr8 intercept window
On Wed, Mar 12, 2014 at 11:40:48AM +0100, Radim Krčmář wrote:
2014-03-11 22:05-0300, Marcelo Tosatti:
On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.
Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.
Cc: sta...@vger.kernel.org
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 64d9bb9..f676c18 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3003,10 +3003,8 @@ static int cr8_write_interception(struct vcpu_svm
*svm)
u8 cr8_prev = kvm_get_cr8(svm-vcpu);
/* instruction emulation calls kvm_set_cr8() */
r = cr_interception(svm);
- if (irqchip_in_kernel(svm-vcpu.kvm)) {
- clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+ if (irqchip_in_kernel(svm-vcpu.kvm))
return r;
- }
if (cr8_prev = kvm_get_cr8(svm-vcpu))
return r;
kvm_run-exit_reason = KVM_EXIT_SET_TPR;
@@ -3568,6 +3566,8 @@ static void update_cr8_intercept(struct kvm_vcpu
*vcpu, int tpr, int irr)
if (is_guest_mode(vcpu) (vcpu-arch.hflags HF_VINTR_MASK))
return;
+ clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+
if (irr == -1)
return;
Shouldnt IRR be injected if TPR IRR ? (via KVM_REQ_EVENT).
1) IRR has interrupt 10.
2) TPR now 9 due to CR8 write.
3) 10 should be injected.
Definitely should, and we will set KVM_REQ_EVENT through kvm_set_cr8()
if we lower the TPR.
(I checked that the bug isn't in apic_update_ppr().)
Yep.
Also not clearing the intercept can cause continuous CR8 writes to
exit until KVM_REQ_EVENT ?
It is intended, I suppose this is because we run with V_INTR_MASKING, so
writes to CR8 only affect V_TPR register; guest then raises it once more
and APIC incorrectly gives us low priority interrupt.
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: SVM: fix cr8 intercept window
Il 12/03/2014 11:40, Radim Krčmář ha scritto:
2014-03-11 22:05-0300, Marcelo Tosatti:
On Tue, Mar 11, 2014 at 07:11:18PM +0100, Radim Krčmář wrote:
We always disable cr8 intercept in its handler, but only re-enable it
if handling KVM_REQ_EVENT, so there can be a window where we do not
intercept cr8 writes, which allows an interrupt to disrupt a higher
priority task.
Fix this by disabling intercepts in the same function that re-enables
them when needed. This fixes BSOD in Windows 2008.
Cc: sta...@vger.kernel.org
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 64d9bb9..f676c18 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3003,10 +3003,8 @@ static int cr8_write_interception(struct vcpu_svm *svm)
u8 cr8_prev = kvm_get_cr8(svm-vcpu);
/* instruction emulation calls kvm_set_cr8() */
r = cr_interception(svm);
- if (irqchip_in_kernel(svm-vcpu.kvm)) {
- clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+ if (irqchip_in_kernel(svm-vcpu.kvm))
return r;
- }
I think that the old code here makes little sense, and for two reasons:
1) There are other ways to change the TPR, and the condition for
setting/clearing the CR8 intercept should be the same for all of them.
Now CR8 is the really optimized one, but there is no reason to treat
them differently and it just complicates understanding the code.
So it is a good thing that your patch moves the clearing of the CR8
write intercept in a generic place (the setting of the intercept is
already generic). Doesn't say much about the correctness of the patch;
it would be just an optimization. But at least the old code is the
smelly one.
2) Unconditionally disabling the CR8 intercept is definitely wrong.
What matters is the change in the PPR; if the processor priority is the
same as before, or higher, absolutely nothing has changed from the point
of view of interrupt delivery; if we had an interrupt in the IRR,
waiting to be delivered, we still have it, and we should keep the CR8
intercept enabled.
Your patch does the right thing by virtue of apic_update_ppr setting
KVM_REQ_EVENT (which ultimately calls update_cr8_intercept) exactly if
the PPR has been lowered. The call chain is
kvm_set_cr8-kvm_lapic_set_tpr-apic_set_tpr-apic_update_ppr.
At the end of this email I'll show an example of why this actually is
relatively common on Windows guests.
So, IMO there is no doubt that the change is semantically correct. The
next question then is whether it undoes the V_TPR optimization. You can
prove it by a sort of induction; consider a sequences of events that
start and end with the same IRR, assume CR8 is not intercepted at the
beginning, and prove that CR8 is still not intercepted afterwards.
We can assume that all changes to the TPR are balanced and properly
nested (except you can go low-med-high-low).
The simple sequences are:
1) changes in TPR with no interrupts in the middle; remember that
Windows doesn't really ever disable/enable preemption or interrupt flags
like Linux does. It only modifies the TPR (raise/lower the IRQL, they
call it). We're assuming that the CR8 intercept is initially disabled,
so a raised-IRQL section of the code that doesn't cause other vmexits
will obviously run at full speed. Not much to see here.
2) delivery of an unmasked interrupt (with priority P) and subsequent
EOI. Changes to TPR don't really matter until EOI, because they are
always to priority = P and they are balanced. So we ignore them.
To summarize: an interrupt with priority P is going to be delivered, the
VCPU is running at TPR = P, interrupts are allowed, and the CR8
intercept is disabled.
The interrupt is injected via apic_set_irr/kvm_make_request, and this
causes a call to update_cr8_intercept. If TPR P, the intercept will
remain disabled. When the EOI is sent, we get another event and another
call to update_cr8_intercept; again, the intercept stays cleared because
IRR == -1.
If TPR == P, the intercept is set while the interrupt handler runs, but
it is still disabled at the end of the interrupt. Looks like another
bugfix; before your patch, it would remain enabled, which is useless.
The TPR == P case is actually interesting for Windows, more below.
The complicated sequences are:
3) a change in the TPR, where an interrupt is masked while the
high-priority task runs. The interrupt is what will cause the intercept
to be set. As soon as the TPR is restored, the interrupt will be
delivered and the intercept cleared (TPR IRR). We fall back to case 2
above.
4) interrupts that are received while interrupts are not allowed. Here
KVM does not inject the interrupt; it requests the interrupt window and
clears the intercept. Clearing the intercept is okay, because no
interrupt can be
[GIT PULL] KVM changes for 3.14-rc7
Linus, The following changes since commit 1b385cbdd74aa803e966e01e5fe49490d6044e30: kvm, vmx: Really fix lazy FPU on nested guest (2014-02-27 22:54:11 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to 596f3142d2b7be307a1652d59e7b93adab918437: KVM: SVM: fix cr8 intercept window (2014-03-12 18:21:10 +0100) The ARM patch fixes a build breakage with randconfig. The x86 one fixes Windows guests on AMD processors. Marc Zyngier (1): ARM: KVM: fix non-VGIC compilation Radim Krčmář (1): KVM: SVM: fix cr8 intercept window arch/x86/kvm/svm.c | 6 +++--- include/kvm/arm_vgic.h | 5 + 2 files changed, 8 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 3.13: BUG: soft lockup - CPU#1 stuck for 22s! [qemu-kvm:2653]
Hi Paolo, Hmm, the symptoms don't seem to match entirely -- I already am on a 64-bit kernel. I didn't recognize high CPU utilization, but I also admit I wasn't looking for it. Leaving the instance running doesn't eventually hang my system, but it did cause strange system behavior. Some apps would stall while launching, others that were already running would not be able to perform some operations. Nautilus, for example, couldn't render directory views and would display Loading... in the corner of the window. I assume this is because CPU1 is locked by KVM. Stopping the instance would allow any pending operations to complete; apps stuck launching all started at once, and Nautilus was again able to show me my local disk. I believe it also prevented clean shutdown. My keyboard's LEDs would stop responding and after allowing a reasonable amount of time, I reached for the reset button several times. I'll reinstall Linux 3.13 tonight and try to confirm these details. On Wed, Mar 12, 2014 at 7:08 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 11/03/2014 21:01, Jason S. Wagner ha scritto: Hi all, Over the weekend, Linux 3.13.6 was installed on my machine. When I started gnome-boxes on Monday morning, my VM halted during boot. Only a portion of the VESA BIOS init output was displayed on-screen before the halt. Backtraces occasionally appeared in dmesg (http://pastebin.com/uUiNLmJ6). Some other programs were prevented from performing some tasks while the VM was running. While investigating, I was directed to an earlier KVM bug report (https://lkml.org/lkml/2014/2/11/487). I downgraded to Linux 3.12.9 and rebooted, and now my VM is starting. Unfortunately, I'm very new to Linux, so I'm not sure what the next steps would be. Yeah, it's quite likely this is the issue you're facing. And the author of the report at http://www.spinics.net/lists/kvm/msg100196.html also told me privately that 64-bit kernel made it go away, so it's also likely to be the same thing. Thomas, do you also see a soft lockup message? Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [fix] kernel does not compile without CONFIG_KVM_ARM_VGIC
On Thu, Mar 06, 2014 at 03:30:46AM +, Marc Zyngier wrote:
Paolo, Michele,
On 2014-03-04 15:31, Paolo Bonzini wrote:
Il 04/03/2014 16:10, Michele Paolino ha scritto:
When the kernel is configured without CONFIG_KVM_ARM_VGIC, the
compilation process fails with :
arch/arm/kvm/arm.c: In function 'kvm_vm_ioctl_set_device_addr':
arch/arm/kvm/arm.c:797:3: error: implicit declaration of
function 'kvm_vgic_addr' [-Werror=implicit-function-declaration]
return kvm_vgic_addr(kvm, type, dev_addr-addr, true)
Signed-off-by: Michele Paolino m.paol...@virtualopensystems.com
---
include/kvm/arm_vgic.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index be85127..0bab057 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -143,8 +143,8 @@ struct kvm_vcpu;
struct kvm_run;
struct kvm_exit_mmio;
-#ifdef CONFIG_KVM_ARM_VGIC
int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64
*addr, bool write);
+#ifdef CONFIG_KVM_ARM_VGIC
int kvm_vgic_hyp_init(void);
int kvm_vgic_init(struct kvm *kvm);
int kvm_vgic_create(struct kvm *kvm);
Christoffer, Marc, I can queue this directly for kvm/master if
it's okay
for you.
This patch looks a bit wrong. Why would we need to configure the
vgic addresses if the vgic is explicitly disabled?
Furthermore, I doubt it leads to a kernel that actually links, as
the file containing kvm_vgic_addr will not be compiled...
Instead, please consider applying the attached patch (quickly tested
on a Cubietruck).
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
From 0876a7f6851e011b24f61ccbada35a5e8b898dd2 Mon Sep 17 00:00:00 2001
From: Marc Zyngier marc.zyng...@arm.com
Date: Thu, 6 Mar 2014 03:21:36 +
Subject: [PATCH] ARM: KVM: fix non-VGIC compilation
Add a stub for kvm_vgic_addr when compiling without
CONFIG_KVM_ARM_VGIC. The usefulness of this configurarion is extremely
doubtful, but let's fix it anyway (until we decide that we'll always
support a VGIC).
Reported-by: Michele Paolino m.paol...@virtualopensystems.com
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
include/kvm/arm_vgic.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index be85127..f27000f 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -171,6 +171,11 @@ static inline int kvm_vgic_set_addr(struct kvm *kvm,
unsigned long type, u64 add
return 0;
}
+static inline int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64
*addr, bool write)
+{
+ return -ENXIO;
+}
+
static inline int kvm_vgic_init(struct kvm *kvm)
{
return 0;
--
1.9.0
This looks right to me. I can queue this for the next -rc release.
Thanks,
-Christoffer
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [fix] kernel does not compile without CONFIG_KVM_ARM_VGIC
On Thu, Mar 06, 2014 at 03:30:46AM +, Marc Zyngier wrote:
Paolo, Michele,
On 2014-03-04 15:31, Paolo Bonzini wrote:
Il 04/03/2014 16:10, Michele Paolino ha scritto:
When the kernel is configured without CONFIG_KVM_ARM_VGIC, the
compilation process fails with :
arch/arm/kvm/arm.c: In function 'kvm_vm_ioctl_set_device_addr':
arch/arm/kvm/arm.c:797:3: error: implicit declaration of
function 'kvm_vgic_addr' [-Werror=implicit-function-declaration]
return kvm_vgic_addr(kvm, type, dev_addr-addr, true)
Signed-off-by: Michele Paolino m.paol...@virtualopensystems.com
---
include/kvm/arm_vgic.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index be85127..0bab057 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -143,8 +143,8 @@ struct kvm_vcpu;
struct kvm_run;
struct kvm_exit_mmio;
-#ifdef CONFIG_KVM_ARM_VGIC
int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64
*addr, bool write);
+#ifdef CONFIG_KVM_ARM_VGIC
int kvm_vgic_hyp_init(void);
int kvm_vgic_init(struct kvm *kvm);
int kvm_vgic_create(struct kvm *kvm);
Christoffer, Marc, I can queue this directly for kvm/master if
it's okay
for you.
This patch looks a bit wrong. Why would we need to configure the
vgic addresses if the vgic is explicitly disabled?
Furthermore, I doubt it leads to a kernel that actually links, as
the file containing kvm_vgic_addr will not be compiled...
Instead, please consider applying the attached patch (quickly tested
on a Cubietruck).
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
From 0876a7f6851e011b24f61ccbada35a5e8b898dd2 Mon Sep 17 00:00:00 2001
From: Marc Zyngier marc.zyng...@arm.com
Date: Thu, 6 Mar 2014 03:21:36 +
Subject: [PATCH] ARM: KVM: fix non-VGIC compilation
Add a stub for kvm_vgic_addr when compiling without
CONFIG_KVM_ARM_VGIC. The usefulness of this configurarion is extremely
doubtful, but let's fix it anyway (until we decide that we'll always
support a VGIC).
Reported-by: Michele Paolino m.paol...@virtualopensystems.com
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
include/kvm/arm_vgic.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index be85127..f27000f 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -171,6 +171,11 @@ static inline int kvm_vgic_set_addr(struct kvm *kvm,
unsigned long type, u64 add
return 0;
}
+static inline int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64
*addr, bool write)
+{
+ return -ENXIO;
+}
+
static inline int kvm_vgic_init(struct kvm *kvm)
{
return 0;
--
1.9.0
Ah, never mind, it was already applied. Thanks Paolo.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/52] arm, kvm: Fix CPU hotplug callback registration
On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(foobar_cpu_notifier);
cpu_notifier_register_done();
Fix the kvm code in arm by using this latter form of callback registration.
Cc: Christoffer Dall christoffer.d...@linaro.org
Cc: Gleb Natapov g...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Ingo Molnar mi...@kernel.org
Cc: kvm...@lists.cs.columbia.edu
Cc: kvm@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
arch/arm/kvm/arm.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index bd18bb8..f0e50a0 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1051,21 +1051,26 @@ int kvm_arch_init(void *opaque)
}
}
+ cpu_notifier_register_begin();
+
err = init_hyp_mode();
if (err)
goto out_err;
- err = register_cpu_notifier(hyp_init_cpu_nb);
+ err = __register_cpu_notifier(hyp_init_cpu_nb);
if (err) {
kvm_err(Cannot register HYP init CPU notifier (%d)\n, err);
goto out_err;
}
+ cpu_notifier_register_done();
+
hyp_cpu_pm_init();
kvm_coproc_table_init();
return 0;
out_err:
+ cpu_notifier_register_done();
return err;
}
Just so we're clear, the existing code was simply racy as not prone to
deadlocks, right?
This makes it clear that the test above for compatible CPUs can be quite
easily evaded by using CPU hotplug, but we don't really have a good
solution for handling that yet... Hmmm, grumble grumble, I guess if you
hotplug unsupported CPUs on a KVM/ARM system for now, stuff will break.
In any case:
Acked-by: Christoffer Dall christoffer.d...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL for-2.0-rc0 1/6] Revert KVM: Split QEMUMachine typedef into separate header
This reverts commit 9c06a1f79f959fffd09bfb7efc3d76051a6cd2da.
The new header sysemu/qemumachine.h is undesired.
Suggested-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
include/hw/boards.h | 3 ++-
include/hw/xen/xen.h | 1 -
include/sysemu/kvm.h | 1 -
include/sysemu/qemumachine.h | 16
include/sysemu/qtest.h | 1 -
kvm-stub.c | 1 -
6 files changed, 2 insertions(+), 21 deletions(-)
delete mode 100644 include/sysemu/qemumachine.h
diff --git a/include/hw/boards.h b/include/hw/boards.h
index c2096e6..89eb665 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -4,9 +4,10 @@
#define HW_BOARDS_H
#include sysemu/blockdev.h
-#include sysemu/qemumachine.h
#include hw/qdev.h
+typedef struct QEMUMachine QEMUMachine;
+
typedef struct QEMUMachineInitArgs {
const QEMUMachine *machine;
ram_addr_t ram_size;
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index e181821..9d549fc 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -10,7 +10,6 @@
#include hw/irq.h
#include qemu-common.h
-#include sysemu/qemumachine.h
/* xen-machine.c */
enum xen_mode {
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index ed01998..0bee1e8 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -18,7 +18,6 @@
#include config-host.h
#include qemu/queue.h
#include qom/cpu.h
-#include sysemu/qemumachine.h
#ifdef CONFIG_KVM
#include linux/kvm.h
diff --git a/include/sysemu/qemumachine.h b/include/sysemu/qemumachine.h
deleted file mode 100644
index 4cefd56..000
--- a/include/sysemu/qemumachine.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/*
- * QEMU Machine typedef
- *
- * Copyright Alexander Graf ag...@suse.de
- *
- * This work is licensed under the terms of the GNU GPL, version 2 or later.
- * See the COPYING file in the top-level directory.
- *
- */
-
-#ifndef QEMUMACHINE_H
-#define QEMUMACHINE_H
-
-typedef struct QEMUMachine QEMUMachine;
-
-#endif /* !QEMUMACHINE_H */
diff --git a/include/sysemu/qtest.h b/include/sysemu/qtest.h
index e62281d..224131f 100644
--- a/include/sysemu/qtest.h
+++ b/include/sysemu/qtest.h
@@ -16,7 +16,6 @@
#include qemu-common.h
#include qapi/error.h
-#include sysemu/qemumachine.h
extern bool qtest_allowed;
diff --git a/kvm-stub.c b/kvm-stub.c
index 4ef084e..ccdba62 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -14,7 +14,6 @@
#include hw/hw.h
#include cpu.h
#include sysemu/kvm.h
-#include sysemu/qemumachine.h
#ifndef CONFIG_USER_ONLY
#include hw/pci/msi.h
--
1.8.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] bridge: trigger a bridge calculation upon port changes
From: Luis R. Rodriguez mcg...@suse.com
If netlink is used to tune a port we currently don't trigger a
new recalculation of the bridge id, ensure that happens just as
if we're adding a new net_device onto the bridge.
Cc: Stephen Hemminger step...@networkplumber.org
Cc: bri...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: kvm@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
net/bridge/br_netlink.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index e74b6d53..6f1b26d 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -364,6 +364,7 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
struct net_bridge_port *p;
struct nlattr *tb[IFLA_BRPORT_MAX + 1];
int err = 0;
+ bool changed;
protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
IFLA_PROTINFO);
afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
@@ -386,7 +387,12 @@ int br_setlink(struct net_device *dev, struct nlmsghdr
*nlh)
spin_lock_bh(p-br-lock);
err = br_setport(p, tb);
+ changed = br_stp_recalculate_bridge_id(p-br);
spin_unlock_bh(p-br-lock);
+ if (changed)
+ call_netdevice_notifiers(NETDEV_CHANGEADDR,
+p-br-dev);
+ netdev_update_features(p-br-dev);
} else {
/* Binary compatibility with old RSTP */
if (nla_len(protinfo) sizeof(u8))
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] bridge: preserve random init MAC address
From: Luis R. Rodriguez mcg...@suse.com As it is now if you add create a bridge it gets started with a random MAC address and if you then add a net_device as a slave but later kick it out you end up with a zero MAC address. Instead preserve the original random MAC address and use it. If you manually set the bridge address that will always be respected. This change only takes effect if at the time of computing the new root port we determine we have found no candidates. Cc: Stephen Hemminger step...@networkplumber.org Cc: bri...@lists.linux-foundation.org Cc: net...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: xen-de...@lists.xenproject.org Cc: kvm@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- net/bridge/br_device.c | 1 + net/bridge/br_private.h | 1 + net/bridge/br_stp_if.c | 3 +++ 3 files changed, 5 insertions(+) diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c index b063050..5f13eac 100644 --- a/net/bridge/br_device.c +++ b/net/bridge/br_device.c @@ -368,6 +368,7 @@ void br_dev_setup(struct net_device *dev) br-bridge_id.prio[1] = 0x00; ether_addr_copy(br-group_addr, eth_reserved_addr_base); + ether_addr_copy(br-random_init_addr, dev-dev_addr); br-stp_enabled = BR_NO_STP; br-group_fwd_mask = BR_GROUPFWD_DEFAULT; diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h index e1ca1dc..32a06da 100644 --- a/net/bridge/br_private.h +++ b/net/bridge/br_private.h @@ -240,6 +240,7 @@ struct net_bridge unsigned long bridge_hello_time; unsigned long bridge_forward_delay; + u8 random_init_addr[ETH_ALEN]; u8 group_addr[ETH_ALEN]; u16 root_port; diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c index 189ba1e..4c9ad45 100644 --- a/net/bridge/br_stp_if.c +++ b/net/bridge/br_stp_if.c @@ -239,6 +239,9 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br) if (ether_addr_equal(br-bridge_id.addr, addr)) return false; /* no change */ + if (ether_addr_equal(addr, br_mac_zero)) + addr = br-random_init_addr; + br_stp_change_bridge_id(br, addr); return true; } -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] bridge: fix bridge root block on designated port
From: Luis R. Rodriguez mcg...@suse.com
Root port blocking was designed so that a bridge port can opt
out of becoming the designated root port for a bridge. If a port
however first becomes the designated root port and we then toggle
the root port block on it we currently don't kick that port out of
the designated root port. This fixes that. This is particularly
important for net_devices that would wish to never become a root
port from the start, currently toggling that off will enable root
port flag but it won't really kick the bridge and do what you'd
expect, the MAC address is kept on the bridge of the toggled port
for root_block if it was the designated port.
In order to catch if a port with root port block preference is set
we need to move our check for root block prior to the root selection
so check for root blocked ports upon eveyr br_configuration_update().
We also simply just prevent the root-blocked ports from consideration
as root port candidates on br_should_become_root_port() and
br_stp_recalculate_bridge_id().
The issue that this patch is trying to address and fix can be tested
easily before and after this patch is applied using 2 TAP net_devices
and then toggling at will with the root_block knob.
ip tuntap add dev tap0 mode tap
ip tuntap add dev tap1 mode tap
ip link add dev br0 type bridge
ip link show br0
echo ---
ip link set dev tap0 master br0
ip link
echo ---
ip link set dev tap1 master br0
ip link
echo ---
Upon review at the above results you can toggle root_block
on each port to see if you see the results you expect.
bridge link set dev tap0 root_block on
ip link
bridge link set dev tap1 root_block on
ip link
Toggling off root_block on any port should will bring back the
port to be a candidate for designated root port:
bridge link set dev tap1 root_block off
ip link
bridge link set dev tap0 root_block off
ip link
To nuke:
ip tuntap del tap0 mode tap
ip tuntap del tap0 mode tap
Cc: Stephen Hemminger step...@networkplumber.org
Cc: bri...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: kvm@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
net/bridge/br_netlink.c | 18
net/bridge/br_private.h | 1 +
net/bridge/br_stp.c | 73 +
net/bridge/br_stp_if.c | 3 +-
4 files changed, 88 insertions(+), 7 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 6f1b26d..fbec354 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -324,6 +324,21 @@ static void br_set_port_flag(struct net_bridge_port *p,
struct nlattr *tb[],
}
}
+static void br_kick_bridge_port(struct net_bridge_port *p)
+{
+ struct net_bridge *br = p-br;
+ bool wasroot;
+
+ wasroot = br_is_root_bridge(br);
+ br_become_designated_port(p);
+
+ br_configuration_update(br);
+ br_port_state_selection(br);
+
+ if (br_is_root_bridge(br) !wasroot)
+ br_become_root_bridge(br);
+}
+
/* Process bridge protocol info on port */
static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
{
@@ -353,6 +368,9 @@ static int br_setport(struct net_bridge_port *p, struct
nlattr *tb[])
if (err)
return err;
}
+
+ br_kick_bridge_port(p);
+
return 0;
}
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 32a06da..45d7917 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -150,6 +150,7 @@ struct net_bridge_port
u8 priority;
u8 state;
u16 port_no;
+ boolroot_block_enabled;
unsigned char topology_change_ack;
unsigned char config_pending;
port_id port_id;
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index 3c86f05..f5741f3 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -59,6 +59,7 @@ static int br_should_become_root_port(const struct
net_bridge_port *p,
br = p-br;
if (p-state == BR_STATE_DISABLED ||
+ (p-flags BR_ROOT_BLOCK) ||
br_is_designated_port(p))
return 0;
@@ -104,7 +105,7 @@ static void br_root_port_block(const struct net_bridge *br,
struct net_bridge_port *p)
{
- br_notice(br, port %u(%s) tried to become root port (blocked),
+ br_notice(br, port %u (%s) is now root blocked,
(unsigned int) p-port_no, p-dev-name);
p-state = BR_STATE_LISTENING;
@@ -124,11 +125,7 @@ static void br_root_selection(struct net_bridge *br)
list_for_each_entry(p, br-port_list, list)
[PATCH 0/3] bridge: few enhancements and small fixes
Here's a few fixes I've been carrying around. I've now tested them on as many systems / environments as I can. They should be ready. Luis R. Rodriguez (3): bridge: preserve random init MAC address bridge: trigger a bridge calculation upon port changes bridge: fix bridge root block on designated port net/bridge/br_device.c | 1 + net/bridge/br_netlink.c | 24 net/bridge/br_private.h | 2 ++ net/bridge/br_stp.c | 73 + net/bridge/br_stp_if.c | 6 +++- 5 files changed, 99 insertions(+), 7 deletions(-) -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
