Hi,
With xenner I see a very high number of exits for no appearent reason in
the statistics:
kvm stats :total diff
mmu_cache_miss : 53800
mmu_flooded : 12940
mmu_pde_zapped :101320
mmu_pte_updated : 122
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |4 +
arch/x86/kernel/Makefile |1 +
arch/x86/kernel/pvclock.c | 148 +
include/asm-x86/pvclock.h |6 ++
4 files changed, 159 insertions(+), 0 del
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |1 +
arch/x86/kernel/kvmclock.c | 86 ---
2 files changed, 33 insertions(+), 54 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index deb3049..b
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/xen/Kconfig |1 +
arch/x86/xen/time.c | 110 +-
2 files changed, 12 insertions(+), 99 deletions(-)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 2e641be..3
paravirt clock source patches, next round, with a bunch of changes
in the host code according to Avi's review comments and some minor
code tweaks.
cheers,
Gerd
-
This SF.net email is sponsored by: Microsoft
Defy all chall
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 71 ---
include/asm-x86/kvm_host.h |1 +
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dab3d4f..7
Avi Kivity wrote:
>> +struct timespec now,sys,boot;
>
> Add spaces.
Done.
>> +#if 0
>> +/* Hmm, getboottime() isn't exported to modules ... */
>> +getboottime(&boot);
>> +#else
>> +now = current_kernel_time();
>> +ktime_get_ts(&sys);
>> +boot = ns_to_timespec(timespec_to_
Glauber Costa wrote:
> So maybe declare the per-cpu areas in a special section, then in
> setup_per_cpu_areas, copy them into the definitive per-cpu section and
> update the callers?
The special section and the copy is implemented already.
That doesn't cut it for the kvmclock case though. We re
This patch switches the kvm clocksource code over to use the
paravirt clock helpers, thereby making it compatible with xen.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |1 +
arch/x86/kernel/kvmclock.c | 84
This patch switches the xen paravirt clock over to use the
generic paravirt clock code.
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/xen/Kconfig |1 +
arch/x86/xen/ti
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 63 +++
1 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 979f983..6906d54 100644
--- a/arch/x86/kvm
Respin of the paravirt clock patch series.
On the host side the kvm paravirt clock is made compatible with the
xen clock.
On the guest side some xen code has been factored out into a separate
source file shared by both kvm and xen clock implementations.
This time it should work ok for kvm smp gu
The helper functions are intended to be used by both xen and kvm
paravirtual clock sources. Following patches of this series put
them into use. They are based on the xen code.
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch
Marcelo Tosatti wrote:
> On Thu, Apr 24, 2008 at 10:37:04AM +0200, Gerd Hoffmann wrote:
>> Hi folks,
>>
>> My first attempt to send out a patch series with git ...
>>
>> The patches fix the kvm paravirt clocksource code to be compatible with
>> xen and they
Gerd Hoffmann wrote:
> Marcelo Tosatti wrote:
>> F8 host, recent kvm-userspace.git (so with IO thread), recent kvm.git
>> (plus your patches), haven't tried 2x but I think 4x is not necessary to
>> reproduce the problem.
>
> Ok, see it too. Seem to be actua
Marcelo Tosatti wrote:
> F8 host, recent kvm-userspace.git (so with IO thread), recent kvm.git
> (plus your patches), haven't tried 2x but I think 4x is not necessary to
> reproduce the problem.
Ok, see it too. Seem to be actually two (maybe related) problems.
First the guest hangs hard after a
Marcelo Tosatti wrote:
> On Thu, Apr 24, 2008 at 10:37:04AM +0200, Gerd Hoffmann wrote:
>> Hi folks,
>>
>> My first attempt to send out a patch series with git ...
>>
>> The patches fix the kvm paravirt clocksource code to be compatible with
>> xen and they
Avi Kivity wrote:
> The patches look good, but pleasy copy Jeremy and virtualization@ for
> patches which touch things outside kvm.
Will do for the next round.
> It's perhaps better to reverse the order: first fix kvm to be
> compatible, then merge the Xen and kvm implementations into a single on
Glauber Costa wrote:
> This is not exactly what kvm does. For us, wallclock read and system
> time reads are decoupled operations, controlled by different msrs.
Same for xen. Although both live in the shared_info page they are
updated independently (and the wall clock is updated much less freque
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |4 +
arch/x86/kernel/Makefile |1 +
arch/x86/kernel/pvclock.c | 146 +
include/asm-x86/pvclock.h |6 ++
4 files changed, 157 insertions(+), 0 del
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |1 +
arch/x86/kernel/kvmclock.c | 66 ++-
2 files changed, 17 insertions(+), 50 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fe73d38..e
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/xen/Kconfig |1 +
arch/x86/xen/time.c | 110 +-
2 files changed, 12 insertions(+), 99 deletions(-)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 4d5f264..4
Hi folks,
My first attempt to send out a patch series with git ...
The patches fix the kvm paravirt clocksource code to be compatible with
xen and they also factor out some code which can be shared into a
separate source files used by both kvm and xen.
cheers,
Gerd
---
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 63 +++
1 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0ce5563..45b71c6 100644
--- a/arch/x86/kvm
Glauber Costa wrote:
> Gerd Hoffmann wrote:
>> Jeremy Fitzhardinge wrote:
>>> Xen could change the parameters in the instant after
>>> get_time_values(). That change could be as a result of
>>> suspend-resume, so the parameters
>>> and the tsc could
Jeremy Fitzhardinge wrote:
> Gerd Hoffmann wrote:
>> Not really. There are only two calls, one in clocksource_read() and one
>> in the init path. The later is superfluous I think because
>> clocksource_read() is the only user of the shadowed time info.
>
> Hm. It do
Jeremy Fitzhardinge wrote:
> Gerd Hoffmann wrote:
>> +cycle_t pvclock_clocksource_read(struct kvm_vcpu_time_info *src)
>> +{
>> +struct pvclock_shadow_time *shadow = &get_cpu_var(shadow_time);
>> +cycle_t ret;
>> +
>> +pvclock_get_tim
Jeremy Fitzhardinge wrote:
> Xen could change the parameters in the instant after get_time_values().
> That change could be as a result of suspend-resume, so the parameters
> and the tsc could be wildly different.
Ah, ok, forgot the rdtsc in the picture. With that in mind I fully
agree that the
Gerd Hoffmann wrote:
> Marcelo Tosatti wrote:
>> Haven't seen Gerd's guest patches ?
>
> I'm still busy cooking them up. I've mentioned them in a mail, but they
> didn't ran over the list (yet). Stay tuned ;)
It compiles, ship it!
This time as
Jeremy Fitzhardinge wrote:
> Gerd Hoffmann wrote:
>> I'm looking at the guest side of the issue right now, trying to identify
>> common code, and while doing so noticed that xen does the
>> version-check-loop in both get_time_values_from_xen(void) and
>> xen_clockso
Marcelo Tosatti wrote:
>> >From what me and marcelo discussed, I think there's a possibility that
>> it has marginally something to do with precision of clock calculation.
>> Gerd's patches address that issues. Can somebody test this with those
>> patches (both guest and host), while I'm off ?
>
>
Jeremy Fitzhardinge wrote:
> Gerd Hoffmann wrote:
>> Wall clock is off a few hours though. Oops.
>>
>> I think the way wall clock and system clock work together in xen (Jeremy
>> correct me if I'm wrong) is that the wall clock specifies the point in
>> tim
Gerd Hoffmann wrote:
> Wall clock is off a few hours though. Oops.
>
> I think the way wall clock and system clock work together in xen (Jeremy
> correct me if I'm wrong) is that the wall clock specifies the point in
> time where the system clock started going. As kvm
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> Hi,
>>
>> Tried to use kvmclock with xenner and noticed that the kvmclock
>> (MSR_KVM_SYSTEM_TIME msr) is incompatible with xen.
>
> Patches are welcome, especially as kvmclock isn't merged yet, so there
> are
Hi,
Tried to use kvmclock with xenner and noticed that the kvmclock
(MSR_KVM_SYSTEM_TIME msr) is incompatible with xen.
kvm guests do this to translate the tsc delta into nsecs:
#define get_clock(cpu, field) per_cpu(hv_clock, cpu).field
static inline u64 kvm_get_delta(u64 last_tsc)
{
Avi Kivity wrote:
> [fairly amazing results. how do they compare to xen?]
Didn't benchmark it side-by-side yet. Most likely xenner is still
noticeable slower on 64bit (32bit should be roughly comparable). I also
wouldn't surprised if you see different results on different workloads.
xen mangl
Gerd Hoffmann wrote:
> I've passed in a physical address. The vmx_cr3_cache_msr() function has
> a gva_to_page() call which makes me suspect it expects a virtual
> address.
Confirmed. When passing in a virtual address it works.
And it gives me a nice speedup for kernel builds:
r
Marcelo Tosatti wrote:
> And this is against a changed x86.git -mm tree (with pvops64 patches).
> I'll send the PTE-write-via-hypercall patches soon and will rebase on
> top of that (the CR3 cache needs more testing/tuning apparently).
Oops for sale ;)
Triggered by guests wrmsr, looks like some e
Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>
>> Hmm, what kvm version is this against? latest git I guess? After
>> applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
>
> Looks like the mmu.h chunk is missing in the patch.
Hmm, and x86.
Gerd Hoffmann wrote:
> Hmm, what kvm version is this against? latest git I guess? After
> applying to kvm-60 (and fixing up some trivial rejects) it doesn't build.
Looks like the mmu.h chunk is missing in the patch.
che
Marcelo Tosatti wrote:
> Hi,
>
> The CR3 cache feature of VMX CPU's does not seem to increase
> context switch performance significantly as it did in the original
> implementation (http://lkml.org/lkml/2007/1/5/205).
>
> The following is similar to the original, but it also caches roots for
> 4-l
Avi Kivity wrote:
> Agree, but should try a "quit" monitor command first. Signals are racy,
> like anything that deals with pids (qemu dies, another process is
> fork()ed with the same pid, libvirt kills it).
There is no race in that specific case because qemu is started by
libvirtd. libvirtd
Hi,
Quick question: is kvm able to handle guests using pae when the host
runs a non-pae 32bit kernel?
cheers,
Gerd
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http
Andrea Arcangeli wrote:
> Like Avi said, Xen is dealing with the linux pte only, so there's no
> racy smp page fault to serialize against. Perhaps we can add another
> notifier for Xen though.
>
> But I think it's still not enough for Xen to have a method called
> before the ptep_clear_flush: rmap
Robin Holt wrote:
> We have a seg structure which is similar to some structure you probably
> have which describes the grant. One of the things hanging off that
> seg structure is essentially a page table containing PFNs with their
> respective flags (XPMEM specific and not the same as the pfn fla
Hi,
>> That would render the notifies useless for Xen too. Xen needs to
>> intercept the actual pte clear and instead of just zapping it use the
>> hypercall to do the unmap and release the grant.
>
> We are tackling that by having our own page table hanging off the
> structure representing ou
Hi,
Jumping in here, looks like this could develop into a direction useful
for Xen.
Background: Xen has a mechanism called "grant tables" for page sharing.
Guest #1 can issue a "grant" for another guest #2, which in turn then
can use that grant to map the page owned by guest #1 into its addre
Hi,
>>> Catching ctrl-c sounds like a good idea but "ctrl-c, ctrl-c" should
>>> probably kill qemu then, since the machine might have no acpid running -
>>> in that case hitting ctrl-c would have no effect.
>>>
>> Good idea.
>>
>
> I'm worried about the 30+ second shutdown latency. Is
> +struct shared_info shared_info __attribute__((__aligned__(PAGE_SIZE)));
leftover from old version?
> +unsigned long kvm_get_wallclock(void)
> +{
> + u32 wc_sec, wc_nsec;
> + u64 delta, last_tsc;
> + struct timespec ts;
> + int version, nsec, cpu = smp_processor_id();
> +
> +
Glauber de Oliveira Costa wrote:
> This is the host part of kvm clocksource implementation. As it does
> not include clockevents, it is a fairly simple implementation. We
> only have to register a per-vcpu area, and start writting to it periodically.
>
> The area is binary compatible with xen, as
Hi,
> We want to avoid updating wall clock all the time. As far as I
> understand, wall clock is just a base which doesn't change.
Yep, it is. Got that wrong first in xenner, with the result that guest
time ran at double speed ;)
>> +/* xen binary-compatible interfaces. See xen headers for
Hi,
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index d083ff5..7728b87 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> -static cycle_t xen_clocksource_read(void);
> +cycle_t xen_clocksource_read(void);
Huh? You kill the static, but don't use the functions anywhe
Muli Ben-Yehuda wrote:
> On Wed, Nov 07, 2007 at 04:21:04PM +0200, Amit Shah wrote:
>
>> We make the dma_mapping_ops structure to point to our structure so
>> that every DMA access goes through us. (This is the reason this only
>> works for 64-bit guest. 32-bit guest doesn't yet have a dma_ops
>>
> +/*
> + * Guest has page alignment and padding requirements. At the host, it will
> + * only lead to wasted space at the vcpu struct. For this reason, the struct
> + * is not anonymous
> + */
> +union kvm_hv_clock {
> + struct kvm_hv_clock_s {
> + u64 tsc_mult;
> + u64
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> No, I'm hacking up one more user ;)
>
> Nice. What will it do?
Run xenified guest kernels without Xen.
>> Should I send an updated patch or do you just drop these lines when
>> merging?
>
> Please send a rebased
Hi,
> Break it. It has just one user, our qemu, which is included in the same
> package.
No, I'm hacking up one more user ;)
But maybe I'm better off shipping a private copy of kvmctl.c as long as
the library interface isn't finalized yet and subject to change.
>> Thats why I went the route
Avi Kivity wrote:
> Izik Eidus wrote:
>> On Thu, 2007-10-18 at 12:18 +0200, Gerd Hoffmann wrote:
>>
>>>>> I don't see how I can pass a pointer to
>>>>> kvm_create_userspace_memory() via kvm_create() without
>>>>> breaking the libkvm
Dor Laor wrote:
> Gerd Hoffmann wrote:
>> I don't see how I can pass a pointer to kvm_create_userspace_memory()
>> via kvm_create() without breaking the libkvm interface. There is no
>> flags field or similar which could be used to signal "vm_mem is a valid
>>
Izik Eidus wrote:
> hi,
> why not making kvm_create_userspace_memory() recive a pointer to a
> userspace allocated memory (that was allocated from file or from normal
> malloc)
> and make all the changes before kvm_create_userspace_memory() get called?
I don't see how I can pass a pointer to kvm_c
Gerd Hoffmann wrote:
> I've made kvm_create() optionally skip the memory setup, so I can create
> my own later on. That doesn't work though because creating the vcpu
> fails then.
Ugh, vmx grabs last 4 pages from slot 0 (looks like for real mode
emulation). Thus memor
Hollis Blanchard wrote:
> That's a good point, but does PIT/HPET emulation show up as a hot spot
> in any profiles? I think keeping the hypercall API as small as feasible
> is a desirable design goal.
pit probably doesn't due to being rarely updated. For hpet I'd expect
it showing up much more.
Glauber de Oliveira Costa wrote:
> Well, my previous understanding was that if the CPU marks the tsc as
> stable, it _won't_ stop even in C3, and it was done this way exactly
> to make sure there are a stable source for timing.
Other way around: Kernel can mark the TSC unstable if it figures it
d
egister any userspace memory
as guest physical memory.
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
user/kvmctl.c | 53 +
user/kvmctl.h |3 +++
2 files changed, 44 insertions(+), 12 deletions(-)
Izik Eidus wrote:
> On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote:
>> Gerd Hoffmann wrote:
>>
>>> Something like this? (compiles, not tested yet).
>> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
>
> try use slot bigge
Gerd Hoffmann wrote:
> Something like this? (compiles, not tested yet).
Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
cheers,
Gerd
-
This SF.net email is sponsored by: Splunk Inc.
S
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> Avi Kivity wrote:
>>
>>> We've now switched to allocating guest memory in userspace rather than
>>> in the kernel.
>>>
>> Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way ho
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>>
>>> 2) the TSC would have to be used as a clocksource. You don't know the
>>> frequency which is the first problem with using the TSC but some systems
>>> have a TSC that changes frequencies.
>>>
Hi,
> 2) the TSC would have to be used as a clocksource. You don't know the
> frequency which is the first problem with using the TSC but some systems
> have a TSC that changes frequencies.
Also note the tsc may stop ticking if the CPU goes sleep in C3, which
IMHO makes the tsc almost useles
Avi Kivity wrote:
> We've now switched to allocating guest memory in userspace rather than
> in the kernel.
Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way how to
use that. If I want to back vm memory with a file mapping, how can I do
that?
cheers,
Gerd
---
>> I *think* it happens because I'm changing guest page tables from outside
>> (i.e. host application), and the new intel pgtable optimization bits
>> don't expect that (yes, it is a vt box).
>
> Well, the older implementation doesn't expect that either. You can
> disable the optimization with by
Avi Kivity wrote:
> You can call kvm_disable_irqchip_creation() to kill in-kernel pic and
> friends.
>
> (the logic is inverted -- the function should be
> kvm_enable_irqchip_creation() so that this problem would not occur)
Ok, will try, next question first though as I'm running in trouble much
e
Avi Kivity wrote:
> Only one fix, but an important one. It fixes booting of newer Linux
> versions, which experienced disk and keyboard problems without
> -no-kvm-irqchip.
>
> As usual, if you have an issue please try with -no-kvm-irqchip and report.
Updated from -41. Now my libkvm-using-tool's
ned-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
diff -up kvm-41/user/Makefile.hdr kvm-41/user/Makefile
--- kvm-41/user/Makefile.hdr 2007-09-20 11:30:47.0 +0200
+++ kvm-41/user/Makefile 2007-09-20 11:31:10.0 +0200
@@ -55,6 +55,8 @@ install:
install -D kvmctl.h $(DESTDIR)/$(PREFIX
Gerd Hoffmann wrote:
> Avi Kivity wrote:
>> Changes since kvm-40:
>> - refactor hypercall infrastructure for simplicity and better smp
>> support (Anthony Liguori)
>
> The new kvm_para.h header file added by (I think) this change isn't
> installed by &quo
Avi Kivity wrote:
> Changes since kvm-40:
> - refactor hypercall infrastructure for simplicity and better smp
> support (Anthony Liguori)
The new kvm_para.h header file added by (I think) this change isn't
installed by "make install", making builds using the libkvm installed on
the system fail.
Rusty Russell wrote:
> You mean backend? For networking it makes a great deal of sense. For
> block it makes far less sense (COW, weird formats, etc).
For block you probably want both: userspace driver which can handle all
sorts of funny image files, and a kernel driver doing a 1:1 mapping to a
Hi,
> Framebuffer is an interesting one. Virtio doesn't assume shared memory,
> so naively the fb you would just send outbufs describing changed memory.
> This would work, but describing rectangles is better. A helper might be
> the right approach here
Rectangles work just fine for a framebu
Maria Casale wrote:
> I have got an Intel Core Duo T2400 processor.
> I added the repository:
> http://software.opensuse.org/download/home:/kraxel/openSUSE_10.2/i386/
> I installed kvm and kvm-kmp. I added kvm modules in etc/sysconfig.
> I ran qemu-kvm and this appeared: Could not initialize KVM,
Avi Kivity wrote:
> - new userspace interface (work in progress)
kvmfs in kvm-15 kernel code does not to build with older kernels (2.6.16
fails, 2.6.18 works ok), looks like the reason are some changes in
superblock handling.
Do you intend to fix that?
cheers,
Gerd
--
Gerd Hoffmann <
or installation and fixing up menu.lst, then go ahead
with the kvm version ...
reproduce: fetch the boot iso[1], boot with "-cdrom /path/to/mini.iso
-boot d"
cheers,
Gerd
[1]
http://ftp.opensuse.org/pub/opensuse/distribution/10.2/iso/cd/openSUSE-10.2-GM-i386-mini.i
80 matches
Mail list logo
