On 04/24/2011 01:50 AM, OGAWA Hirofumi wrote:
OGAWA Hirofumihirof...@mail.parknet.co.jp writes:
I noticed recently NMI on guest kernel is not working well. host/guest
kernel is 2.6.39-rc4, and using vmx.
And test code is something like the following:
local_irq_disable();
for
On 04/21/2011 10:16 PM, Clemens Noss wrote:
Commit 0b56652e33c72092956c651ab6ceb9f0ad081153 fails to build:
CC [M] arch/x86/kvm/emulate.o
arch/x86/kvm/emulate.c: In function 'x86_emulate_insn':
arch/x86/kvm/emulate.c:4095:25: error: macro wbinvd passed 1 arguments, but
takes just 0
Hello everybody,
I have a problem with an opcode emulation not yet emulated in kvm-kmod
2.6.38-rc7.
The opcode is the LEAVE that as Intel Manual says:
Set RSP to RBP, then pop RBP
The problem is that despite to the fact that the opcode of the leave
(C9) is correctly fetched and decoded, it falls
On 04/21/2011 06:43 PM, Jan Kiszka wrote:
On 2011-04-21 16:10, Yaniv Kaul wrote:
Fedora 15beta/x64, latest git:
[ykaul@ykaul qemu]$ make
CCx86_64-softmmu/kvm.o
/home/ykaul/qemu/target-i386/kvm.c: In function ‘kvm_get_xsave’:
/home/ykaul/qemu/target-i386/kvm.c:953:29: error:
On 04/21/2011 07:09 PM, Randy Dunlap wrote:
From: Randy Dunlaprandy.dun...@oracle.com
arch/x86/kvm/emulate.c:2598: warning: integer constant is too large for 'long'
type
Applied, thanks.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
On 04/24/2011 10:08 AM, Matteo Signorini wrote:
Hello everybody,
I have a problem with an opcode emulation not yet emulated in kvm-kmod
2.6.38-rc7.
The opcode is the LEAVE that as Intel Manual says:
Set RSP to RBP, then pop RBP
The problem is that despite to the fact that the opcode of the
On 04/21/2011 01:06 PM, brill...@viatech.com.cn wrote:
So,the conclusion is:
Only VIA C7 CPUs have dependency on EFLAGS[30], but they do not support VT-X
technology, so kvm can not run on it and the issue about EFLAGS[30] will not
occur.
VIA Nano CPUs support VT-X technology and can run kvm,
On 04/21/2011 06:34 PM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawayoshikawa.tak...@oss.ntt.co.jp
This patch optimizes the guest page table walk by using get_user()
instead of copy_from_user().
With this patch applied, paging64_walk_addr_generic() has become
about 0.5us to 1.0us faster on
On 04/23/2011 12:45 PM, Takuya Yoshikawa wrote:
Changelog v1-v2:
- Dropped push sreg part.
- Covered CMPS and SCAS
- Removed useless emulate_* functions
- Replaced D6ALU macro with I6ALU
- Various rebases.
I also updated the titles and changelogs to be consistent with
Avi's
On Sun, Apr 24, 2011 at 12:38 AM, Ryan Wang openspace.w...@gmail.com wrote:
I read some writings on the qemu, and found some demo examples use the
command qemu, some use kvm, and some mention the qemu-kvm?
I wonder are there any difference between these commands? Or they just
point to the
On Sun, Apr 24, 2011 at 12:17 AM, Jagane Sundar jag...@sundar.org wrote:
I would like to get your input on a KVM feature that I am
currently developing.
What it does is this - it can perform full and incremental
disk backups of running KVM VMs, where a backup is defined
as a snapshot of the
Avi Kivity a...@redhat.com writes:
With some debug, the cause seems to be in pit_do_work(). With the
following patch, NMI watchdog seems to be working correctly (if irq
disabled for long time, NMI watchdog can detect it).
Is the following patch right?
This would cause IRQs to be delivered
walk_addr_generic() is a hot path and is also hard for the cpu to predict -
some of the parameters (fetch_fault in particular) vary wildly from
invocation to invocation.
Add unlikely() annotations where appropriate; all walk failures are
considered unlikely, as are cases where we have to mark the
On 2011-04-24 11:17, OGAWA Hirofumi wrote:
Avi Kivity a...@redhat.com writes:
With some debug, the cause seems to be in pit_do_work(). With the
following patch, NMI watchdog seems to be working correctly (if irq
disabled for long time, NMI watchdog can detect it).
Is the following patch
Jan Kiszka jan.kis...@web.de writes:
Yes, this is old kernel (2.6.9), and is not using HPET
(CONFIG_HPET_TIMER=n), using IO-APIC as NMI source (PMU seems to be
unsupported on kvm for now).
Unfortunately, -no-hpet didn't change situation. irq_stat.apic_timer_irqs
and nmi_count() are same
OGAWA Hirofumi hirof...@mail.parknet.co.jp writes:
Maybe it's a regression of latest NMI injection patches.
This worked before? Can you check if commits
c2dd554dc61173ecb6b3741b680d2ae4c245d2ba and
f86368493ec038218e8663cc1b6e5393cd8e008a have any impact on your problem?
Unfortunately, no.
Move all groups into a single field and handle them in a single place. This
saves bits when we add more group types (3 bits - 7 groups types).
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/emulate.c | 80
1 files changed, 40
On 2011-04-24 08:44, Avi Kivity wrote:
On 04/24/2011 01:50 AM, OGAWA Hirofumi wrote:
OGAWA Hirofumihirof...@mail.parknet.co.jp writes:
I noticed recently NMI on guest kernel is not working well.
host/guest
kernel is 2.6.39-rc4, and using vmx.
And test code is something like the
This patch bumps host to guest tcp bandwidth from
1060 Mib/s to 1760 Mib/s,
and guest to host tcp bandwidth from
342 Mib/s to 619 Mib/s.
*
Without TSO and UFO
*
(guest - host)
root@sid1:~# iperf -s
On 2011-04-24 08:44, Avi Kivity wrote:
On 04/24/2011 01:50 AM, OGAWA Hirofumi wrote:
OGAWA Hirofumihirof...@mail.parknet.co.jp writes:
I noticed recently NMI on guest kernel is not working well.
host/guest
kernel is 2.6.39-rc4, and using vmx.
And test code is something like the
dump_vmcb isn't used outside this module, make it static.
Shrink text and object by ~1% by standardizing formats.
$ size arch/x86/kvm/svm.o*
textdata bss dec hex filename
52910 580 10072 63562f84a arch/x86/kvm/svm.o.new
53563 580 10072 64215fad7
On 04/21/2011 01:06 PM, brill...@viatech.com.cn wrote:
So,the conclusion is:
Only VIA C7 CPUs have dependency on EFLAGS[30], but they do
not support VT-X technology, so kvm can not run on it and the issue
about EFLAGS[30] will not occur.
VIA Nano CPUs support VT-X technology and can
22 matches
Mail list logo