On Sat, 6 Jan 2007, Pavel Machek wrote:
> Does this make Xen obsolete? I mean... we have xen patches in suse
> kernels, should we keep updating them, or just drop them in favour of
> KVM?
> Pavel
Xen is duplicating basic OS components like the
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Looks like a lot of complexity for very little gain. I'm not sure
> what the vmwrite cost is, cut it can't be that high compared to
> vmexit.
while i disagree with characterising one extra parameter passed down
plus one extra branch as 'a lot of comp
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
but AFAICS rmap_write_protect() is only ever called if we write a new
cr3 - hence a TLB flush will happen anyway, because we do a
vmcs_writel(GUEST_CR3, new_cr3). Am i missing something?
No, rmap_write_protect() is called whe
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >but AFAICS rmap_write_protect() is only ever called if we write a new
> >cr3 - hence a TLB flush will happen anyway, because we do a
> >vmcs_writel(GUEST_CR3, new_cr3). Am i missing something?
>
> No, rmap_write_protect() is called whenever we shadow
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
the cache is zapped upon pagefaults anyway, so unpinning ought to be
possible. Which one would you prefer?
It's zapped by the equivalent of mmu_free_roots(), right? That's
effectively unpinning it (by zeroing ->root_count).
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > the cache is zapped upon pagefaults anyway, so unpinning ought to be
> > possible. Which one would you prefer?
>
> It's zapped by the equivalent of mmu_free_roots(), right? That's
> effectively unpinning it (by zeroing ->root_count).
no, right now
Ingo Molnar wrote:
This is a little too good to be true. Were both runs with the same
KVM_NUM_MMU_PAGES?
yes, both had the same elevated KVM_NUM_MMU_PAGES of 2048. The 'trunk'
run should have been labeled as: 'cr3 tree with paravirt turned off'.
That's not completely 'trunk' but clos
On Sat, Jan 06, 2007 at 01:08:18PM +, Pavel Machek wrote:
> Does this make Xen obsolete? I mean... we have xen patches in suse
> kernels, should we keep updating them, or just drop them in favour of
> KVM?
After all the Novell Marketing Hype you'll probably have to keep Xen ;-)
Except for that
On Sun, 2007-01-07 at 14:20 +0200, Avi Kivity wrote:
>
>
> Well, you did say it was ad-hoc. For reference, this is how I see the
> hypercall API:
[snip]
> - Guest/host communications is by guest physical addressed, as the
> virtual->physical translation is much cheaper on the guest (__pa() vs
>
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >2-task context-switch performance (in microseconds, lower is better):
> >
> > native: 1.11
> > --
> > Qemu:61.18
> > KVM upstream:53.01
> > KVM trunk:
Ingo Molnar wrote:
i'm pleased to announce the first release of paravirtualized KVM (Linux
under Linux), which includes support for the hardware cr3-cache feature
of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
the patch is against 2.6.20-rc3 + KVM trunk and can be found
Hi!
> i'm pleased to announce the first release of paravirtualized KVM (Linux
> under Linux), which includes support for the hardware cr3-cache feature
> of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
>
> the patch is against 2.6.20-rc3 + KVM trunk and can be found at:
>
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> >>What you really want is more like
> >>EXPORT_SYMBOL_READABLE_GPL(paravirt_ops);
> >>
> >
> >yep. Not a big issue - what is important is to put the paravirt ops
> >into the read-only section so that it's somewhat harder for rootkits
> >to modi
This is pretty cool. I've read the VT spec a number of times and never
understood why they included the CR3 caching :-) I suspect that you may
even be faster than Xen for context switches because of the hardware
assistance here. Any chance you can run your benchmarks against Xen?
You may al
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
What you really want is more like
EXPORT_SYMBOL_READABLE_GPL(paravirt_ops);
yep. Not a big issue - what is important is to put the paravirt ops into
the read-only section so that it's somewhat harder for rootkits to
modi
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> What you really want is more like
> EXPORT_SYMBOL_READABLE_GPL(paravirt_ops);
yep. Not a big issue - what is important is to put the paravirt ops into
the read-only section so that it's somewhat harder for rootkits to
modify. (Also, it needs to be
Ingo Molnar wrote:
i'm pleased to announce the first release of paravirtualized KVM (Linux
under Linux), which includes support for the hardware cr3-cache feature
of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
the patch is against 2.6.20-rc3 + KVM trunk and can be found
i'm pleased to announce the first release of paravirtualized KVM (Linux
under Linux), which includes support for the hardware cr3-cache feature
of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
the patch is against 2.6.20-rc3 + KVM trunk and can be found at:
http://redha
18 matches
Mail list logo
