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
Carsten Otte wrote:
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
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
Carsten Otte wrote:
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
Carsten Otte wrote:
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().
Ah ok. The kernel signal (or fd readiness) logic takes care of this
Hollis Blanchard wrote:
I think we can start the syscall based API (with compatibility ioctls
for x86), now that we have all four archs looking at it.
It would probably make sense for the IA64 and S390 folks, who already have
syscall-based implementations, to put up a straw man
On Sun, 29 Apr 2007 11:45:33 +0300, Avi Kivity wrote:
Heiko Carstens wrote:
We intend to move to a common arch-independent kernel interface and
userspace with kvm.
The address space and vcpu management are rather different from kvm's,
however your approach is better and we'll want to
To investigate PowerPC support I did some work to refactor the KVM code
into x86 vs shared bits. It was based on the in-kernel KVM code, so I need
to rebase that work on kvm.git. I guess you guys have the same
problem; have you done any work in that area?
We haven't done anything yet to make
Heiko Carstens wrote:
We intend to move to a common arch-independent kernel interface and
userspace with kvm.
The address space and vcpu management are rather different from kvm's,
however your approach is better and we'll want to move kvm in your
direction rather than the other way
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
Carsten Otte wrote:
Can one do the equivalent of a futex wakeup from the kernel easily?
No, we did not have the need to do that. Now that you mention it, we'd
want to move interprocessor signal handling into the kernel anyway for
performance reasons. That would rise the need to wake up
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
Carsten Otte wrote:
Our implementation does use action bits preseted to sys_s390host_sie
to update the hardware control blocks for the virutal machine. The
hardware control blocks would be mapped read-only to user address
space. This way, the kernel can enforce the user not to mess things
Carsten Otte wrote:
This series of patches adds support for s390host. This interface can be
used to run virtual machines using s390's hardware virtualization
capability SIE.
I must say I'm pleasantly surprised by this. I keep thinking of ppc and
ia64 as additional ports, while ignoring the
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
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.
On Fri, 27 Apr 2007 15:40:24 +0200, Carsten Otte wrote:
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
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
Carsten Otte wrote:
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
21 matches
Mail list logo
