The last one is an RFC patch:
I think it is better to refactor the rmap things, if needed, before
other architectures than x86 starts large pages support.
Takuya
arch/ia64/kvm/kvm-ia64.c|8
arch/powerpc/kvm/book3s_64_mmu_hv.c |6 +++---
We want to eliminate direct access to the rmap array.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/mmu_audit.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu_audit.c b/arch/x86/kvm/mmu_audit.c
index 6eabae3..e62fa4f
We can hide the implementation details and treat every level uniformly.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/mmu.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index
Though we have one rmap array for every level, those for large pages,
called rmap_pde, are coupled with write_count information and constitute
lpage_info arrays.
To hide this implementation details, we are now using __gfn_to_rmap()
which includes likely(level == PT_PAGE_TABLE_LEVEL) heuristics;
On Thu, Jan 19, 2012 at 10:22:41PM -0500, Christoffer Dall wrote:
The kvm_vcpu_kick function performs roughly the same funcitonality on
most all architectures, so we shouldn't have separate copies.
PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch
structure and to
On Mon, Jan 23, 2012 at 07:42:04PM +0900, Takuya Yoshikawa wrote:
The last one is an RFC patch:
I think it is better to refactor the rmap things, if needed, before
other architectures than x86 starts large pages support.
Takuya
Looks good to me.
--
To unsubscribe from this list:
