From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index b8da671..7397932 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -151,6 +151,9 @@ module_param(oos_shadow, bool, 0644);
#define ACC_USER_MASK
From: Avi Kivity a...@redhat.com
vmx can allow many bits to be owned by the guest, need to detail them all
to avoid kvm_read_cr4() failures.
Fixes Linux -smp 2 -no-kvm-irqchip failures.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/kvm_cache_regs.h
From: Wei Yongjun yj...@cn.fujitsu.com
If fail to create pit, we should unregister kvm irq notifier
which register in kvm_create_pit().
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
Acked-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git
From: Liu Yu yu@freescale.com
Old method prematurely sets ESR and DEAR.
Move this part after we decide to inject interrupt,
which is more like hardware behave.
Signed-off-by: Liu Yu yu@freescale.com
Acked-by: Hollis Blanchard hol...@penguinppc.org
Acked-by: Alexander Graf ag...@suse.de
From: Wei Yongjun yj...@cn.fujitsu.com
If KVM_CREATE_IRQCHIP fail due to kvm_setup_default_irq_routing(),
ioapic device is not destroyed and kvm-arch.vioapic is not set to
NULL, this may cause KVM_GET_IRQCHIP and KVM_SET_IRQCHIP access to
unexcepted memory.
Signed-off-by: Wei Yongjun
From: Wei Yongjun yj...@cn.fujitsu.com
kvm-arch.vioapic should be NULL in case of kvm_ioapic_init() failure
due to cannot register io dev.
Signed-off-by: Wei Yongjun yj...@cn.fujitsu.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index
Following the new SDM. Now the bit is named Ignore PAT memory type.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/include/asm/vmx.h |2 +-
arch/x86/kvm/vmx.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/vmx.h
Alexander Graf wrote:
On 09.02.2010, at 07:56, Avi Kivity wrote:
- rcuify/fine-grain qemu locks
And this should be done either way, but is probably not a short-term goal.
Indeed. We won't get around this longterm as it is a scalability
bottleneck and a killer for RT guest load. We can't
Bugs item #2948108, was opened at 2010-02-08 23:06
Message generated for change (Comment added) made by mrt2k9
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2948108group_id=180599
Please note that this message will contain a full copy of the comment
On 02/09/2010 10:41 AM, Sheng Yang wrote:
Following the new SDM. Now the bit is named Ignore PAT memory type.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
Thank you for your comments. We have implemented the code which applied your
comments. This is patch for qemu-kvm.c.
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
qemu-kvm.c | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git
Thank you for your comments. We have implemented the code which applied your
comments. This is patch for upstream.
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
kvm-all.c | 54 +++---
1 files changed, 39 insertions(+), 15 deletions(-)
On 02/09/2010 11:54 AM, OHMURA Kei wrote:
Thank you for your comments. We have implemented the code which applied your
comments. This is patch for qemu-kvm.c.
Please reuse the changelog when reposing a patch, this makes it easier
for me to apply it.
@@ -2438,27 +2438,34 @@ static int
On 02/09/2010 08:40 AM, Tsuyoshi Ozawa wrote:
Build fix for #define KVM_DEBUG
If KVM_DEBUG is defined, the build for kvm_kmod is failed because :
1. is_long_mode() has moved to x86.h.
2. shadow_efer no longer exists.
3. The registers R8 - R15 don't exist on i386 architecture.
This patch fix
On 02/01/2010 12:37 PM, Nikola Ciprich wrote:
Hello,
it seems to me that after upgrading to some 2.6.32.x release, KSM stopped
working
for me. I'm not exactly sure which update did this, but enabling KSM doesn't
seem to do anything, ksmd process just sleeps and doesn't merge any memory.
Early
shadow_efer was renamed to efer, so this should be modified rather than
deleted.
OK. The new patch uses efer instead of deleting shadow_efer :
Signed-off-by: Tsuyoshi Ozawa oz...@t-oza.net
---
x86/vmx-debug.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
Avi Kivity wrote:
On 02/08/2010 12:02 AM, Alexander Graf wrote:
It's not a good idea for the kernel either, if it happens all the
time. If a typical Gekko application uses the fpu and the emulated
instructions intensively, performance will suck badly (as in: qemu/tcg
will be faster).
On 02/09/2010 01:00 PM, Alexander Graf wrote:
That's pretty impressive (never saw x86 with this exit rate) but it's
more than 1000 times slower than the hardware, assuming 1 fpu IPC (and
the processor can probably do more). An fpu intensive application
will slow to a crawl.
Measuring a
Avi Kivity wrote:
On 02/09/2010 01:00 PM, Alexander Graf wrote:
That's pretty impressive (never saw x86 with this exit rate) but it's
more than 1000 times slower than the hardware, assuming 1 fpu IPC (and
the processor can probably do more). An fpu intensive application
will slow to a
On 02/09/2010 01:13 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 02/09/2010 01:00 PM, Alexander Graf wrote:
That's pretty impressive (never saw x86 with this exit rate) but it's
more than 1000 times slower than the hardware, assuming 1 fpu IPC (and
the processor can
FYI, just brought all step file install/setups that were removed back:
http://autotest.kernel.org/changeset/4228
Also, added kickstarts for F8, F9 and F10.
On Sun, Feb 7, 2010 at 11:59 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
On Sun, 2010-02-07 at 22:44 -0200, Marcelo Tosatti wrote:
FYI, reverted:
http://autotest.kernel.org/changeset/4227
On Sun, Feb 7, 2010 at 11:11 PM, Lucas Meneghel Rodrigues
l...@redhat.com wrote:
On Sun, 2010-02-07 at 12:59 -0500, Michael Goldish wrote:
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
The way tests are currently defined,
On Tue, 09 Feb 2010 12:51:47 +0200
Avi Kivity a...@redhat.com wrote:
On 02/01/2010 12:37 PM, Nikola Ciprich wrote:
Hello,
it seems to me that after upgrading to some 2.6.32.x release, KSM stopped
working
for me. I'm not exactly sure which update did this, but enabling KSM doesn't
seem
I have not seen response to this. If there are no objections please apply.
Thanks,
David Ahern
On 02/03/2010 09:00 AM, David S. Ahern wrote:
This fixes a segfault due to buffer overrun in the usb-serial device.
The memcpy was incrementing the start location by recv_used yet, the
computation
I have not seen a response to this. If there are no objections please apply.
Thanks,
David Ahern
On 02/03/2010 08:49 AM, David S. Ahern wrote:
I have streaming audio devices working within qemu-kvm. This is a port
of the changes to qemu.
Streaming audio generates a series of isochronous
Use groups mechanism to decode 0F BA instructions.
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 645b245..435b1e4 100644
---
Currently when x86 emulator needs to access memory, page walk is done with
broadest permission possible, so if emulated instruction was executed
by userspace process it can still access kernel memory. Fix that by
providing correct memory access to page walker during emulation.
Signed-off-by: Gleb
Add CPL checking in case emulator is tricked into emulating
privilege instruction from userspace.
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git
Instructions which are not allowed to have LOCK prefix should
generate #UD if one is used.
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c | 85 +++-
1 files changed, 48 insertions(+), 37 deletions(-)
diff --git
POPF behaves differently depending on current CPU mode. Emulate correct
logic to prevent guest from changing flags that it can't change otherwise.
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/kvm/emulate.c | 55 +++-
1 files changed, 54
Make emulator check that vcpu is allowed to execute IN, INS, OUT,
OUTS, CLI, STI.
Signed-off-by: Gleb Natapov g...@redhat.com
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/emulate.c | 18 ---
arch/x86/kvm/x86.c | 63
On 02/09/2010 12:56 AM, Avi Kivity wrote:
On 02/09/2010 03:28 AM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
hpet overhead on large smp guests
I measured hpet consuming about a half a core's worth of cpu on an
idle Windows 2008 R2 64-way guest. This
On 02/09/2010 04:18 PM, Anthony Liguori wrote:
On 02/09/2010 02:52 AM, Jan Kiszka wrote:
Alexander Graf wrote:
On 09.02.2010, at 07:56, Avi Kivity wrote:
- rcuify/fine-grain qemu locks
And this should be done either way, but is probably not a short-term
goal.
Indeed. We won't get around
On 02/09/2010 04:14 PM, Gleb Natapov wrote:
Make emulator check that vcpu is allowed to execute IN, INS, OUT,
OUTS, CLI, STI.
+bool kvm_check_iopl(struct kvm_vcpu *vcpu)
+{
+ int iopl;
+ if (!is_protmode(vcpu))
+ return false;
+ if (kvm_get_rflags(vcpu)
After I get the git tree, checking out the 0.12.2 tag, I run configure+make.
The results of the compilation are
qemu-nbd
qemu-img
qemu-io
qemu-system-x86_64
There is no qemu-kvm.
When qemu-system-x86_64 is called by libvirtd, it is called with -no-kvm flag,
resulting in emulation mode and poor
On 02/09/2010 08:38 AM, Avi Kivity wrote:
On 02/09/2010 04:18 PM, Anthony Liguori wrote:
On 02/09/2010 02:52 AM, Jan Kiszka wrote:
Alexander Graf wrote:
On 09.02.2010, at 07:56, Avi Kivity wrote:
- rcuify/fine-grain qemu locks
And this should be done either way, but is probably not a
On 02/09/2010 05:08 PM, Anthony Liguori wrote:
I'm not saying we should push hpet into the kernel to save userspace
coding effort; there should be an independent reason to do this. But
I don't think threading qemu is going to be anything near easy.
It's certainly not easy but I don't think
On 02/09/2010 05:04 PM, Dan Bar Dov wrote:
After I get the git tree, checking out the 0.12.2 tag, I run configure+make.
The results of the compilation are
qemu-nbd
qemu-img
qemu-io
qemu-system-x86_64
There is no qemu-kvm.
When qemu-system-x86_64 is called by libvirtd, it is called with -no-kvm
Bugs item #2948108, was opened at 2010-02-08 16:06
Message generated for change (Comment added) made by iggy_cav
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2948108group_id=180599
Please note that this message will contain a full copy of the comment
Bugs item #2948108, was opened at 2010-02-08 14:06
Message generated for change (Comment added) made by ramereth
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2948108group_id=180599
Please note that this message will contain a full copy of the comment
Thanks, a symlink actually worked.
Dan
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 09, 2010 at 08:38:56AM +0200, Avi Kivity wrote:
On 02/09/2010 12:41 AM, Marcelo Tosatti wrote:
On Thu, Feb 04, 2010 at 11:46:25PM +0200, Avi Kivity wrote:
On 02/04/2010 11:36 PM, Marcelo Tosatti wrote:
On Thu, Feb 04, 2010 at 09:16:47PM +0200, Avi Kivity wrote:
On 01/28/2010 09:03
Bugs item #2915201, was opened at 2009-12-15 18:35
Message generated for change (Comment added) made by iggy_cav
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2915201group_id=180599
Please note that this message will contain a full copy of the comment
Anthony Liguori wrote:
No, basically, the problem will boil down to, the IO thread is
select()'d waiting for an event to occur. However, you've done
something in the VCPU thread that requires the IO thread to run it's
main loop. You need to use qemu_notify_event() to force the IO thread
Bugs item #2948108, was opened at 2010-02-08 14:06
Message generated for change (Comment added) made by ramereth
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2948108group_id=180599
Please note that this message will contain a full copy of the comment
Tom Lendacky a écrit :
On Wednesday 20 January 2010 09:48:04 am Tom Lendacky wrote:
On Tuesday 19 January 2010 05:57:53 pm Chris Wright wrote:
* Tom Lendacky (t...@linux.vnet.ibm.com) wrote:
On Wednesday 13 January 2010 03:52:28 pm Chris Wright wrote:
(Mark cc'd,
Thanks for the patch! It seems to solve the problem that
under load ( 50 MBit/s) the network goes down. I've applied
the patch to KVM 0.12.2 running Gentoo. Host and guest is running
kernel 2.6.32 currently (kernel 2.6.30 in guest and 2.6.32 in
host works also for us).
Another host doing the same
Chris Wright a écrit :
* Jean-Philippe Menil (jean-philippe.me...@univ-nantes.fr) wrote:
it seems, that i encounter the same bug.
I've a guest with an high network load, and after some time, it seems
that there's no more network.
Under the guest, I can't ping anymore the gateway.
If i
You're right... this should be enough to avoid a stop with uncomplete
PIO (and this is what happens for MMIO already). The signal will not
be dequeued, so KVM will complete_pio and exit before entering with
-EAGAIN. Please review and queue for stable.
qemu upstream needs a bit more work.
On 8 févr. 2010, at 13:21, Avi Kivity wrote:
On 02/08/2010 01:13 PM, Jan Kiszka wrote:
I confirm that this exception does not happen with kvm-kmod-2.6.33-rc6.
However, after I run and stop a guest VM just executing the bios sequence
(no disk/CD image attached), I get this kind of errors
2010/2/7 Avi Kivity a...@redhat.com
That is basically the same error.
The guest runs the vga vios and hangs. Please try with a production
processor.
Working fine with a retail E5520. Thanks for your help.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
This patch set consists of macro replacements
and some fixes of fault handling in the x86
emulator.
Suggested by Marcelo, I separated these two
works and tried to make it clear what effects
each patch will produce: if you think that
reordering something in this series makes your
maintainance
This patch injects page fault when reading descriptor in
load_guest_segment_descriptor() fails with FAULT.
Effects of this injection: This function is used by
kvm_load_segment_descriptor() which is necessary for the
following instructions.
- mov seg,r/m16
- jmp far
- pop ?s
This patch makes it
This patch makes kvm_load_segment_descriptor() to propagate
faults generated by load_guest_segment_descriptor().
We have confirmed that unless we change x86_emulate_insn() to
handle this propagated faults, this patch has no effect.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
We change the x86_emulate_insn() to handle faults propagated
from kvm_load_segment_descriptor().
Original code checks if the return value is negative or not.
But this means nothing because kvm_load_segment_descriptor()
never returns negative value. Instead of this, we use the
rc variable to hold
This patch just replaces integer values used inside
x86_emulate_insn() and its helper functions to X86EMUL_*.
The purpose of this is to make it clear what will happen
when rc variable is compared to X86EMUL_* at the end of
x86_emulate_insn().
Signed-off-by: Takuya Yoshikawa
This patch makes non-X86EMUL_* family functions not to use
rc variable.
Be sure that this changes nothing but makes the purpose of
rc variable clearer.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/emulate.c | 15 ++-
1 files changed, 6
This patch fixes emulate_syscall(), emulate_sysenter() and
emulate_sysexit() to handle injected faults properly.
Even though original code injects faults in these functions,
we cannot handle these unless we use the different return
value from the UNHANDLEABLE case. So this patch use X86EMUL_*
This patch removes redundant prototype of load_pdptrs().
I found load_pdptrs() twice in kvm_host.h . Let's remove one.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/include/asm/kvm_host.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
On 02/09/2010 10:58 PM, Marcelo Tosatti wrote:
You're right... this should be enough to avoid a stop with uncomplete
PIO (and this is what happens for MMIO already). The signal will not
be dequeued, so KVM will complete_pio and exit before entering with
-EAGAIN. Please review and queue for
Jean-Philippe Menil a écrit :
Chris Wright a écrit :
* Jean-Philippe Menil (jean-philippe.me...@univ-nantes.fr) wrote:
it seems, that i encounter the same bug.
I've a guest with an high network load, and after some time, it
seems that there's no more network.
Under the guest, I can't
Avi Kivity wrote:
On 02/08/2010 12:02 AM, Alexander Graf wrote:
It's not a good idea for the kernel either, if it happens all the
time. If a typical Gekko application uses the fpu and the emulated
instructions intensively, performance will suck badly (as in: qemu/tcg
will be faster).
On 02/09/2010 01:00 PM, Alexander Graf wrote:
That's pretty impressive (never saw x86 with this exit rate) but it's
more than 1000 times slower than the hardware, assuming 1 fpu IPC (and
the processor can probably do more). An fpu intensive application
will slow to a crawl.
Measuring a
Avi Kivity wrote:
On 02/09/2010 01:00 PM, Alexander Graf wrote:
That's pretty impressive (never saw x86 with this exit rate) but it's
more than 1000 times slower than the hardware, assuming 1 fpu IPC (and
the processor can probably do more). An fpu intensive application
will slow to a
On 02/09/2010 01:13 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 02/09/2010 01:00 PM, Alexander Graf wrote:
That's pretty impressive (never saw x86 with this exit rate) but it's
more than 1000 times slower than the hardware, assuming 1 fpu IPC (and
the processor can
65 matches
Mail list logo
