* Ian Pratt [EMAIL PROTECTED] wrote:
Sigh, I don't really want to have this fight again.
i dont remember us having discussed this before, ever. If there's any
fight about monotonicity and SMP then it would be a pretty onesided
affair, with you being beaten up seriously ;-)
* Dan Hecht [EMAIL PROTECTED] wrote:
but if there's a perfect TSC available (there is such hardware) then
the TSC _is_ the best clocksource. Paravirt now turns it off
unconditionally in essence.
Not really. In the case hardware TSC is perfect, the paravirt time
counter can be
* Rusty Russell [EMAIL PROTECTED] wrote:
No. tsc is very good, it's not perfect. If a paravirt clock
registers 400 it really means pick me over the tsc.
often the TSC is not perfect, but _IF_ it's perfect, using the paravirt
driver is a pessimisation in performance.
the main problem at
Avi Kivity wrote:
David Brown wrote:
I thought I'd try out the realtime patch set and it didn't work at all
with kvm. The console didn't dump anything and the system completely
locked up.
Up to now, the unmodified kvm module never worked with any RT kernel.
This would only change, if RT
It seems nice !
But is there any documentation ? I don't know how-to start it.
-Alexey
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and
Hi,
I wanted to use network with --mac optin of kvm script on guest,
but I didn't use it because I didn't know needing to copy some scripts.
I think it is better that we can use --mac option after make install.
So I modified install section in the Makefile.
Signed-off-by: Akio Takebe [EMAIL
-Original Message-
From: [EMAIL PROTECTED] on behalf of Akio Takebe
Sent: Tue 10/30/2007 2:29 AM
To: kvm-devel@lists.sourceforge.net
Subject: [kvm-devel] [Patch] adding some scripts at installing
Hi,
I wanted to use network with --mac optin of kvm script on guest,
but I didn't use it
Carsten Emde wrote:
Avi Kivity wrote:
David Brown wrote:
I thought I'd try out the realtime patch set and it didn't work at all
with kvm. The console didn't dump anything and the system completely
locked up.
Up to now, the unmodified kvm module never worked with any RT kernel.
This would
On Oct 30, 2007, at 10:49 AM, Jan Kiszka wrote:
Carsten Emde wrote:
Avi Kivity wrote:
David Brown wrote:
I thought I'd try out the realtime patch set and it didn't work
at all
with kvm. The console didn't dump anything and the system
completely
locked up.
Up to now, the unmodified
Hi,
This patch fix make rpm.
When I used the rpm option, I got some error.
So I fixed it, but it is a just sample?
What do you think about it?
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
---
--- kvm-49/Makefile 2007-10-29 02:14:57.0 +0900
+++ kvm-49.mod/Makefile 2007-10-30
Hi, Alexey
Yes, that would be better.
However, I found that when using multiple virtual bridges (via brctl),
you need to have several script files.
Thank you for your comment.
Are there any other necessary files not including in my patch?
I may forgot some files because my machine is installed
On Tuesday 30 October 2007 18:37:36 Ingo Molnar wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
No. tsc is very good, it's not perfect. If a paravirt clock
registers 400 it really means pick me over the tsc.
often the TSC is not perfect, but _IF_ it's perfect, using the paravirt
driver
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Carsten Otte
Sent: 2007年10月26日 20:02
To: Avi Kivity; Zhang, Xiantao; Hollis Blanchard
Cc: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
This patch
Dong, Eddie wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Carsten Otte
Sent: 2007年10月26日 20:02
To: Avi Kivity; Zhang, Xiantao; Hollis Blanchard
Cc: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] RFC/patch portability:
Jan Kiszka wrote:
Interesting result - you've read about the wbinvd issues? Is there no
wbinvd in the bios shipped with older kvm? Which VM extension did you
test, both Intel and AMD? I would bet that your X issues are due to the
same effect. X startup/shutdown involves a lot of wbinvd calls
Hollis Blanchard wrote:
Move libkvm into its own directory. No functional changes.
Applied, thanks.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk
Akio Takebe wrote:
Hi,
Hi,
I wanted to use network with --mac optin of kvm script on guest,
but I didn't use it because I didn't know needing to copy some scripts.
I think it is better that we can use --mac option after make install.
So I modified install section in the Makefile.
Dong, Eddie wrote:
Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec
which
I assume to be generic though S390 may not take.
ACPI is not present on s390 and ppc. In fact, I doubt it is present on
any architecture except those two intel ones: at least my mips router
Avi Kivity wrote:
Jan Kiszka wrote:
Interesting result - you've read about the wbinvd issues? Is there no
wbinvd in the bios shipped with older kvm? Which VM extension did you
test, both Intel and AMD? I would bet that your X issues are due to the
same effect. X startup/shutdown involves a
OK, so how can a device inform kernel for an IRQ in S390?
-Original Message-
From: Carsten Otte [mailto:[EMAIL PROTECTED]
Sent: 2007年10月30日 19:30
To: Dong, Eddie
Cc: Avi Kivity; Zhang, Xiantao; Hollis Blanchard;
kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] RFC/patch
Jan Kiszka wrote:
Avi Kivity wrote:
Jan Kiszka wrote:
Interesting result - you've read about the wbinvd issues? Is there no
wbinvd in the bios shipped with older kvm? Which VM extension did you
test, both Intel and AMD? I would bet that your X issues are due to the
same effect. X
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Izik Eidus
Sent: 2007年10月29日 19:36
To: Yang, Sheng
Cc: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] [PATCH] KVM: VMX: Enable memory
mappedTPR shadow(FlexPriority)
On Mon, 2007-10-29 at
Avi Kivity wrote:
Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec
which
I assume to be generic though S390 may not take.
ia64 can probably share much. ppc will probably want KVM_IRQ_LINE with
with different parameters. s390, as far as I understand, will
Dong, Eddie wrote:
From: Sheng Yang [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 09:40:42 +0800
Subject: [PATCH] KVM: VMX: Enable memory mapped TPR
shadow(FlexPriority)
This patch based on CR8/TPR patch, and enable the TPR
shadow(FlexPriority)
for 32bit Windows. Since TPR is
Carsten Otte wrote:
I think we'll have to come up with a more modular approach later on:
various aspects are of interest to various architectures and/or
platforms. The generic kernel has CONFIG_FEATURE toggles for that.
The portability patches are not intended to split kvm into components
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zachary Amsden escreveu:
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and accurate to do so.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar escreveu:
* Rusty Russell [EMAIL PROTECTED] wrote:
and just in case it's not obvious: i am not arguing for the inclusion of
the patch, i'm just pointing out the plain fact that in the case where
the TSC _is_ reliable, 5 different
Hi, Avi
Thank you for your comments.
This patch fix make rpm.
When I used the rpm option, I got some error.
So I fixed it, but it is a just sample?
'make rpm' works for me on F7 (after I fixed fallout from the libkvm
separation patch). What distribution did you run it on? What error
Dong, Eddie wrote:
OK, so how can a device inform kernel for an IRQ in S390?
Oooh, that is a looong explanation. If you want to peek at it, see
http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf . Chapter 6
covers Interruptions. I'd recommend to start with reading external
interruptions,
Akio Takebe wrote:
Hi, Avi
Thank you for your comments.
This patch fix make rpm.
When I used the rpm option, I got some error.
So I fixed it, but it is a just sample?
'make rpm' works for me on F7 (after I fixed fallout from the libkvm
separation patch). What
Avi Kivity wrote:
But that doesn't make the code portable. The s390 userspace has to know
how to encode the number, and x86 will do it differently.
If it's really different, let's keep it different. Unless you can push
the encoding so far back it's transparent to userspace (e.g. qemu).
I
Carsten Otte wrote:
In addition, I would love to be able to specify which target CPUs
may receive that interrupt because our IPI equivalent comes out just
like a regular interrupt on just one target CPU.
That boils down to something like this:
struct kvm_interrupt_data {
__u64
Avi Kivity wrote:
A bitmap would do it, but what size? Expandable ones are messy.
We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific
header files that go to include/asm/. For s390, we have one of our
rocket science virtualization accelerating facilities that limits us
to 64 cpus
Carsten Otte wrote:
Avi Kivity wrote:
A bitmap would do it, but what size? Expandable ones are messy.
We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific
header files that go to include/asm/. For s390, we have one of our
rocket science virtualization accelerating facilities
* Alexey Eremenko [EMAIL PROTECTED] [2007-10-30 04:26]:
It seems nice !
But is there any documentation ? I don't know how-to start it.
Have you read the wiki page?
http://kvm.qumranet.com/kvmwiki/KVMTest
basically, you want to use kvm-test-record where you would normally use
qemu. So,
-Original Message-
From: Ryan Harper [mailto:[EMAIL PROTECTED]
Sent: Tue 10/30/2007 7:46 AM
To: Alexey Eremenko
Cc: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] Question about KVM-test
* Alexey Eremenko [EMAIL PROTECTED] [2007-10-30 04:26]:
It seems nice !
But is
[EMAIL PROTECTED] wrote:
Avi Kivity wrote:
A bitmap would do it, but what size? Expandable ones are messy.
We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific
header files that go to include/asm/. For s390, we have one of our
rocket science virtualization accelerating facilities
On Tue, 2007-10-30 at 13:59 +0200, Avi Kivity wrote:
-/usr/kvm
+%dir /usr/kvm
+%dir /usr/kvm/bin
+/usr/kvm/bin/qemu-img
+/usr/kvm/bin/qemu-system-x86_64
[...]
Why is this change necessary? Doesn't '/usr/kvm' work? This way,
every time qemu adds a file we have to update the rpm
Dong, Eddie wrote:
IA64/KVM will handle interrupt in kernel including IPI IMO, so what
user level need to tell kernel is which platform IRQ pin is set/cleared.
Can't S390 do in similar way? From platform point of view, each
irq can have a unique # and the device itself doesn;t need to know
* Alexey Eremenko [EMAIL PROTECTED] [2007-10-30 10:11]:
-Original Message-
From: Ryan Harper [mailto:[EMAIL PROTECTED]
Sent: Tue 10/30/2007 7:46 AM
To: Alexey Eremenko
Cc: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] Question about KVM-test
* Alexey Eremenko
This patch moves the implementation of the functions of kvm_get/set_msr,
kvm_get/set_msr_common, and set_efer from kvm_main.c to x86.c. The
definition of EFER_RESERVED_BITS is moved too.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
kvm_main.c | 133
Thanks to Xiantao and Hollis for your quick review of last patch series.
Thanks Avi for finding time to pick up last patches on your trip to
Japan.
This series of patches moves more code from kvm_main.c to x86.c. I start
seeing the light at the end of the tunnel, I think these should be the
last
This patch moves implementation of the following functions from
kvm_main.c to x86.c:
free_pio_guest_pages, vcpu_find_pio_dev, pio_copy_data, complete_pio,
kernel_pio, pio_string_write, kvm_emulate_pio, kvm_emulate_pio_string
The function inject_gp, which was duplicated by yesterday's patch
On Tue, 2007-10-30 at 18:44 +0100, Carsten Otte wrote:
-/*
- * Only apic need an MMIO device hook, so shortcut now..
- */
-static struct kvm_io_device *vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
-{
- struct kvm_io_device
On Tue, 2007-10-30 at 18:44 +0100, Carsten Otte wrote:
This patch moves implementation of the following functions from
kvm_main.c to x86.c:
free_pio_guest_pages, vcpu_find_pio_dev, pio_copy_data, complete_pio,
kernel_pio, pio_string_write, kvm_emulate_pio, kvm_emulate_pio_string
The
Carsten Otte wrote:
Thanks to Xiantao and Hollis for your quick review of last patch
series. Thanks Avi for finding time to pick up last patches on your
trip to Japan.
This series of patches moves more code from kvm_main.c to x86.c. I
start seeing the light at the end of the tunnel, I think
I know you hate junk mail, but this is just plane old fun.
http://75.20.182.164/
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and
Zhang, Xiantao wrote:
Basically, It doesn't impact our side. For patch 2/3, we had better find
an approach to handle mmio-realted functions, becasue they may exist in
most archs.
For IA64, if this move happens, we have to duplicate them in IA64 side.
Thanks for your feedback. This matches
On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote:
Zhang, Xiantao wrote:
Basically, It doesn't impact our side. For patch 2/3, we had better find
an approach to handle mmio-realted functions, becasue they may exist in
most archs.
For IA64, if this move happens, we have to duplicate
Hollis Blanchard wrote:
On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote:
Zhang, Xiantao wrote:
Basically, It doesn't impact our side. For patch 2/3, we had better find
an approach to handle mmio-realted functions, becasue they may exist in
most archs.
For IA64, if this move happens,
Hi Avi,
Attached is the patch to implement mul instruction from the group 3
opcodes.
Please Apply.
--
Thanks Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better
Carsten Otte wrote:
Thanks to Xiantao and Hollis for your quick review of last patch series.
Thanks Avi for finding time to pick up last patches on your trip to
Japan.
This series of patches moves more code from kvm_main.c to x86.c. I start
seeing the light at the end of the tunnel, I think
Hi Avi,
Attached is the patch to implement emulation of instruction aas
please apply.
--
Thanks Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when
Hi Avi,
Attached is the patch to implement emulation of further xchg
instructions.
--
Thanks Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when
Hi Avi,
Attached is the patch to implement emulation of instruction:
jb (opcode 0xe3)
Please apply.
--
Thanks Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better
Hi Avi,
Attached is the patch to implement emulation of instructions
mov rl, imm8 (opcodes 0xb0-0xb3)
mov rh, imm8 (opcodes 0xb4-0xb7)
mov r, imm (opcodes0xb8-0xbf)
please apply.
--
Thanks Regards,
Nitin
Open Source Technology Center, Intel Corporation
Dong, Eddie wrote:
Yes. FlexPriority will be both faster and safer for those who have it
than my hack.
It may turn out that patching can improve performance even with
FlexPriority: we can patch the APIC EOI write to look if any
interrupts are pending, and only exit if the EOI will result in
Hollis Blanchard wrote:
On Tue, 2007-10-30 at 13:59 +0200, Avi Kivity wrote:
-/usr/kvm
+%dir /usr/kvm
+%dir /usr/kvm/bin
+/usr/kvm/bin/qemu-img
+/usr/kvm/bin/qemu-system-x86_64
[...]
Why is this change necessary? Doesn't '/usr/kvm' work? This way,
every time qemu adds a
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instruction aas
+ case 0x3f: /* aas */ {
+ u8 al, ah, af, cf;
+ al = c-regs[VCPU_REGS_RAX] 0xff;
+ ah = (c-regs[VCPU_REGS_RAX] 8) 0xff;
+ af =
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instructions
stc (opcode 0xf9)
cld (opcode 0xfc)
+ case 0xfc: /* cld */
+ ctxt-eflags |= X86_EFLAGS_DF;
+ c-dst.type = OP_NONE; /* Disable writeback. */
+
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instruction:
jb (opcode 0xe3)
[PATCH] Implement emulation of instruction jb (conditional jump)
opcodes: 0xe3
From:
Nitin A Kamble [EMAIL PROTECTED]
To:
Date:
2007-10-31 05:41
Signed-off-by:
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement mul instruction from the group 3
opcodes.
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 3959c20..5815128 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1034,6
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instructions
mov rl, imm8 (opcodes 0xb0-0xb3)
mov rh, imm8 (opcodes 0xb4-0xb7)
mov r, imm (opcodes0xb8-0xbf)
@@ -146,8 +146,12 @@ static u16 opcode_table[256] = {
0, 0, ByteOp | ImplicitOps |
Tim Dempsey wrote:
Avi,
I have subscribed to the mailing list, so hopefully my responses will
be threaded.
You don't actually need to subscribe for that. Simply hitting
reply-to-all every time should work.
The patch you sent appeared to work initially. But when I repeated the install
Carsten Otte wrote:
Hollis Blanchard wrote:
On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote:
Zhang, Xiantao wrote:
Basically, It doesn't impact our side. For patch 2/3, we had
better find an approach to handle mmio-realted functions, becasue
they may exist in most archs. For IA64, if
Hollis Blanchard wrote:
On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote:
Zhang, Xiantao wrote:
Basically, It doesn't impact our side. For patch 2/3, we had better
find an approach to handle mmio-realted functions, becasue they may
exist in most archs. For IA64, if this move happens, we
On Tue, 2007-10-30 at 17:53 -0700, Avi Kivity wrote:
This is missing a break;.
Hi Avi,
You are right. The break statement should be there. It was my mistake
while getting the patch out from the test tree to the push tree. Even if
it is a small patch I should not retype it.
How are you
On Tue, 2007-10-30 at 18:06 -0700, Avi Kivity wrote:
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instructions
mov rl, imm8 (opcodes 0xb0-0xb3)
mov rh, imm8 (opcodes 0xb4-0xb7)
mov r, imm (opcodes0xb8-0xbf)
@@ -146,8 +146,12 @@ static u16
On Tue, 2007-10-30 at 18:02 -0700, Avi Kivity wrote:
This is 'cld', but it looks like you're setting DF?
Good catch. Same problem hand copy of the patch.
It should look like this.
+ case 0xfc: /* cld */
+ ctxt-eflags = ~EFLG_DF;
--
Thanks Regards,
Nitin
Open Source
69 matches
Mail list logo
