Found during documenting mmu_lock usage for myself.
Takuya Yoshikawa (3):
KVM: MMU: Clean up set_spte()'s ACC_WRITE_MASK handling
KVM: MMU: Use kvm_mmu_sync_roots() in kvm_mmu_load()
KVM: MMU: Consolidate common code in mmu_free_roots()
arch/x86/kvm/mmu.c | 48
Rather than clearing the ACC_WRITE_MASK bit of pte_access in the
if (mmu_need_write_protect()) block not to call mark_page_dirty() in
the following if statement, simply moving the call into the appropriate
else block is better.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
No need to open-code this function.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
arch/x86/kvm/mmu.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 08119a8..d01f340 100644
--- a/arch/x86/kvm/mmu.c
By making the last three statements common to both if/else cases, the
symmetry between the locking and unlocking becomes clearer. One note
here is that VCPU's root_hpa does not need to be protected by mmu_lock.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Caraman
Mihai Claudiu-B02008
Sent: Wednesday, May 08, 2013 6:44 PM
To: Wood Scott-B07421; tiejun.chen
On 05/09/2013 03:51 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, May 09, 2013 1:18 PM
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org;
On Thu, May 09, 2013 at 07:51:09AM +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, May 09, 2013 1:18 PM
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
On 05/09/2013 04:12 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Kevin Hao [mailto:haoke...@gmail.com]
Sent: Thursday, May 09, 2013 1:38 PM
To: Bhushan Bharat-R65777
Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood Scott-
B07421; ag...@suse.de;
On Thu, May 09, 2013 at 08:12:51AM +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Kevin Hao [mailto:haoke...@gmail.com]
Sent: Thursday, May 09, 2013 1:38 PM
To: Bhushan Bharat-R65777
Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 40
1 file changed, 40 insertions(+)
diff --git a/x86/realmode.c b/x86/realmode.c
index 91c93a9..35ace08 100644
--- a/x86/realmode.c
+++ b/x86/realmode.c
@@ -1391,6 +1391,43 @@ static
Il 08/05/2013 14:25, Vladimir ha scritto:
Here they are:
(qemu) x/8i $pc
0x000fc49b: lgdtw %cs:-0x2c60
Hi, this is the same problem as
http://article.gmane.org/gmane.comp.emulators.kvm.devel/109527 -- the
fix is on its way to the next stable kernel.
Thanks for your patience!
On Thu, May 09, 2013 at 10:53:37AM +0200, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 40
1 file changed, 40 insertions(+)
diff --git a/x86/realmode.c b/x86/realmode.c
index 91c93a9..35ace08 100644
Il 09/05/2013 11:13, Gleb Natapov ha scritto:
On Thu, May 09, 2013 at 10:53:37AM +0200, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 40
1 file changed, 40 insertions(+)
diff --git a/x86/realmode.c
On Thu, May 09, 2013 at 11:18:07AM +0200, Paolo Bonzini wrote:
Il 09/05/2013 11:13, Gleb Natapov ha scritto:
On Thu, May 09, 2013 at 10:53:37AM +0200, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 40
These three instructions are not emulated, but can be found in
real mode code.
These are also good for stable, but they conflict before 3.9 and are
not really useful since emulate_invalid_guest_state defaulted to false.
So I'm not marking them for earlier releases.
Paolo Bonzini (3):
KVM:
These three instructions are not emulated, but can be found in
real mode code.
These are also good for stable, but they conflict before 3.9 and are
not really useful since emulate_invalid_guest_state defaulted to false.
So I'm not marking them for earlier releases.
Paolo Bonzini (3):
KVM:
On 05/09/2013 04:23 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Caraman
Mihai Claudiu-B02008
Sent: Wednesday, May 08, 2013 6:44 PM
To: Wood Scott-B07421; tiejun.chen
On Thu, May 09, 2013 at 11:32:50AM +0200, Paolo Bonzini wrote:
This is used by SGABIOS, KVM breaks with emulate_invalid_guest_state=1.
It is just a MOV in disguise, with a funny source address.
Reported-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Cc: sta...@vger.kernel.org # 3.9
On 05/09/2013 02:46 PM, Takuya Yoshikawa wrote:
By making the last three statements common to both if/else cases, the
symmetry between the locking and unlocking becomes clearer. One note
here is that VCPU's root_hpa does not need to be protected by mmu_lock.
Signed-off-by: Takuya Yoshikawa
On 05/09/2013 06:00 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, May 09, 2013 3:15 PM
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org;
On 05/09/2013 02:44 PM, Takuya Yoshikawa wrote:
Rather than clearing the ACC_WRITE_MASK bit of pte_access in the
if (mmu_need_write_protect()) block not to call mark_page_dirty() in
the following if statement, simply moving the call into the appropriate
else block is better.
Signed-off-by:
On 05/09/2013 02:45 PM, Takuya Yoshikawa wrote:
No need to open-code this function.
Signed-off-by: Takuya Yoshikawa yoshikawa_takuya...@lab.ntt.co.jp
---
arch/x86/kvm/mmu.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
On 05/08/2013 05:28 PM, tiejun.chen wrote:
On 05/08/2013 05:20 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of tiejun.chen
Sent: Wednesday, May 08, 2013 4:54 AM
To: Wood Scott-B07421
Cc:
On Thu, May 09, 2013 at 06:16:55PM +0800, Xiao Guangrong wrote:
On 05/09/2013 02:44 PM, Takuya Yoshikawa wrote:
Rather than clearing the ACC_WRITE_MASK bit of pte_access in the
if (mmu_need_write_protect()) block not to call mark_page_dirty() in
the following if statement, simply moving the
On 05/09/2013 07:21 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, May 09, 2013 3:48 PM
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org;
Il 09/05/2013 12:03, Gleb Natapov ha scritto:
On Thu, May 09, 2013 at 11:32:50AM +0200, Paolo Bonzini wrote:
This is used by SGABIOS, KVM breaks with emulate_invalid_guest_state=1.
It is just a MOV in disguise, with a funny source address.
Reported-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
On 05/09/2013 07:34 PM, Caraman Mihai Claudiu-B02008 wrote:
VF stands for virtualization fault see MAS8[VF] and we may use it for
virtualized
Looks KVM PPC have no this mechanism currently since I don't find MAS8_VF
is
used in kernel, right?
Yes but 'we may use it' in the feature, I have a
On Thu, May 09, 2013 at 10:53:37AM +0200, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Applied, thanks.
---
x86/realmode.c | 40
1 file changed, 40 insertions(+)
diff --git a/x86/realmode.c b/x86/realmode.c
index
On Thu, May 09, 2013 at 11:32:48AM +0200, Paolo Bonzini wrote:
These three instructions are not emulated, but can be found in
real mode code.
These are also good for stable, but they conflict before 3.9 and are
not really useful since emulate_invalid_guest_state defaulted to false.
So I'm
On 05/09/2013 07:18 PM, Gleb Natapov wrote:
On Thu, May 09, 2013 at 06:16:55PM +0800, Xiao Guangrong wrote:
On 05/09/2013 02:44 PM, Takuya Yoshikawa wrote:
Rather than clearing the ACC_WRITE_MASK bit of pte_access in the
if (mmu_need_write_protect()) block not to call mark_page_dirty() in
the
On Thu, 2013-05-09 at 16:21 +0800, Kevin Hao wrote:
Is it because that we cannot afford to lose perfmon interrupt for
more accurate capturing of data ?
Yes, I think this will definitely improve the perf sample quality.
This is one of the primary reason why we implemented lazy disabling in
On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I
recall.
Only if directed to the hypervisor.
Case 1)
- Local_irq_disable() will set soft_enabled = 0
- Now Externel interrupt happens, there we set
CC kvm list.
On 05/09/2013 12:31 PM, David Ahern wrote:
With the consolidation of the open counters code in December 2012
(late to the party figuring that out) I think all of the past
comments on the live mode for perf-kvm have been resolved.
Great work, David! I am playing it and glad to see
Some MPIC implementations tend to generate a spurrious IRQ in the case
of level IRQs going away. IE. they still remember an event occurred and
interrupt the processor, but on IACK return the spurious vector. However
that isn't guaranteed to be the case and it is perfectly ok (and a good
idea)
Linus,
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.10-2
to receive the KVM fixes for the 3.10 merge window. Most of the fixes
are in the emulator since now we emulate more than we did before for
correctness sake we see more bugs there, but there is also an OOPS
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Thursday, May 09, 2013 8:38 PM
To: Chen, Tiejun
Cc: Bhushan Bharat-R65777; Caraman Mihai Claudiu-B02008; Wood
Scott-B07421; linuxppc-...@lists.ozlabs.org; ag...@suse.de;
The realmode test is compiled in 16-bit mode, hence it uses a
cut-and-pasted version of the mini C library and is still printing
to the old debug port at 0xf1. Use the serial port instead.
Paolo Bonzini (2):
realmode: restore DF at exit from exec_in_big_real_mode
realmode: print to serial
Some tests fail if DF=1. Restore it directly after executing the test,
do not do it magically in print_serial.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/x86/realmode.c b/x86/realmode.c
index
The realmode test is still printing to the old debug port at 0xf1.
Use the serial port instead.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 65 --
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git
On Thu, May 09, 2013 at 04:23:34PM +0200, Paolo Bonzini wrote:
The realmode test is still printing to the old debug port at 0xf1.
Use the serial port instead.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 65
Automatic ballooning consists of dynamically adjusting the guest's
balloon according to memory pressure in the host and in the guest.
This commit implements the host side of automatic balloning, which
basically consists of:
1. Registering with the memory.pressure_level API (from the
Linux
Hi,
This series is a respin of automatic ballooning support I started
working on last year. Patch 2/2 contains all relevant technical
details and performance measurements results.
This is in RFC state because it's a work in progress.
Here's some information if you want to try automatic
Automatic ballooning consists of dynamically adjusting the guest's
balloon according to memory pressure in the host and in the guest.
This commit implements the guest side of automatic balloning, which
basically consists of registering a shrinker callback with the kernel,
which will try to
This commit moves the balloon_lock mutex out of the fill_balloon()
and leak_balloon() functions to their callers.
The reason for this change is that the next commit will introduce
a shrinker callback for the balloon driver, which will also call
leak_balloon() but will require different locking
The realmode test is compiled in 16-bit mode, hence it uses a
cut-and-pasted version of the mini C library and is still printing
to the old debug port at 0xf1. Use the serial port instead.
v1-v2: set serial_inited, both in the original and the copied code [Gleb]
Paolo Bonzini (3):
realmode:
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
lib/x86/io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/x86/io.c b/lib/x86/io.c
index 0282888..d3b971e 100644
--- a/lib/x86/io.c
+++ b/lib/x86/io.c
@@ -46,6 +46,7 @@ static void print_serial(const char *buf)
unsigned long
Some tests fail if DF=1. Restore it directly after executing the test,
do not do it magically in print_serial.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/x86/realmode.c b/x86/realmode.c
index
The realmode test is still printing to the old debug port at 0xf1.
Use the serial port instead.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
x86/realmode.c | 66 --
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git
On Thu, May 09, 2013 at 04:55:02PM +0200, Paolo Bonzini wrote:
The realmode test is compiled in 16-bit mode, hence it uses a
cut-and-pasted version of the mini C library and is still printing
to the old debug port at 0xf1. Use the serial port instead.
v1-v2: set serial_inited, both in the
On Fri, May 03, 2013 at 03:02:52PM +0100, Marc Zyngier wrote:
As KVM/arm64 is looming on the horizon, it makes sense to move some
of the common code to a single location in order to reduce duplication.
The code could live anywhere. Actually, most of KVM is already built
with a bunch of ugly
On Thu, May 09, 2013 at 10:53:48AM -0400, Luiz Capitulino wrote:
This commit moves the balloon_lock mutex out of the fill_balloon()
and leak_balloon() functions to their callers.
The reason for this change is that the next commit will introduce
a shrinker callback for the balloon driver,
On Thu, May 09, 2013 at 10:53:49AM -0400, Luiz Capitulino wrote:
Automatic ballooning consists of dynamically adjusting the guest's
balloon according to memory pressure in the host and in the guest.
This commit implements the guest side of automatic balloning, which
basically consists of
On Thu, 2013-05-09 at 14:28 +0100, David Laight wrote:
That will happen if the IRQ goes away while the cpu is performing
the IACK sequence.
If the IRQ goes away while the cpu has interrupts masked then
the cpu won't start the interrupt sequence and then try to
read a vector when no interrupt
On Thu, 2013-05-09 at 16:27 -0500, Scott Wood wrote:
On 05/09/2013 07:37:42 AM, Benjamin Herrenschmidt wrote:
On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur
as I
recall.
Only if directed to the
kvmclock updates which are isolated to a given vcpu, such as vcpu-cpu
migration, should not allow system_timestamp from the rest of the vcpus
to remain static. Otherwise ntp frequency correction applies to one
vcpu's system_timestamp but not the others.
So in those cases, request a kvmclock
On Thu, 09 May 2013 18:11:31 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
On 05/09/2013 02:46 PM, Takuya Yoshikawa wrote:
By making the last three statements common to both if/else cases, the
symmetry between the locking and unlocking becomes clearer. One note
here is that
On Thu, 09 May 2013 20:16:18 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
That function is really magic, and this change do no really help it. I had
several
patches posted some months ago to make these kind of code better
understanding, but
i am too tired to update
On 05/10/2013 09:05 AM, Takuya Yoshikawa wrote:
On Thu, 09 May 2013 18:11:31 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
On 05/09/2013 02:46 PM, Takuya Yoshikawa wrote:
By making the last three statements common to both if/else cases, the
symmetry between the locking and
On 05/07/13 18:55, Jun'ichi Nomura wrote:
With v3.9 kernel and Nehalem CPU (i.e. unrestricted_guest=N),
a guest stuck during boot (seemingly in BIOS).
When setting emulate_invalid_guest_state=0, it does boot.
(With v3.8 kernel and older, the guest used to boot fine by default.)
The
EE is hard-disabled on entry to kvmppc_handle_exit(), so call
hard_irq_disable() so that PACA_IRQ_HARD_DIS is set, and soft_enabled
is unset.
Without this, we get warnings such as arch/powerpc/kernel/time.c:300,
and sometimes host kernel hangs.
Signed-off-by: Scott Wood scottw...@freescale.com
Simplify the handling of lazy EE by going directly from fully-enabled
to hard-disabled. This replaces the lazy_irq_pending() check
(including its misplaced kvm_guest_exit() call).
As suggested by Tiejun Chen, move the interrupt disabling into
kvmppc_prepare_to_enter() rather than have each
v2:
- Split into separate changes
- Rebase on top of (and fix a bug in) powerpc: Make hard_irq_disable()
do the right thing vs. irq tracing
- Move interrupt diasbling/enabling into kvmppc_handle_exit
Based on Ben's next branch.
Scott Wood (4):
powerpc: hard_irq_disable(): Call
Currently this is only being done on 64-bit. Rather than just move it
out of the 64-bit ifdef, move it to kvm_lazy_ee_enable() so that it is
consistent with lazy ee state, and so that we don't track more host
code as interrupts-enabled than necessary.
Rename kvm_lazy_ee_enable() to
lockdep.c has this:
/*
* So we're supposed to get called after you mask local IRQs,
* but for some reason the hardware doesn't quite think you did
* a proper job.
*/
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
return;
Since
BookE altivec support brought two new exceptions, but KVM was not
updated, so the build broke for all 64-bit booke with KVM enabled.
Add the new vectors, but there's more than this required to make
Altivec work in the guest, and we can't prevent the guest from turning
on Altivec (which can
On 05/10/2013 11:34 AM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of
Scott Wood
Sent: Friday, May 10, 2013 8:40 AM
To: Alexander Graf; Benjamin Herrenschmidt
Cc: kvm-...@vger.kernel.org;
On Wed, May 08, 2013 at 11:15:32AM +0800, Hu Tao wrote:
pvpanic device is a qemu simulated device through which guest panic
event is sent to host.
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
v18 - v19: 1. return -ENODEV early if port is 0
v17 - v18: 1. call acpi_walk_resources to
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of Scott Wood
Sent: Friday, May 10, 2013 8:40 AM
To: Alexander Graf; Benjamin Herrenschmidt
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org;
linuxppc-...@lists.ozlabs.org;
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of Scott Wood
Sent: Friday, May 10, 2013 8:40 AM
To: Alexander Graf; Benjamin Herrenschmidt
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org;
linuxppc-...@lists.ozlabs.org;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 4e05f8c..f8659aa 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -64,12 +64,14 @@ int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu)
{
int r = 1;
-
On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Caraman
Mihai Claudiu-B02008
Sent: Wednesday, May 08, 2013 6:44 PM
To: Wood Scott-B07421; tiejun.chen
On 05/09/2013 03:51 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, May 09, 2013 1:18 PM
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org;
On Thu, May 09, 2013 at 07:51:09AM +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, May 09, 2013 1:18 PM
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
On 05/09/2013 04:12 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Kevin Hao [mailto:haoke...@gmail.com]
Sent: Thursday, May 09, 2013 1:38 PM
To: Bhushan Bharat-R65777
Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; k...@vger.kernel.org; Wood Scott-
B07421; ag...@suse.de;
On Thu, May 09, 2013 at 08:12:51AM +, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Kevin Hao [mailto:haoke...@gmail.com]
Sent: Thursday, May 09, 2013 1:38 PM
To: Bhushan Bharat-R65777
Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; k...@vger.kernel.org; Wood
On 05/09/2013 04:23 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Caraman
Mihai Claudiu-B02008
Sent: Wednesday, May 08, 2013 6:44 PM
To: Wood Scott-B07421; tiejun.chen
On 05/08/2013 05:28 PM, tiejun.chen wrote:
On 05/08/2013 05:20 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of tiejun.chen
Sent: Wednesday, May 08, 2013 4:54 AM
To: Wood Scott-B07421
Cc:
On 05/09/2013 07:21 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: tiejun.chen [mailto:tiejun.c...@windriver.com]
Sent: Thursday, May 09, 2013 3:48 PM
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org;
On 05/09/2013 07:34 PM, Caraman Mihai Claudiu-B02008 wrote:
VF stands for virtualization fault see MAS8[VF] and we may use it for
virtualized
Looks KVM PPC have no this mechanism currently since I don't find MAS8_VF
is
used in kernel, right?
Yes but 'we may use it' in the feature, I have a
On Thu, 2013-05-09 at 16:21 +0800, Kevin Hao wrote:
Is it because that we cannot afford to lose perfmon interrupt for
more accurate capturing of data ?
Yes, I think this will definitely improve the perf sample quality.
This is one of the primary reason why we implemented lazy disabling in
On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I
recall.
Only if directed to the hypervisor.
Case 1)
- Local_irq_disable() will set soft_enabled = 0
- Now Externel interrupt happens, there we set
Some MPIC implementations tend to generate a spurrious IRQ in the case
of level IRQs going away. IE. they still remember an event occurred and
interrupt the processor, but on IACK return the spurious vector. However
that isn't guaranteed to be the case and it is perfectly ok (and a good
idea)
On Thu, 2013-05-09 at 14:28 +0100, David Laight wrote:
That will happen if the IRQ goes away while the cpu is performing
the IACK sequence.
If the IRQ goes away while the cpu has interrupts masked then
the cpu won't start the interrupt sequence and then try to
read a vector when no interrupt
On Thu, 2013-05-09 at 16:27 -0500, Scott Wood wrote:
On 05/09/2013 07:37:42 AM, Benjamin Herrenschmidt wrote:
On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur
as I
recall.
Only if directed to the
EE is hard-disabled on entry to kvmppc_handle_exit(), so call
hard_irq_disable() so that PACA_IRQ_HARD_DIS is set, and soft_enabled
is unset.
Without this, we get warnings such as arch/powerpc/kernel/time.c:300,
and sometimes host kernel hangs.
Signed-off-by: Scott Wood scottw...@freescale.com
Simplify the handling of lazy EE by going directly from fully-enabled
to hard-disabled. This replaces the lazy_irq_pending() check
(including its misplaced kvm_guest_exit() call).
As suggested by Tiejun Chen, move the interrupt disabling into
kvmppc_prepare_to_enter() rather than have each
v2:
- Split into separate changes
- Rebase on top of (and fix a bug in) powerpc: Make hard_irq_disable()
do the right thing vs. irq tracing
- Move interrupt diasbling/enabling into kvmppc_handle_exit
Based on Ben's next branch.
Scott Wood (4):
powerpc: hard_irq_disable(): Call
lockdep.c has this:
/*
* So we're supposed to get called after you mask local IRQs,
* but for some reason the hardware doesn't quite think you did
* a proper job.
*/
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
return;
Since
Currently this is only being done on 64-bit. Rather than just move it
out of the 64-bit ifdef, move it to kvm_lazy_ee_enable() so that it is
consistent with lazy ee state, and so that we don't track more host
code as interrupts-enabled than necessary.
Rename kvm_lazy_ee_enable() to
BookE altivec support brought two new exceptions, but KVM was not
updated, so the build broke for all 64-bit booke with KVM enabled.
Add the new vectors, but there's more than this required to make
Altivec work in the guest, and we can't prevent the guest from turning
on Altivec (which can
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf
Of
Scott Wood
Sent: Friday, May 10, 2013 8:40 AM
To: Alexander Graf; Benjamin Herrenschmidt
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org;
linuxppc-...@lists.ozlabs.org;
Wood
On 05/10/2013 11:34 AM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of
Scott Wood
Sent: Friday, May 10, 2013 8:40 AM
To: Alexander Graf; Benjamin Herrenschmidt
Cc: kvm-ppc@vger.kernel.org;
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of Scott Wood
Sent: Friday, May 10, 2013 8:40 AM
To: Alexander Graf; Benjamin Herrenschmidt
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org;
linuxppc-...@lists.ozlabs.org;
93 matches
Mail list logo
