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.
Ag
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 tak
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 h
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 meas
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 (initia
Regards,
Anthony Liguori
Subject: [PATCH][PARAVIRT] Make IO delay a NOP for paravirt guests
No delay is required in between PIO operations under KVM guests so make IO
delay a NOP. This was originally part of Ingo Molnar's paravirt series.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
Ind
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
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.
>
This change coul
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
hypercalls).
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:
> 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
-
This SF.net email i
>>> >I have used KVM 16 in x86_64 OpenSUSE 10.2 without problems.
>>
>>> >I have recently downloaded and installed x86_64 RPMs of KVM 24.
>>
>>> >But I could not start it:
>>
>>> >
>>
>>> >#qemu-kvm
>>
>>> >open /dev/kvm: No such file or directory
>>
>>> >Could not initialize KVM, will disable KVM
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
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
Nakajima, Jun wrote:
> 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.
>
Is that leaf reserved for such use by Intel?
Regards,
Anthony Liguori
> Jun
> -
Zachary Amsden wrote:
>> VMI can determine that it's under VMware since VMware has to publish
>> an option ROM. It's quite neat, but overkill for what we're doing
>> (since we're not going to be using a ROM anyway).
>
> The near to being blessed way to do this is to use a CPUID leaf (I
> believ
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'
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> > 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.
> >
>
> Is that leaf reserved for such use b
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
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?
>>>
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> > 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. T
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_o
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.
Re
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 hoo
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
>>>
>>>The result of the command:
>>>
>>>/sbin/lsmod|grep kvm
>>>
>>>was:
>>>
>>>KVM 866160
>>>I did not found any /dev/kvm file...
>>
>>You don't have kvm_intel module loaded.
>>If it fails loading please check dmesg.
>
>Thank you Dor!
>This is output of dmesg below. I could not understand w
Move per VCPU mmu_memory_cache to be VM basis.
Your opnion?
Eddie
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..77989b4 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -300,11 +300,6 @@ struct kvm_vcpu {
struct kvm_mmu mmu;
- struct kvm_mmu_memor
29 matches
Mail list logo
