Carsten Otte wrote:
System call latency adds to the in-kernel approach here.
I don't understand this.
What I meant to state was: If the host side of the block driver runs
in userspace, we have the extra latency to leave the kernel system
call context, compute on behalf of the user process,
Gregory Haskins wrote:
Later we'll have vcpu and thread_info point to each other and then you
can do that kind of optimization.
I am not familiar with thread_info, but if it solves the dangling pointer
problem, that sounds great.
It's fairly tricky, but it's the right way forward.
Gregory Haskins wrote:
On Tue, May 15, 2007 at 3:45 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
Signed- off- by: Gregory Haskins [EMAIL PROTECTED]
---
drivers/kvm/kvm.h |1 +
drivers/kvm/kvm_main.c | 52
Davide Libenzi wrote:
On Tue, 15 May 2007, Gregory Haskins wrote:
On Tue, May 15, 2007 at 3:45 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
Signed- off- by: Gregory Haskins [EMAIL PROTECTED]
---
Gregory Haskins wrote:
Newer userspace may run on an older kernel. Therefore we need a way to
check the capabilities of the kernel so that we can downgrade userspace
dynamically if necessary
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 19 +++
Gregory Haskins wrote:
@@ -1045,7 +1054,7 @@ static CPUWriteMemoryFunc *ioapic_mem_write[3] = {
ioapic_mem_writel,
};
-IOAPICState *ioapic_init(void)
+IOAPICState *ioapic_init(CPUState *env)
{
IOAPICState *s;
int io_memory;
@@ -1054,6 +1063,7 @@ IOAPICState
Anthony Liguori wrote:
Gregory Haskins wrote:
While KVM will inevitably start requiring newer kernel versions, do we
really need to do it right now? Perhaps we could add dummy eventfd_*
functions to the module compat header? Then at least older kernels will
continue to work with in-
Davide Libenzi wrote:
On Tue, 15 May 2007, Christoph Hellwig wrote:
On Tue, May 15, 2007 at 12:18:17PM -0400, Gregory Haskins wrote:
On Tue, May 15, 2007 at 11:40 AM, in message
[EMAIL PROTECTED], Davide Libenzi
[EMAIL PROTECTED] wrote:
I don't know how
Gregory Haskins wrote:
Changelog:
1) Incorporated Anthony's feedback regarding the missed use_kernel_apic()
2) Added a new patch to allow new userspace on old kernels
All good.
--
error compiling committee.c: too many arguments to function
On Wed, May 16, 2007 at 6:05 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
Later we'll have vcpu and thread_info point to each other and then you
can do that kind of optimization.
I am not familiar with thread_info, but if it solves
On Wed, May 16, 2007 at 7:51 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
@@ - 1045,7 +1054,7 @@ static CPUWriteMemoryFunc *ioapic_mem_write[3] = {
ioapic_mem_writel,
};
- IOAPICState *ioapic_init(void)
+IOAPICState
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
This is
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 to
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 -
Gregory Haskins wrote:
diff -- git a/qemu/qemu- kvm.c b/qemu/qemu- kvm.c
index 59e79bf..6096f21 100644
--- a/qemu/qemu- kvm.c
+++ b/qemu/qemu- kvm.c
@@ - 697,6 +697,25 @@ int kvm_qemu_init()
int kvm_qemu_create_context(void)
{
int i;
+uint64_t ext;
+
+if
On Wed, 16 May 2007 15:51:27 +0200,
Carsten Otte [EMAIL PROTECTED] wrote:
+static int priv_chsc(struct zlcpu *cpu)
+{
+
+ debug(cpu %d: channel subsystem call at %lx, cpu-cpuno,
cl_get_psw(cpu).addr);
+ setcc(cpu, 3);
Actually, while this works for a Linux guest, this is not quite
Avi Kivity wrote:
This looks nicer, however I get an oops on fxrstor in
kvm_load_guest_fpu(), when running user/test/vmexit.flat compiled for
i386, on an x86_64 host.
Avi:
Per your guideline, I did following under kvm-userspace/user:
1: make test/bootstrap
2: make
Avi Kivity wrote:
Gregory Haskins wrote:
As of May 1st I could boot 64 bit SLED. As of yesterday, it
exceptions immediately in the bootloader. This happens both with
and without my APIC patches applied.
Any idea of what checkin was the cause? At least, which release was
Dong, Eddie wrote:
Avi Kivity wrote:
This looks nicer, however I get an oops on fxrstor in
kvm_load_guest_fpu(), when running user/test/vmexit.flat compiled for
i386, on an x86_64 host.
Avi:
Per your guideline, I did following under kvm-userspace/user:
1: make
On Wed, May 16, 2007 at 12:28:00PM -0500, Anthony Liguori wrote:
Eric Van Hensbergen wrote:
On 5/11/07, Anthony Liguori [EMAIL PROTECTED] wrote:
There's definitely a conversation to have here. There are going to be a
lot of small devices that would benefit from a common transport
On 5/16/07, Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.
From a functional standpoint I don't have a huge problem with it,
particularly if
On Wed, May 16, 2007 at 1:28 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.
FYI: The work I am doing
Gregory Haskins wrote:
On Wed, May 16, 2007 at 1:28 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the
Eric Van Hensbergen wrote:
On 5/16/07, Anthony Liguori [EMAIL PROTECTED] wrote:
What do you think about a socket interface? I'm not sure how discovery
would work yet, but there are a few PV socket implementations for Xen at
the moment.
From a functional standpoint I don't have a huge
An updated specification (Rev 1.0 update) of Intel(r) virtualization
technology for Directed I/O is now available on Intel web site:
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di
rect_IO.pdf
The specification update includes DMA remapping capability, Interrupt
Hi,
I'm using a somewhat old kernel with KVM (KVM included in the kernel).
I think it may be KVM-17 or something like that. Anyway, I got an OOPS
in the module while attempting to install Windows Server 2003 Standard
Edition 32-bit.
I just started it with
kvm -no-acpi -cdrom w2k3.iso w2k3.img
Gregory Haskins wrote:
On Wed, May 16, 2007 at 2:39 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
On Wed, May 16, 2007 at 1:28 PM, in message [EMAIL PROTECTED],
Anthony Liguori [EMAIL PROTECTED]
On Wed, 16 May 2007, Avi Kivity wrote:
IMO doing eventfd_fget() asap is best. I much prefer refcounted pointers to
handles in the kernel: it's easier to see what things point to, and there is
to context needed for dereferencing.
There are concerns (from Al and Christoph) about file lifetime
Hi Avi,
I was playing with KVM while booting SuSE Linux 10.1 on it. And I found
it was bailing out with #SS fault. I root caused it to the address size
override opcode (0x67) from a mov instruction from the boot loader.
The attached patch handles the #SS(0) fault with emulation, letting
guest
Hello,
I have the same problem with Linux which is using isolinux,
such as Ubuntu. I checked the BIOS in the latest KVM and
I found that it seemed to be missing the following change.
http://bochs.cvs.sourceforge.net/bochs/bochs/bios/rombios.c?view=log#rev1.172
I can boot isolinux on the
On Wed, 2007-05-16 at 14:10 -0500, Anthony Liguori wrote:
For the host, you can probably stay entirely within QEMU. Interguest
communication would be a bit tricky but guest-host communication is
real simple.
guest-host is always simple. But it'd be great if it didn't matter to
the guest
32 matches
Mail list logo
