Zhang, Xiantao wrote:
From 12457e0fb85ef32f1a1f808be294bebe8d22667c Mon Sep 17 00:00:00 2001
From: Zhang xiantao [EMAIL PROTECTED]
Date: Fri, 12 Oct 2007 13:29:30 +0800
Subject: [PATCH] Split kvm_vcpu to support new archs. Define a new sub
field
kvm_arch_vcpu to hold arch-specific sections.
Zhang, Xiantao wrote:
According to our previous discuss, we proposed a source layout, which
contains an include directory to hold header files for all archs
under drivers/kvm/, and kvm_arch.h will finally go into
drivers/kvm/include/kvm-x86/(linked as kvm when compile).
Right. The thing is,
the s390 might have a lot in common with a future AMD
nested page table implementation. If AMD choose to reuse the page table
too, we might share the same ioctl to set up guest addressing with them.
signed-off-by: Carsten Otte [EMAIL PROTECTED]
reviewed-by: Christian Borntraeger [EMAIL PROTECTED
screen space.
The intend of an rfc is in general to review a patch, not to pick on
formalities.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
Reviewed-by: Christian Borntraeger [EMAIL PROTECTED]
Reviewed-by: Christian Ehrhardt [EMAIL PROTECTED]
---
kvm.h |3
kvm_main.c | 460
Zhang, Xiantao wrote:
diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
index 3b69541..df67292 100644
--- a/drivers/kvm/ioapic.c
+++ b/drivers/kvm/ioapic.c
@@ -156,7 +156,7 @@ static u32 ioapic_get_delivery_bitmask(struct
kvm_ioapic *ioapic, u8 dest,
if (dest_mode == 0) { /*
Zhang, Xiantao wrote:
So, every
architecture can defines its own kvm_arch.h for their arch, and
compile will choose it per ARCH when compile time. But for now, we
can just put it here before another real new arch in. Then, we can
remove x86.h, since it is not so common for all archs. :)
Jim Paris wrote:
If I stop KVM in the monitor with stop, wait a minute, and do
cont, a Linux guest gives me a BUG: soft lockup detected on CPU#0.
Is that expected behavior?
We have the same behavior on s390 when running in a virtual
environment. The issue is, that the guest physical cpu may
Zhang, Xiantao wrote:
These patches are based on commit
7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).
They don't apply on top of git head anymore, could you please rebase?
Any comments are welcome!
I do appreciate your work towards portability. Could you also please
post
Dong, Eddie wrote:
[EMAIL PROTECTED] wrote:
Jim Paris wrote:
If I stop KVM in the monitor with stop, wait a minute, and do
cont, a Linux guest gives me a BUG: soft lockup detected on
CPU#0. Is that expected behavior?
We have the same behavior on s390 when running in a virtual
environment.
Avi Kivity wrote:
The new capability bitmap moves the patch out of the very trivial
realm. I removed those hunks and applied.
Thanks.
Send more, the approach is clearly right. Leave things which require
changes (like the capability bitmap) to the end, there's more than
enough stuff for
, and an architecture
specific kvm_arch_vcpu_load/put. In the x86 case, this one calls the
vmx/svm function defined in kvm_x86_ops.
signed-off-by: Carsten Otte [EMAIL PROTECTED]
reviewed-by: Christian Borntraeger [EMAIL PROTECTED]
reviewed-by: Christian Ehrhardt [EMAIL PROTECTED]
---
Index: kvm/drivers/kvm
Avi Kivity wrote:
This is wrong -- kvm_main.c calls vmalloc() so this is needed. The fact
that it is included by something else doesn't mean we can remove it; we
don't want to depend on random #includes within header files.
Only remove a #include if nothing within the including file
Avi Kivity wrote:
Applied, thanks. I renamed kvm_vcpu_load() and kvm_vcpu_put() back to
vcpu_load() and vcpu_put() in order to keep the patch small and simple,
and because I'm emotionally attached to the original names.
Oh, I think I had a very good reason for renaming it: it's no longer
Avi Kivity wrote:
Small, reviewable, posted patches are definitely the best way forward.
Very well, will go that direction.
-case KVM_CHECK_EXTENSION: {
-int ext = (long)argp;
-
-switch (ext) {
-case KVM_CAP_IRQCHIP:
-case KVM_CAP_HLT:
-case
Avi Kivity wrote:
What's the motivation for the new header? So we have a list of
arch-dependent functions? Compiler-wise it could just as well remain in
kvm.h.
The motivation for a new header, is that it contains definitions
specific to an architecture. These prototypes should go to kvm.h,
think it is more convenient to have the
file in drivers/kvm so that we only need to convince Avi when changing
it.
signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: kvm/drivers/kvm/kvm_x86.h
===
--- /dev/null 1970-01-01 00:00
Christian Borntraeger pointed out that Avi requested to rename kvm_x86.c
to x86.c. The patch below is the same as V2, but the files kvm_x86.[ch]
have been renamed to x86.[ch], and the #includes have been updated.
signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: kvm/drivers/kvm/kvm.h
Avi Kivity wrote:
Argument names in prototypes please.
Will do that.
case KVM_CHECK_EXTENSION: {
int ext = (long)argp;
-switch (ext) {
-case KVM_CAP_IRQCHIP:
-case KVM_CAP_HLT:
-case KVM_CAP_MMU_SHADOW_CACHE_CONTROL:
-
capabilities they support. Possible valus for the bit
masks are defined in drivers/kvm/kvm.h (KVM_ARCH_HAS_*), which rely on
KVM_CAP_* definitions in include/linux/kvm.h.
Function prototypes in drivers/kvm/kvm.h have been fixed: they have
argument names now.
signed-off-by: Carsten Otte [EMAIL
by kvm_arch_dev_ioctl() in kvm_x86.c.
A header file named kvm_arch.h is being introduced that contains
prototypes for funtions in kvm_x86.c.
Comments? Is this a preferable approach? What needs to be done
different?
signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: kvm/drivers/kvm/kvm_arch.h
Rusty Russell wrote:
Whatever way we go, grouping both host and guest support in the same dir
seems confusing (which is why lguest is moving to arch/i386/lguest/ for
guest and drivers/lguest/i386/ for host).
That really is funny. Our s39host is just the other way round:
arch/s390/sie for the
Zhang, Xiantao wrote:
We are working on enabling KVM support on IA64 platform, and now
Linux, Windows guests get stable run and achieve reasonable performance
on KVM with Open GFW. But you know, the current KVM only considers x86
platform, and is short of cross-architecture framework.
Hi list,
I've observed that current kvm-44 userspace with Avi's git as of
yesterday does not boot our debian test image on an AMD64 machine. The
kernel seems to die various panic's in sequence (too fast to observe),
the final one is in __delay(). Everything seems well without -no-kvm
option
Izik Eidus wrote:
we are working on swapping support for the guests in kvm.
we want to allow management of the memory swapping of the guests from kvm.
This is excellent, thank you!
this is request for comment, so any idea you have please write to me.
I ran into a few while reading the code:
Avi Kivity wrote:
kvm only tracks dirty bits if requested by userspace (for live
migration). Checking the pte is not so easy because the pte contains
only host addresses, not page addresses (well, we could consult the
guest page table, but...).
As far as I undstand this code, this function
in the
architecture independent struct even if we have different control
registers on different architectures.
This is tested on svm, unfortunately I don't have a vmx capable machine
at hand.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 70231f3
Avi Kivity wrote:
From a Linux point of view, the pid identifies the VM. A management
application can, however, use its own VM identifiers as it sees fit, and
map the (possibly persistent, gloablly unique, and ridiculously long)
VMID to the pid.
It might be preferable to have something
Avi Kivity wrote:
It may make sense to add a vmid to qemu (or to keep it in the management
application entirely). Certainly the kernel doesn't need to know about it.
Yes, I agree that should be userland only.
-
This
Dor Laor wrote:
I agree that pci interface isn't ideal, the advantage is that platforms
that do support pci don't have to implement a virtualized bus, and pci
is PnP device. This was the motivation behind using it, especially for
Windows.
In understand that requirement, and I think being able
Arnd Bergmann wrote:
On Wednesday 06 June 2007, Carsten Otte wrote:
We do have something basic, our vdev bus. The bad thing is, it is
platform specific. I really prefer to aim for an idea that Arnd came
up with when discussing this issue:
We could define a virtual device bus.
I guess
Rusty Russell wrote:
Is the noop scheduler significantly worse than hooking directly into
q-make_request_fn?
The noop scheduler does do request merging, and has the same device
plug latency as other schedulers.
so long,
Carsten
Jens Axboe wrote:
On Fri, Jun 01 2007, Carsten Otte wrote:
With regard to compute power needed, almost none. The penalty is
latency, not overhead: A small request may sit on the request queue to
wait for other work to arrive until the queue gets unplugged. This
penality is compensated
Jens Axboe wrote:
Most people should not fiddle with it, the defaults are there for good
reason. I can provide a blk_queue_unplug_thresholds(q, depth, delay)
helper that you could use for the virtualized drivers, perhaps that
would be better for that use?
Yea, we should'nt change the defaults
Rusty Russell wrote:
Now my lack of block-layer knowledge is showing. I would have thought
that if we want to do things like ionice(1) to work, we have to do some
guest scheduling or pass that information down to the host.
Yea that would only work on the host: one can use ionice to set the io
Troy Benjegerdes wrote:
This kind of a claim needs some benchmark data to document it.
We've implemented both for our vdisk driver on 390. At least on our
platform, merging in the host is preferable because vmenter/vmexit is
very fast and we would merge twice because we submit the result via
Gregory Haskins wrote:
1) I think I really want *any* signal to kick the HLT, so I temporarily
unmask everything while halted.
Acutally that'll cause trouble if people have device drivers in user
space, which mask SIGIO for the CPU threads like our s390 prototype
does. Consider leaving the
Avi Kivity wrote:
Ooh, I want one too.
You can get one here: http://www-03.ibm.com/systems/z/os/linux/lcds/
This might get useful the day we merge our stuff into kvm.
so long,
Carsten
-
This SF.net email is sponsored by DB2
Shaohua Li wrote:
+EXPORT_SYMBOL(delete_from_swap_cache);
+EXPORT_SYMBOL(move_to_swap_cache);
+EXPORT_SYMBOL(lookup_swap_cache);
+EXPORT_SYMBOL(read_swap_cache_async);
+EXPORT_SYMBOL(get_swap_page);
+EXPORT_SYMBOL(swap_free);
+EXPORT_SYMBOL(add_to_page_cache_lru);
Use EXPORT_SYMBOL_GPL for
Avi Kivity wrote:
For one thing, kvm uses page-private to store its rmap information.
This is lost if regular mappings are used.
More importantly, both the regular address space and kvm will want to be
called when a page is paged out, while this is doable, it isn't easy.
Taking the long
Avi Kivity wrote:
The pte is stored/cached in two different places (in addition to what
Linux already knows about):
- in the shadow page tables
- in the tlbs of the vcpus that may have referenced the page
so, when swapping out the page, you need to use the kvm rmap to find all
shadow
Avi Kivity wrote:
Interesting. And if you have multiple guest virtual to guest physical
translations, the hardware knows to flush them when the host virtual to
host physical entry is flushed?
Yes, the cpu flushes all of them.
so long,
Carsten
Daniel P. Berrange wrote:
As a userspace apps service, I'd very much like to see a common sockets
interface for inter-VM communication that is portable across virt systems
like Xen KVM. I'd see it as similar to UNIX domain sockets in style. So
basically any app which could do UNIX domain
Subject: [PATCH/RFC 0/5] s390 zlive
This set of patches contains our prototype userspace called zlive. We've used
this for initial development starting in 2005. This code tree is doomed to die
in months to come, as various code in here will head towards our kernel module
and kvm/qemu userspace. I
Subject: [PATCH/RFC 4/5] s390 zlive service processor calls
From: Carsten Otte [EMAIL PROTECTED]
From: Martin Peschke [EMAIL PROTECTED]
This patch adds support for calls to our service processor
o infrastructure that handles sclp calls
o infrastructure for sclp events
o sclp handlers
Subject: [PATCH/RFC 2/5] s390 zlive privileged instructions
From: Carsten Otte [EMAIL PROTECTED]
From: Christian Borntraeger [EMAIL PROTECTED]
This patch adds two things to the base code:
o infrastructure for handling priviledged operations
o handlers for basic priv ops, which are necessary
Subject: [PATCH/RFC 5/5] s390 zlive device drivers
From: Carsten Otte [EMAIL PROTECTED]
From: Christian Borntraeger [EMAIL PROTECTED]
From: Martin Peschke [EMAIL PROTECTED]
This patch contains the userland parts that connect to the set of paravirtual
device drivers posted last week
o zlick
Anthony Liguori wrote:
It seems like request_irq is roughly the same as
register_external_interrupt. I suspect that you could get away with
either patching hvc_console to use register_external_interrupt if
CONFIG_S390 or perhaps providing a common interface.
I suspect that this is going
Avi Kivity wrote:
I don't see an immediate need to put the host-side driver in the kernel,
but I don't want to embed the host fd (which is an implementation
detail) into the host/guest ABI. There may not even be a host fd.
Your point is taken, it also punches a hole in the security barrier
Avi Kivity wrote:
But I agree that the growing code base is a problem. With the block
driver we can probably keep the host side in userspace, but to do the
same for networking is much more work. I do think (now) that it is doable.
I agree that networking needs to be handled in the host
Avi Kivity wrote:
If the eventfd patchset is merged, then file descriptors will become the
standard Linux handle type, and poll (or rather, epoll) will become the
standard way of waiting for something to happen. But of course if you
come up with something better we'll use that.
Triggered
Avi Kivity wrote:
kvm doesn't do this directly. A hlt instruction (which is is used on
x86 to signal an idle cpu) is trapped and echoed to userspace, which
then sleeps using select(2).
I've read that part. I still don't like this approach, it just does'nt
fit our signal processor
Carsten Otte wrote:
- When the target CPU is going idle, but has not yet called signal(),
how can we figure from kernel space if it has masked this interrupt?
*Ouch*. Should be select(), not signal().
-
This SF.net email
Anthony Liguori wrote:
I think it would be better to use hvc_console as Xen now uses it too.
This console driver is pretty basic indeed.
This is an interesting way to get input data from the console :-) How
many interrupts does s390 support (the x86 only supports 256)? Can you
afford to
ron minnich wrote:
Let me ask what may seem to be a naive question to the linux world. I
see you are doing a lot off solid work on adding block and network
devices. The code for block and network devices
is implemented in different ways. I've also seen this difference of
-by: Carsten Otte [EMAIL PROTECTED]
---
include/asm-s390/page.h|8 +
include/asm-s390/pgalloc.h |5 +
include/asm-s390/pgtable.h | 197 -
3 files changed, 209 insertions(+), 1 deletion(-)
Index: linux-2.6.21/include/asm-s390/pgtable.h
that this patch is nothing more than a proof-of-concept
and may contain quite a few bugs.
Since we want to convert to use kvm instead, most of this will be
dropped anyway. But maybe this is of interest for others as well.
Signed-off-by: Heiko Carstens [EMAIL PROTECTED]
Signed-off-by: Carsten Otte [EMAIL
-by: Christian Borntraeger [EMAIL PROTECTED]
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
arch/s390/kernel/early.c |4
arch/s390/kernel/setup.c |9 ++---
include/asm-s390/setup.h |1 +
3 files changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6.21/arch/s390/kernel/setup.c
From: Carsten Otte [EMAIL PROTECTED]
This driver provides a simple virtualized console. Userspace can
use read/write to its console to pass the data to the host.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
drivers/s390/Kconfig |5 +
drivers/s390/guest/Makefile
-By: Carsten Otte [EMAIL PROTECTED]
---
arch/s390/Kconfig |1 +
arch/s390/host/s390host.c | 15 +++
arch/s390/kernel/process.c |1 +
arch/s390/kernel/vtime.c | 11 ++-
include/asm-s390/thread_info.h |2 ++
5 files changed, 29 insertions
Avi Kivity wrote:
We'll want to keep a vcpu fd. If the vcpu is idle we'll be asleep in
poll() or the like, and we need some kind of wakeup mechanism.
Our userspace does idle/wakeup differently:
One cpu exits sys_s390host_sie, and the intercept code indicates a
halt with interrupts enabled
Avi Kivity wrote:
The trick I mentioned (copying a pgd entry) means:
- guest physical and host userspace are different (have different pgds)
- guest physical (offset 0) is aliased to host userspace (offset $bignum)
- guest address space is limited to 2^(12+9*3)
- the pte dirty and accessed
Avi Kivity wrote:
I must say I'm pleasantly surprised by this. I keep thinking of ppc and
ia64 as additional ports, while ignoring the big daddy of virtualization.
Thank you very much for the warm welcome :-).
Similar to the kvm interface on x86, this interface is
hardware dependent at this
This series of patches adds support for s390host. This interface can be
used to run virtual machines using s390's hardware virtualization
capability SIE. Similar to the kvm interface on x86, this interface is
hardware dependent at this time. Patches apply against 2.6.21, please
review.
We intend
Add changes to s390 memory management which are necessary to use the s390
hardware assisted virtualization facility. For this the upper halve of each
page table needs to be reserved so the hardware can save extended page status
bits for the guest and the host.
Easy solution to this is to just
===
--- /dev/null
+++ linux-2.6/arch/s390/host/s390host.c
@@ -0,0 +1,411 @@
+/*
+ * s390host.c -- hosting zSeries Linux virtual engines
+ *
+ * Copyright IBM Corp. 2007
+ * Author(s): Carsten Otte [EMAIL PROTECTED],
+ * Christian Borntraeger [EMAIL
Am Freitag, den 27.04.2007, 15:40 +0200 schrieb Carsten Otte:
This series of patches adds support for s390host.
I forgot to mention: this set of patches is licensed under the terms of
the GNU general public license. Future versions of these patches will
contain the corresponding header
Hollis Blanchard wrote:
So if I understand correctly, this work is totally separate from KVM, but
you're posting for comment and intend to merge with KVM in the future.
Actually we started working on this quite long before kvm came up back
in 2005 as prototype work. Our approach however seems
201 - 267 of 267 matches
Mail list logo
