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.iso
--
Gerd Hoffmann [EMAIL PROTECTED
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
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 make install, making builds using the libkvm installed
-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)/include
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
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
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
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
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 bigger bigger than 5 and smaller than 8
It doesn't come that far
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(-)
Index: kvm-46/user/kvmctl.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 memory must exist before creating
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
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
pointer, please use that instead of mmap()'ing
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 and retested patch.
Oh, -47 is there. Updated
+/*
+ * 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 now_ns;
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
struct.)
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 anywhere?
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 there precedent
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 address
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 our seg
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 flags
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.c
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.
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-level
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.
cheers,
Gerd
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.c looks incomplete too. vcpu
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
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:
rhel5-64 kraxel
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
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:
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 no backward compatibility issues.
Great, so I'll
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 fills in host system
time
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
time where the system clock started going. As kvm
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 ?
Haven't
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_clocksource_read(void), and I can't see any
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
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_time_values(shadow, src);
+ret = shadow-system_timestamp
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 doesn't look like shadow_time needs
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 be wildly different.
Ah, ok, forgot the rdtsc in the picture
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/x86.c
+++ b
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/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..47f0cdc
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..ed1a679
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 deletions
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
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 one.
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 also factor out some code which can be shared
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
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 actually two (maybe related) problems.
First
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 also factor out some code which can be shared
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/x86/Kconfig
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
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/x86.c
+++ b
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/time.c | 110 +-
2
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 ---
2
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_ns(now) -
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
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..3a4f16a
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..b749c85
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 deletions
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 :
61 matches
Mail list logo
