On Wed, 2007-05-30 at 08:01 +0300, Avi Kivity wrote:
Rusty Russell wrote:
but it's not clear to me that verifying PTEs is that
much faster than shadowing them if you're prepared to be that invasive
in the guest anyway.
This can probably be measured on Xen which can switch from direct
Avi Kivity wrote:
On a pte update, npte will always be 1. On a pde update, we won't do
anything in mmu_pte_write_new_pte because it doesn't handle
pdes. If we
extend it to handle pdes, then we need either to modify the
new gpde or
to have the update take the quadrant into account.
Agree,
Avi Kivity wrote:
Dong, Eddie wrote:
Avi Kivity wrote:
On a pte update, npte will always be 1. On a pde update, we won't
do anything in mmu_pte_write_new_pte because it doesn't handle
pdes. If we extend it to handle pdes, then we need either to
modify the new gpde or to have the update
This is the start of a paravirt_ops implementation for KVM. Most of it
was done by Ingo Molnar, I just moved things around a bit. I don't
think there's a measurable performance benefit just yet but there are a
few more optimizations that I think we can get in time for 2.6.23 that
will be
Regards,
Anthony Liguori
Subject: [PATCH] Add KVM paravirt_ops implementation
From: Anthony Liguori [EMAIL PROTECTED]
This patch adds the basic infrastructure for paravirtualizing a KVM guest.
Discovery of running under KVM is done by sharing a page of memory between
the guest and host
Regards,
Anthony Liguori
Subject: [PATCH][PARAVIRT] Eliminate unnecessary CR3 read in TLB flush
This patch eliminates the CR3 read (which would cause a VM exit) in the TLB
flush path. The patch is based on Ingo Molnar's paravirt series.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
Index:
Hi Ingo,
In my last series, I avoided submitting any patches that used
hypercalls. Part of the reason is that I know that your tree already
has assigned hypercalls out to various things. Some make sense (like
flush_cr3_cache) but some are, at least, contentious (like the pv disk
Andi Kleen wrote:
On Wednesday 30 May 2007 16:53:41 Anthony Liguori wrote:
Subject: [PATCH][PARAVIRT] Eliminate unnecessary CR3 read in TLB flush
This patch eliminates the CR3 read (which would cause a VM exit) in the TLB
flush path. The patch is based on Ingo Molnar's paravirt series.
Anthony Liguori wrote:
Regards,
Anthony Liguori
I think we should use the CPUID instruction (leaf 0x4000) to detect
the hypervosor as we are doing in Xen.
Jun
---
Intel Open Source Technology Center
-
This SF.net
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
Sure. It adds a few more cycles onto native though (two memory
reads,
and some math).
As opposed to a serializing control-register read? I think that's
probably a win.
J
And actually you don't need the write to CR3 to flush TLB
Anthony Liguori wrote:
Rusty Russell wrote:
On Mon, 2007-05-28 at 20:54 -0500, Anthony Liguori wrote:
Howdy,
Does anyone know what the state of a pv_ops backend for KVM is? I
know Ingo has an implementation that implements CR3 caching but I
don't see any branches in Avi's git tree.
Nakajima, Jun wrote:
And actually you don't need the write to CR3 to flush TLB because the
one to CR4 does it. Or does kvm_flush_tlb_kernel assume that CR3 is
updated at the same time?
Jun
It should not be necessary, but I believe this was added as a workaround
to a PII erratum. I can't
Zachary Amsden wrote:
Nakajima, Jun wrote:
And actually you don't need the write to CR3 to flush TLB because
the
one to CR4 does it. Or does kvm_flush_tlb_kernel assume that CR3 is
updated
at the same time?
Jun
It should not be necessary, but I believe this was added as a
Nakajima, Jun wrote:
Zachary Amsden wrote:
Nakajima, Jun wrote:
And actually you don't need the write to CR3 to flush TLB because
the
one to CR4 does it. Or does kvm_flush_tlb_kernel assume that CR3 is
updated
at the same time?
Jun
It should not
Anthony Liguori wrote:
Nakajima, Jun wrote:
snip
For KVM, it should be okay as well. But we can replace two CR4
accesses
with just one hypercall.
I was thinking the same thing :-)
I was actually thinking about adding a hypercall to set/clear a bit in
a
control register. The
Anthony Liguori wrote:
I was thinking the same thing :-)
I was actually thinking about adding a hypercall to set/clear a bit in
a control register. The thought here is that it would be useful not
just for the global bit but also for CR0.TS although we would need
another paravirt_op hook
Nakajima, Jun wrote:
Anthony Liguori wrote:
Given the optimizations for CPU virtualization in the current H/W, I'm
not sure if such hooks are useful. Do you have any performance data that
justify such hooks?
No, I don't. It was just a thought that was yet to be confirmed.
Regards,
On Wed, 2007-05-30 at 09:52 -0500, Anthony Liguori wrote:
This patch adds the basic infrastructure for paravirtualizing a KVM
guest.
Hi Anthony!
Nice patch, comments below.
Discovery of running under KVM is done by sharing a page of memory
between
the guest and host (initially
On Wed, 2007-05-30 at 14:22 -0500, Anthony Liguori wrote:
I was actually thinking about adding a hypercall to set/clear a bit in a
control register. The thought here is that it would be useful not just
for the global bit but also for CR0.TS although we would need another
paravirt_op hook
Rusty Russell wrote:
On Wed, 2007-05-30 at 09:52 -0500, Anthony Liguori wrote:
This patch adds the basic infrastructure for paravirtualizing a KVM
guest.
Hi Anthony!
Nice patch, comments below.
Discovery of running under KVM is done by sharing a page of memory
between
20 matches
Mail list logo
