[PATCH] Convert .flat files to 32-bit elf format
Recent qemus no longer load 64-bit elf kernels. Fix by converting to 32-bit elf. Signed-off-by: Avi Kivity a...@redhat.com --- config-x86-common.mak | 39 +-- 1 files changed, 21 insertions(+), 18 deletions(-) diff --git a/config-x86-common.mak b/config-x86-common.mak index b541c1c..c5508b3 100644 --- a/config-x86-common.mak +++ b/config-x86-common.mak @@ -20,9 +20,12 @@ CFLAGS += -m$(bits) libgcc := $(shell $(CC) -m$(bits) --print-libgcc-file-name) FLATLIBS = lib/libcflat.a $(libgcc) -%.flat: %.o $(FLATLIBS) flat.lds +%.elf: %.o $(FLATLIBS) flat.lds $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $(filter %.o, $^) $(FLATLIBS) +%.flat: %.elf + objcopy -O elf32-i386 $^ $@ + tests-common = $(TEST_DIR)/vmexit.flat $(TEST_DIR)/tsc.flat \ $(TEST_DIR)/smptest.flat $(TEST_DIR)/port80.flat \ $(TEST_DIR)/realmode.flat $(TEST_DIR)/msr.flat \ @@ -35,47 +38,47 @@ test_cases: $(tests-common) $(tests) $(TEST_DIR)/%.o: CFLAGS += -std=gnu99 -ffreestanding -I lib -I lib/x86 -$(TEST_DIR)/access.flat: $(cstart.o) $(TEST_DIR)/access.o +$(TEST_DIR)/access.elf: $(cstart.o) $(TEST_DIR)/access.o -$(TEST_DIR)/hypercall.flat: $(cstart.o) $(TEST_DIR)/hypercall.o +$(TEST_DIR)/hypercall.elf: $(cstart.o) $(TEST_DIR)/hypercall.o -$(TEST_DIR)/sieve.flat: $(cstart.o) $(TEST_DIR)/sieve.o \ +$(TEST_DIR)/sieve.elf: $(cstart.o) $(TEST_DIR)/sieve.o \ $(TEST_DIR)/vm.o -$(TEST_DIR)/vmexit.flat: $(cstart.o) $(TEST_DIR)/vmexit.o +$(TEST_DIR)/vmexit.elf: $(cstart.o) $(TEST_DIR)/vmexit.o -$(TEST_DIR)/smptest.flat: $(cstart.o) $(TEST_DIR)/smptest.o +$(TEST_DIR)/smptest.elf: $(cstart.o) $(TEST_DIR)/smptest.o -$(TEST_DIR)/emulator.flat: $(cstart.o) $(TEST_DIR)/emulator.o \ +$(TEST_DIR)/emulator.elf: $(cstart.o) $(TEST_DIR)/emulator.o \ $(TEST_DIR)/vm.o $(TEST_DIR)/idt.o -$(TEST_DIR)/port80.flat: $(cstart.o) $(TEST_DIR)/port80.o +$(TEST_DIR)/port80.elf: $(cstart.o) $(TEST_DIR)/port80.o -$(TEST_DIR)/tsc.flat: $(cstart.o) $(TEST_DIR)/tsc.o +$(TEST_DIR)/tsc.elf: $(cstart.o) $(TEST_DIR)/tsc.o -$(TEST_DIR)/apic.flat: $(cstart.o) $(TEST_DIR)/apic.o $(TEST_DIR)/vm.o +$(TEST_DIR)/apic.elf: $(cstart.o) $(TEST_DIR)/apic.o $(TEST_DIR)/vm.o -$(TEST_DIR)/realmode.flat: $(TEST_DIR)/realmode.o +$(TEST_DIR)/realmode.elf: $(TEST_DIR)/realmode.o $(CC) -m32 -nostdlib -o $@ -Wl,-T,$(TEST_DIR)/realmode.lds $^ $(TEST_DIR)/realmode.o: bits = 32 -$(TEST_DIR)/msr.flat: $(cstart.o) $(TEST_DIR)/msr.o +$(TEST_DIR)/msr.elf: $(cstart.o) $(TEST_DIR)/msr.o -$(TEST_DIR)/idt_test.flat: $(cstart.o) $(TEST_DIR)/idt.o $(TEST_DIR)/idt_test.o +$(TEST_DIR)/idt_test.elf: $(cstart.o) $(TEST_DIR)/idt.o $(TEST_DIR)/idt_test.o -$(TEST_DIR)/xsave.flat: $(cstart.o) $(TEST_DIR)/idt.o $(TEST_DIR)/xsave.o +$(TEST_DIR)/xsave.elf: $(cstart.o) $(TEST_DIR)/idt.o $(TEST_DIR)/xsave.o -$(TEST_DIR)/rmap_chain.flat: $(cstart.o) $(TEST_DIR)/rmap_chain.o \ +$(TEST_DIR)/rmap_chain.elf: $(cstart.o) $(TEST_DIR)/rmap_chain.o \ $(TEST_DIR)/vm.o -$(TEST_DIR)/svm.flat: $(cstart.o) $(TEST_DIR)/vm.o +$(TEST_DIR)/svm.elf: $(cstart.o) $(TEST_DIR)/vm.o -$(TEST_DIR)/kvmclock_test.flat: $(cstart.o) $(TEST_DIR)/kvmclock.o \ +$(TEST_DIR)/kvmclock_test.elf: $(cstart.o) $(TEST_DIR)/kvmclock.o \ $(TEST_DIR)/kvmclock_test.o arch_clean: - $(RM) $(TEST_DIR)/*.o $(TEST_DIR)/*.flat \ + $(RM) $(TEST_DIR)/*.o $(TEST_DIR)/*.flat $(TEST_DIR)/*.elf \ $(TEST_DIR)/.*.d $(TEST_DIR)/lib/.*.d $(TEST_DIR)/lib/*.o -include $(TEST_DIR)/.*.d lib/.*.d lib/x86/.*.d -- 1.7.1 -- 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
Re: Problems on qemu-kvm unittests
On 12/03/2010 12:03 PM, Avi Kivity wrote: On 12/03/2010 12:59 AM, Lucas Meneghel Rodrigues wrote: We are getting failures when executing apic.flat on our periodic upstream tests: 12/02 18:40:59 DEBUG|kvm_vm:0664| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:'/tmp/monitor-humanmonitor1-20101202-184059-9EnX',server,nowait -serial unix:'/tmp/serial-20101202-184059-9EnX',server,nowait -m 512 -smp 2 -kernel '/usr/local/autotest/tests/kvm/unittests/apic.flat' -vnc :0 -chardev file,id=testlog,path=/tmp/testlog-20101202-184059-9EnX -device testdev,chardev=testlog -S -cpu qemu64,+x2apic 12/02 18:40:59 DEBUG|kvm_subpro:0700| (qemu) Cannot load x86-64 image, give a 32bit one. 12/02 18:40:59 DEBUG|kvm_subpro:0700| (qemu) (Process terminated with status 1) Relevant git commits: 12/02 18:20:16 INFO | kvm_utils:0407| Commit hash for git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git is 9ee00410d82a7c5cab5ae347d97fbf8a95c55506 (tag v2.6.32-56688-g9ee0041) 12/02 18:39:11 INFO | kvm_utils:0407| Commit hash for git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is 53b6d3d5c2522e881c8d194f122de3114f6f76eb (tag kvm-88-6325-g53b6d3d) 12/02 18:39:16 INFO | kvm_utils:0407| Commit hash for git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git is f2d2b7c74355523b90019427224577b6f0ff1b8a (no tag found) Please advise! Caused by qemu tightening up -kernel. Easily fixed by using objcopy, I'll post a patch soon. Now fixed, kvm-unit-tests.git should work with newer qemus. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] KVM: x86 emulator: add framework for instruction intercepts
When running in guest mode, certain instructions can be intercepted by
hardware. This also holds for nested guests running on emulated
virtualization hardware, in particular instructions emulated by kvm
itself.
This patch adds a framework for intercepting instructions. If an
instruction is marked for interception, and if we're running in guest
mode, a callback is called to check whether an intercept is needed or
not. The callback is called at three points in time: immediately after
beginning execution, after checking privilge exceptions, and after checking
memory exception. This suits the different interception points defined for
different instructions and for the various virtualization instruction sets.
In addition, a new X86EMUL_INTERCEPT is defined, which any callback or memory
access may define, allowing the more complicated intercepts to be implemented
in existing callbacks.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_emulate.h | 20
arch/x86/kvm/emulate.c | 26 ++
arch/x86/kvm/x86.c |9 +
3 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index bf70ece..df06265 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -14,6 +14,8 @@
#include asm/desc_defs.h
struct x86_emulate_ctxt;
+enum x86_intercept;
+enum x86_intercept_stage;
struct x86_exception {
u8 vector;
@@ -62,6 +64,7 @@ struct x86_exception {
#define X86EMUL_RETRY_INSTR 3 /* retry the instruction for some reason */
#define X86EMUL_CMPXCHG_FAILED 4 /* cmpxchg did not see expected value */
#define X86EMUL_IO_NEEDED 5 /* IO is needed to complete emulation */
+#define X86EMUL_INTERCEPTED 6 /* Intercepted by nested VMCB/VMCS */
struct x86_emulate_ops {
/*
@@ -158,6 +161,9 @@ struct x86_emulate_ops {
int (*set_dr)(int dr, unsigned long value, struct kvm_vcpu *vcpu);
int (*set_msr)(struct kvm_vcpu *vcpu, u32 msr_index, u64 data);
int (*get_msr)(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata);
+ int (*intercept)(struct x86_emulate_ctxt *ctxt,
+enum x86_intercept intercept,
+enum x86_intercept_stage stage);
};
/* Type, address-of, and value of an instruction's operand. */
@@ -197,6 +203,7 @@ struct read_cache {
struct decode_cache {
u8 twobyte;
u8 b;
+ u8 intercept;
u8 lock_prefix;
u8 rep_prefix;
u8 op_bytes;
@@ -238,6 +245,7 @@ struct x86_emulate_ctxt {
/* interruptibility state, as a result of execution of STI or MOV SS */
int interruptibility;
+ bool guest_mode; /* guest running a nested guest */
bool perm_ok; /* do not check permissions if true */
bool have_exception;
@@ -258,6 +266,18 @@ struct x86_emulate_ctxt {
#define X86EMUL_MODE_PROT32 4/* 32-bit protected mode. */
#define X86EMUL_MODE_PROT64 8/* 64-bit (long) mode.*/
+enum x86_intercept_stage {
+ x86_icpt_pre_except,
+ x86_icpt_post_except,
+ x86_icpt_post_memaccess,
+};
+
+enum x86_intercept {
+ x86_intercept_none,
+
+ nr_x86_intercepts
+};
+
/* Host execution mode. */
#if defined(CONFIG_X86_32)
#define X86EMUL_MODE_HOST X86EMUL_MODE_PROT32
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 6366735..be6ebff 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -101,6 +101,7 @@
struct opcode {
u32 flags;
+ u8 intercept;
union {
int (*execute)(struct x86_emulate_ctxt *ctxt);
struct opcode *group;
@@ -2319,10 +2320,13 @@ static int em_mov(struct x86_emulate_ctxt *ctxt)
}
#define D(_y) { .flags = (_y) }
+#define DI(_y, _i) { .flags = (_y), .intercept = x86_intercept_##_i }
#define ND(0)
#define G(_f, _g) { .flags = ((_f) | Group), .u.group = (_g) }
#define GD(_f, _g) { .flags = ((_f) | Group | GroupDual), .u.gdual = (_g) }
#define I(_f, _e) { .flags = (_f), .u.execute = (_e) }
+#define II(_f, _e, _i) \
+ { .flags = (_f), .u.execute = (_e), .intercept = x86_intercept_##_i }
#define D2bv(_f) D((_f) | ByteOp), D(_f)
#define I2bv(_f, _e) I((_f) | ByteOp, _e), I(_f, _e)
@@ -2733,6 +2737,7 @@ done_prefixes:
}
c-execute = opcode.u.execute;
+ c-intercept = opcode.intercept;
/* Unrecognised? */
if (c-d == 0 || (c-d Undefined))
@@ -2964,12 +2969,26 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
goto done;
}
+ if (unlikely(ctxt-guest_mode) c-intercept) {
+ rc = ops-intercept(ctxt, c-intercept,
+ x86_icpt_pre_except);
+ if (rc != X86EMUL_CONTINUE)
+ goto done;
+ }
+
/* Privileged instruction can be
buildbot failure in qemu-kvm on disable_kvm_x86_64_debian_5_0
The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/666 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Aaro Koskinen aaro.koski...@iki.fi,Abhijith Das a...@redhat.com,Abhilash Kesavan a.kesa...@samsung.com,Ajay Kumar Gupta ajay.gu...@ti.com,Alan Stern st...@rowland.harvard.edu,Alberto Panizzo maramaopercheseimo...@gmail.com,Alex Deucher alexdeuc...@gmail.com,Alex Shi alex@intel.com,Alexey Dobriyan adobri...@gmail.com,Anand Gadiyar gadi...@ti.com,Anders Kaseorg ande...@ksplice.com,Andiry Xu andiry...@amd.com,Andreas Mohr a...@lisas.de,Andres Salomon dilin...@queued.net,Andrew Morton a...@linux-foundation.org,Andy Lutomirski l...@mit.edu,Andy Whitcroft a...@canonical.com,Anupam Chanda anup...@vmware.com,Arend van Spriel ar...@broadcom.com,Arnaldo Carvalho de Melo a...@redhat.com,Arnd Hannemann a...@arndnet.de,Arne Jansen sensi...@gmx.net,Artem Bityutskiy artem.bityuts...@nokia.com,Arun Bharadwaj a...@linux.vnet.ibm.com,Avi Kivity a...@redhat.com,Axel Lin axel@gmail.com,Baruch Siach bar...@tkos.co.il,Bastian B lank wa...@debian.org,Ben Hutchings b...@decadent.org.uk,Ben Skeggs bske...@redhat.com,Bengt Jonsson bengt.g.jons...@stericsson.com,Brandon Philips bran...@ifup.org,Breno Leitao br...@cafe.(none),Brian J. Tarricone br...@tarricone.org,Caglar Akyuz cag...@bilkon-kontrol.com.tr,Casey Leedom lee...@chelsio.com,Chien Tung chien.tin.t...@intel.com,Chris Mason chris.ma...@oracle.com,Chris Metcalf cmetc...@tilera.com,Chris Paulson-Ellis ch...@edesix.com,Chris Wilson ch...@chris-wilson.co.uk,Christian Lamparter chunk...@googlemail.com,Cyrill Gorcunov gorcu...@gmail.com,Daisuke Nishimura nishim...@mxp.nes.nec.co.jp,Dan Carpenter erro...@gmail.com,Dan Rosenberg drosenb...@vsecurity.com,Daniel Drake d...@laptop.org,Daniel Glöckner daniel...@gmx.net,Daniel Klaffenbach danielklaffenb...@gmail.com,Daniel T Chen crim...@ubuntu.com,Daniel Vetter daniel.vet...@ffwll.ch,Darius Augulis augulis.dar...@gmail.com,Darrick J. Wong djw...@us.ibm.com ,Dave Airlie airl...@redhat.com,Dave Chinner dchin...@redhat.com,David Daney dda...@caviumnetworks.com,David Henningsson david.hennings...@canonical.com,David Howells dhowe...@redhat.com,David S. Miller da...@davemloft.net,David Sterba dste...@suse.cz,Dean Nelson dnel...@redhat.com,Denis Kuplyakov dener@gmail.com,Dimitri Sivanich sivan...@sgi.com,Dimitris Papastamos d...@opensource.wolfsonmicro.com,Dmitry Artamonow mad_s...@inbox.ru,Dmitry Torokhov dmitry.torok...@gmail.com,Don Zickus dzic...@redhat.com,Eli Cohen e...@dev.mellanox.co.il,Eric Benard e...@eukrea.com,Eric Bénard e...@eukrea.com,Eric Dumazet eric.duma...@gmail.com,Felix Fietkau n...@openwrt.org,Feng Tang feng.t...@intel.com,Filip Aben f.a...@option.com,Florian Fainelli flor...@openwrt.org,Francisco Jerez curroje...@riseup.net,Frederic Weisbecker fweis...@gmail.com,Gerrit Renker ger...@erg.abdn.ac.uk,Giuseppe CAVALLARO peppe.cavall...@st.com,Giuseppe Cavallaro peppe.cavall...@st.com,Greg Kroah-Hartman gre...@suse.de,Greg Thelen gthe...@google.com,Guennadi Liakhovetski g.liakhovet...@gmx.de,Guenter Roeck guenter.ro...@ericsson.com,Hans J. Koch h...@hansjkoch.de,Heiko Carstens heiko.carst...@de.ibm.com,Hema Kalliguddi hem...@ti.com,Henrik Rydberg rydb...@euromail.se,Herton Ronaldo Krzesinski her...@mandriva.com.br,Huang Weiyi weiyi.hu...@gmail.com,Ian Campbell ian.campb...@citrix.com,Ian Kent ra...@themaw.net,Ingo Molnar mi...@elte.hu,Jacob Pan jacob.jun@linux.intel.com,Jacques Viviers jacques.vivi...@gmail.com,James Jones jajo...@nvidia.com,Jan Beulich jbeul...@novell.com,Jan Beulich jbeul...@novell.com,Jan Glauber j...@linux.vnet.ibm.com,Janusz Krzysztofik jkrzy...@tis.icnet.pl,Jarkko Nikula jhnik...@gmail.com,Jason Wessel jason.wes...@windriver.com,Jean Delvare kh...@linux-fr.org,Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com,Jeff Layton jlay...@redhat.com,Jens Axboe jax...@fusionio.com,Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com,Jeremy Fitzhardinge jer...@goop.org,Jesper Juhl j...@chaosbits.net,Jesse Marroquin jesse.marroq...@maxim-ic.com,Jiri Slaby jsl...@suse.cz,Joe Perches j...@perches.com,Johannes Berg johannes.b...@intel.com,John Fastabend john.r.fastab...@intel.com,John Tapsell johnf...@gmail.com,Josef Bacik jo...@redhat.com,Josh Wu josh...@atmel.com,Julia Lawall ju...@diku.dk,Jussi Kivilinna jussi.kivili...@mbnet.fi,Justin Maggard jmaggar...@gmail.com,KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com,KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com,Kailang Yang kail...@realtek.com,Keith Packard kei...@keithp.com,Ken Kawasaki ken_kawas...@spring.nifty.jp,Ken Sumrall ksumr...@android.com,Kevin Hilman khil...@deeprootsystems.com,Kirill A. Shutemov
buildbot failure in qemu-kvm on default_x86_64_debian_5_0
The Buildbot has detected a new failure of default_x86_64_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_debian_5_0/builds/676 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Aaro Koskinen aaro.koski...@iki.fi,Abhijith Das a...@redhat.com,Abhilash Kesavan a.kesa...@samsung.com,Ajay Kumar Gupta ajay.gu...@ti.com,Alan Stern st...@rowland.harvard.edu,Alberto Panizzo maramaopercheseimo...@gmail.com,Alex Deucher alexdeuc...@gmail.com,Alex Shi alex@intel.com,Alexey Dobriyan adobri...@gmail.com,Anand Gadiyar gadi...@ti.com,Anders Kaseorg ande...@ksplice.com,Andiry Xu andiry...@amd.com,Andreas Mohr a...@lisas.de,Andres Salomon dilin...@queued.net,Andrew Morton a...@linux-foundation.org,Andy Lutomirski l...@mit.edu,Andy Whitcroft a...@canonical.com,Anupam Chanda anup...@vmware.com,Arend van Spriel ar...@broadcom.com,Arnaldo Carvalho de Melo a...@redhat.com,Arnd Hannemann a...@arndnet.de,Arne Jansen sensi...@gmx.net,Artem Bityutskiy artem.bityuts...@nokia.com,Arun Bharadwaj a...@linux.vnet.ibm.com,Avi Kivity a...@redhat.com,Axel Lin axel@gmail.com,Baruch Siach bar...@tkos.co.il,Bastian B lank wa...@debian.org,Ben Hutchings b...@decadent.org.uk,Ben Skeggs bske...@redhat.com,Bengt Jonsson bengt.g.jons...@stericsson.com,Brandon Philips bran...@ifup.org,Breno Leitao br...@cafe.(none),Brian J. Tarricone br...@tarricone.org,Caglar Akyuz cag...@bilkon-kontrol.com.tr,Casey Leedom lee...@chelsio.com,Chien Tung chien.tin.t...@intel.com,Chris Mason chris.ma...@oracle.com,Chris Metcalf cmetc...@tilera.com,Chris Paulson-Ellis ch...@edesix.com,Chris Wilson ch...@chris-wilson.co.uk,Christian Lamparter chunk...@googlemail.com,Cyrill Gorcunov gorcu...@gmail.com,Daisuke Nishimura nishim...@mxp.nes.nec.co.jp,Dan Carpenter erro...@gmail.com,Dan Rosenberg drosenb...@vsecurity.com,Daniel Drake d...@laptop.org,Daniel Glöckner daniel...@gmx.net,Daniel Klaffenbach danielklaffenb...@gmail.com,Daniel T Chen crim...@ubuntu.com,Daniel Vetter daniel.vet...@ffwll.ch,Darius Augulis augulis.dar...@gmail.com,Darrick J. Wong djw...@us.ibm.com ,Dave Airlie airl...@redhat.com,Dave Chinner dchin...@redhat.com,David Daney dda...@caviumnetworks.com,David Henningsson david.hennings...@canonical.com,David Howells dhowe...@redhat.com,David S. Miller da...@davemloft.net,David Sterba dste...@suse.cz,Dean Nelson dnel...@redhat.com,Denis Kuplyakov dener@gmail.com,Dimitri Sivanich sivan...@sgi.com,Dimitris Papastamos d...@opensource.wolfsonmicro.com,Dmitry Artamonow mad_s...@inbox.ru,Dmitry Torokhov dmitry.torok...@gmail.com,Don Zickus dzic...@redhat.com,Eli Cohen e...@dev.mellanox.co.il,Eric Benard e...@eukrea.com,Eric Bénard e...@eukrea.com,Eric Dumazet eric.duma...@gmail.com,Felix Fietkau n...@openwrt.org,Feng Tang feng.t...@intel.com,Filip Aben f.a...@option.com,Florian Fainelli flor...@openwrt.org,Francisco Jerez curroje...@riseup.net,Frederic Weisbecker fweis...@gmail.com,Gerrit Renker ger...@erg.abdn.ac.uk,Giuseppe CAVALLARO peppe.cavall...@st.com,Giuseppe Cavallaro peppe.cavall...@st.com,Greg Kroah-Hartman gre...@suse.de,Greg Thelen gthe...@google.com,Guennadi Liakhovetski g.liakhovet...@gmx.de,Guenter Roeck guenter.ro...@ericsson.com,Hans J. Koch h...@hansjkoch.de,Heiko Carstens heiko.carst...@de.ibm.com,Hema Kalliguddi hem...@ti.com,Henrik Rydberg rydb...@euromail.se,Herton Ronaldo Krzesinski her...@mandriva.com.br,Huang Weiyi weiyi.hu...@gmail.com,Ian Campbell ian.campb...@citrix.com,Ian Kent ra...@themaw.net,Ingo Molnar mi...@elte.hu,Jacob Pan jacob.jun@linux.intel.com,Jacques Viviers jacques.vivi...@gmail.com,James Jones jajo...@nvidia.com,Jan Beulich jbeul...@novell.com,Jan Beulich jbeul...@novell.com,Jan Glauber j...@linux.vnet.ibm.com,Janusz Krzysztofik jkrzy...@tis.icnet.pl,Jarkko Nikula jhnik...@gmail.com,Jason Wessel jason.wes...@windriver.com,Jean Delvare kh...@linux-fr.org,Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com,Jeff Layton jlay...@redhat.com,Jens Axboe jax...@fusionio.com,Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com,Jeremy Fitzhardinge jer...@goop.org,Jesper Juhl j...@chaosbits.net,Jesse Marroquin jesse.marroq...@maxim-ic.com,Jiri Slaby jsl...@suse.cz,Joe Perches j...@perches.com,Johannes Berg johannes.b...@intel.com,John Fastabend john.r.fastab...@intel.com,John Tapsell johnf...@gmail.com,Josef Bacik jo...@redhat.com,Josh Wu josh...@atmel.com,Julia Lawall ju...@diku.dk,Jussi Kivilinna jussi.kivili...@mbnet.fi,Justin Maggard jmaggar...@gmail.com,KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com,KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com,Kailang Yang kail...@realtek.com,Keith Packard kei...@keithp.com,Ken Kawasaki ken_kawas...@spring.nifty.jp,Ken Sumrall ksumr...@android.com,Kevin Hilman khil...@deeprootsystems.com,Kirill A. Shutemov
buildbot failure in qemu-kvm on disable_kvm_i386_out_of_tree
The Buildbot has detected a new failure of disable_kvm_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/615 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Aaro Koskinen aaro.koski...@iki.fi,Abhijith Das a...@redhat.com,Abhilash Kesavan a.kesa...@samsung.com,Ajay Kumar Gupta ajay.gu...@ti.com,Alan Stern st...@rowland.harvard.edu,Alberto Panizzo maramaopercheseimo...@gmail.com,Alex Deucher alexdeuc...@gmail.com,Alex Shi alex@intel.com,Alexey Dobriyan adobri...@gmail.com,Anand Gadiyar gadi...@ti.com,Anders Kaseorg ande...@ksplice.com,Andiry Xu andiry...@amd.com,Andreas Mohr a...@lisas.de,Andres Salomon dilin...@queued.net,Andrew Morton a...@linux-foundation.org,Andy Lutomirski l...@mit.edu,Andy Whitcroft a...@canonical.com,Anupam Chanda anup...@vmware.com,Arend van Spriel ar...@broadcom.com,Arnaldo Carvalho de Melo a...@redhat.com,Arnd Hannemann a...@arndnet.de,Arne Jansen sensi...@gmx.net,Artem Bityutskiy artem.bityuts...@nokia.com,Arun Bharadwaj a...@linux.vnet.ibm.com,Avi Kivity a...@redhat.com,Axel Lin axel@gmail.com,Baruch Siach bar...@tkos.co.il,Bastian B lank wa...@debian.org,Ben Hutchings b...@decadent.org.uk,Ben Skeggs bske...@redhat.com,Bengt Jonsson bengt.g.jons...@stericsson.com,Brandon Philips bran...@ifup.org,Breno Leitao br...@cafe.(none),Brian J. Tarricone br...@tarricone.org,Caglar Akyuz cag...@bilkon-kontrol.com.tr,Casey Leedom lee...@chelsio.com,Chien Tung chien.tin.t...@intel.com,Chris Mason chris.ma...@oracle.com,Chris Metcalf cmetc...@tilera.com,Chris Paulson-Ellis ch...@edesix.com,Chris Wilson ch...@chris-wilson.co.uk,Christian Lamparter chunk...@googlemail.com,Cyrill Gorcunov gorcu...@gmail.com,Daisuke Nishimura nishim...@mxp.nes.nec.co.jp,Dan Carpenter erro...@gmail.com,Dan Rosenberg drosenb...@vsecurity.com,Daniel Drake d...@laptop.org,Daniel Glöckner daniel...@gmx.net,Daniel Klaffenbach danielklaffenb...@gmail.com,Daniel T Chen crim...@ubuntu.com,Daniel Vetter daniel.vet...@ffwll.ch,Darius Augulis augulis.dar...@gmail.com,Darrick J. Wong djw...@us.ibm.com ,Dave Airlie airl...@redhat.com,Dave Chinner dchin...@redhat.com,David Daney dda...@caviumnetworks.com,David Henningsson david.hennings...@canonical.com,David Howells dhowe...@redhat.com,David S. Miller da...@davemloft.net,David Sterba dste...@suse.cz,Dean Nelson dnel...@redhat.com,Denis Kuplyakov dener@gmail.com,Dimitri Sivanich sivan...@sgi.com,Dimitris Papastamos d...@opensource.wolfsonmicro.com,Dmitry Artamonow mad_s...@inbox.ru,Dmitry Torokhov dmitry.torok...@gmail.com,Don Zickus dzic...@redhat.com,Eli Cohen e...@dev.mellanox.co.il,Eric Benard e...@eukrea.com,Eric Bénard e...@eukrea.com,Eric Dumazet eric.duma...@gmail.com,Felix Fietkau n...@openwrt.org,Feng Tang feng.t...@intel.com,Filip Aben f.a...@option.com,Florian Fainelli flor...@openwrt.org,Francisco Jerez curroje...@riseup.net,Frederic Weisbecker fweis...@gmail.com,Gerrit Renker ger...@erg.abdn.ac.uk,Giuseppe CAVALLARO peppe.cavall...@st.com,Giuseppe Cavallaro peppe.cavall...@st.com,Greg Kroah-Hartman gre...@suse.de,Greg Thelen gthe...@google.com,Guennadi Liakhovetski g.liakhovet...@gmx.de,Guenter Roeck guenter.ro...@ericsson.com,Hans J. Koch h...@hansjkoch.de,Heiko Carstens heiko.carst...@de.ibm.com,Hema Kalliguddi hem...@ti.com,Henrik Rydberg rydb...@euromail.se,Herton Ronaldo Krzesinski her...@mandriva.com.br,Huang Weiyi weiyi.hu...@gmail.com,Ian Campbell ian.campb...@citrix.com,Ian Kent ra...@themaw.net,Ingo Molnar mi...@elte.hu,Jacob Pan jacob.jun@linux.intel.com,Jacques Viviers jacques.vivi...@gmail.com,James Jones jajo...@nvidia.com,Jan Beulich jbeul...@novell.com,Jan Beulich jbeul...@novell.com,Jan Glauber j...@linux.vnet.ibm.com,Janusz Krzysztofik jkrzy...@tis.icnet.pl,Jarkko Nikula jhnik...@gmail.com,Jason Wessel jason.wes...@windriver.com,Jean Delvare kh...@linux-fr.org,Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com,Jeff Layton jlay...@redhat.com,Jens Axboe jax...@fusionio.com,Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com,Jeremy Fitzhardinge jer...@goop.org,Jesper Juhl j...@chaosbits.net,Jesse Marroquin jesse.marroq...@maxim-ic.com,Jiri Slaby jsl...@suse.cz,Joe Perches j...@perches.com,Johannes Berg johannes.b...@intel.com,John Fastabend john.r.fastab...@intel.com,John Tapsell johnf...@gmail.com,Josef Bacik jo...@redhat.com,Josh Wu josh...@atmel.com,Julia Lawall ju...@diku.dk,Jussi Kivilinna jussi.kivili...@mbnet.fi,Justin Maggard jmaggar...@gmail.com,KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com,KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com,Kailang Yang kail...@realtek.com,Keith Packard kei...@keithp.com,Ken Kawasaki ken_kawas...@spring.nifty.jp,Ken Sumrall ksumr...@android.com,Kevin Hilman khil...@deeprootsystems.com,Kirill A. Shutemov
buildbot failure in qemu-kvm on default_x86_64_out_of_tree
The Buildbot has detected a new failure of default_x86_64_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_x86_64_out_of_tree/builds/617 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Aaro Koskinen aaro.koski...@iki.fi,Abhijith Das a...@redhat.com,Abhilash Kesavan a.kesa...@samsung.com,Ajay Kumar Gupta ajay.gu...@ti.com,Alan Stern st...@rowland.harvard.edu,Alberto Panizzo maramaopercheseimo...@gmail.com,Alex Deucher alexdeuc...@gmail.com,Alex Shi alex@intel.com,Alexey Dobriyan adobri...@gmail.com,Anand Gadiyar gadi...@ti.com,Anders Kaseorg ande...@ksplice.com,Andiry Xu andiry...@amd.com,Andreas Mohr a...@lisas.de,Andres Salomon dilin...@queued.net,Andrew Morton a...@linux-foundation.org,Andy Lutomirski l...@mit.edu,Andy Whitcroft a...@canonical.com,Anupam Chanda anup...@vmware.com,Arend van Spriel ar...@broadcom.com,Arnaldo Carvalho de Melo a...@redhat.com,Arnd Hannemann a...@arndnet.de,Arne Jansen sensi...@gmx.net,Artem Bityutskiy artem.bityuts...@nokia.com,Arun Bharadwaj a...@linux.vnet.ibm.com,Avi Kivity a...@redhat.com,Axel Lin axel@gmail.com,Baruch Siach bar...@tkos.co.il,Bastian B lank wa...@debian.org,Ben Hutchings b...@decadent.org.uk,Ben Skeggs bske...@redhat.com,Bengt Jonsson bengt.g.jons...@stericsson.com,Brandon Philips bran...@ifup.org,Breno Leitao br...@cafe.(none),Brian J. Tarricone br...@tarricone.org,Caglar Akyuz cag...@bilkon-kontrol.com.tr,Casey Leedom lee...@chelsio.com,Chien Tung chien.tin.t...@intel.com,Chris Mason chris.ma...@oracle.com,Chris Metcalf cmetc...@tilera.com,Chris Paulson-Ellis ch...@edesix.com,Chris Wilson ch...@chris-wilson.co.uk,Christian Lamparter chunk...@googlemail.com,Cyrill Gorcunov gorcu...@gmail.com,Daisuke Nishimura nishim...@mxp.nes.nec.co.jp,Dan Carpenter erro...@gmail.com,Dan Rosenberg drosenb...@vsecurity.com,Daniel Drake d...@laptop.org,Daniel Glöckner daniel...@gmx.net,Daniel Klaffenbach danielklaffenb...@gmail.com,Daniel T Chen crim...@ubuntu.com,Daniel Vetter daniel.vet...@ffwll.ch,Darius Augulis augulis.dar...@gmail.com,Darrick J. Wong djw...@us.ibm.com ,Dave Airlie airl...@redhat.com,Dave Chinner dchin...@redhat.com,David Daney dda...@caviumnetworks.com,David Henningsson david.hennings...@canonical.com,David Howells dhowe...@redhat.com,David S. Miller da...@davemloft.net,David Sterba dste...@suse.cz,Dean Nelson dnel...@redhat.com,Denis Kuplyakov dener@gmail.com,Dimitri Sivanich sivan...@sgi.com,Dimitris Papastamos d...@opensource.wolfsonmicro.com,Dmitry Artamonow mad_s...@inbox.ru,Dmitry Torokhov dmitry.torok...@gmail.com,Don Zickus dzic...@redhat.com,Eli Cohen e...@dev.mellanox.co.il,Eric Benard e...@eukrea.com,Eric Bénard e...@eukrea.com,Eric Dumazet eric.duma...@gmail.com,Felix Fietkau n...@openwrt.org,Feng Tang feng.t...@intel.com,Filip Aben f.a...@option.com,Florian Fainelli flor...@openwrt.org,Francisco Jerez curroje...@riseup.net,Frederic Weisbecker fweis...@gmail.com,Gerrit Renker ger...@erg.abdn.ac.uk,Giuseppe CAVALLARO peppe.cavall...@st.com,Giuseppe Cavallaro peppe.cavall...@st.com,Greg Kroah-Hartman gre...@suse.de,Greg Thelen gthe...@google.com,Guennadi Liakhovetski g.liakhovet...@gmx.de,Guenter Roeck guenter.ro...@ericsson.com,Hans J. Koch h...@hansjkoch.de,Heiko Carstens heiko.carst...@de.ibm.com,Hema Kalliguddi hem...@ti.com,Henrik Rydberg rydb...@euromail.se,Herton Ronaldo Krzesinski her...@mandriva.com.br,Huang Weiyi weiyi.hu...@gmail.com,Ian Campbell ian.campb...@citrix.com,Ian Kent ra...@themaw.net,Ingo Molnar mi...@elte.hu,Jacob Pan jacob.jun@linux.intel.com,Jacques Viviers jacques.vivi...@gmail.com,James Jones jajo...@nvidia.com,Jan Beulich jbeul...@novell.com,Jan Beulich jbeul...@novell.com,Jan Glauber j...@linux.vnet.ibm.com,Janusz Krzysztofik jkrzy...@tis.icnet.pl,Jarkko Nikula jhnik...@gmail.com,Jason Wessel jason.wes...@windriver.com,Jean Delvare kh...@linux-fr.org,Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com,Jeff Layton jlay...@redhat.com,Jens Axboe jax...@fusionio.com,Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com,Jeremy Fitzhardinge jer...@goop.org,Jesper Juhl j...@chaosbits.net,Jesse Marroquin jesse.marroq...@maxim-ic.com,Jiri Slaby jsl...@suse.cz,Joe Perches j...@perches.com,Johannes Berg johannes.b...@intel.com,John Fastabend john.r.fastab...@intel.com,John Tapsell johnf...@gmail.com,Josef Bacik jo...@redhat.com,Josh Wu josh...@atmel.com,Julia Lawall ju...@diku.dk,Jussi Kivilinna jussi.kivili...@mbnet.fi,Justin Maggard jmaggar...@gmail.com,KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com,KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com,Kailang Yang kail...@realtek.com,Keith Packard kei...@keithp.com,Ken Kawasaki ken_kawas...@spring.nifty.jp,Ken Sumrall ksumr...@android.com,Kevin Hilman khil...@deeprootsystems.com,Kirill A. Shutemov
buildbot failure in qemu-kvm on default_i386_out_of_tree
The Buildbot has detected a new failure of default_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/default_i386_out_of_tree/builds/615 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: Build Source Stamp: [branch next] HEAD Blamelist: Aaro Koskinen aaro.koski...@iki.fi,Abhijith Das a...@redhat.com,Abhilash Kesavan a.kesa...@samsung.com,Ajay Kumar Gupta ajay.gu...@ti.com,Alan Stern st...@rowland.harvard.edu,Alberto Panizzo maramaopercheseimo...@gmail.com,Alex Deucher alexdeuc...@gmail.com,Alex Shi alex@intel.com,Alexey Dobriyan adobri...@gmail.com,Anand Gadiyar gadi...@ti.com,Anders Kaseorg ande...@ksplice.com,Andiry Xu andiry...@amd.com,Andreas Mohr a...@lisas.de,Andres Salomon dilin...@queued.net,Andrew Morton a...@linux-foundation.org,Andy Lutomirski l...@mit.edu,Andy Whitcroft a...@canonical.com,Anupam Chanda anup...@vmware.com,Arend van Spriel ar...@broadcom.com,Arnaldo Carvalho de Melo a...@redhat.com,Arnd Hannemann a...@arndnet.de,Arne Jansen sensi...@gmx.net,Artem Bityutskiy artem.bityuts...@nokia.com,Arun Bharadwaj a...@linux.vnet.ibm.com,Avi Kivity a...@redhat.com,Axel Lin axel@gmail.com,Baruch Siach bar...@tkos.co.il,Bastian B lank wa...@debian.org,Ben Hutchings b...@decadent.org.uk,Ben Skeggs bske...@redhat.com,Bengt Jonsson bengt.g.jons...@stericsson.com,Brandon Philips bran...@ifup.org,Breno Leitao br...@cafe.(none),Brian J. Tarricone br...@tarricone.org,Caglar Akyuz cag...@bilkon-kontrol.com.tr,Casey Leedom lee...@chelsio.com,Chien Tung chien.tin.t...@intel.com,Chris Mason chris.ma...@oracle.com,Chris Metcalf cmetc...@tilera.com,Chris Paulson-Ellis ch...@edesix.com,Chris Wilson ch...@chris-wilson.co.uk,Christian Lamparter chunk...@googlemail.com,Cyrill Gorcunov gorcu...@gmail.com,Daisuke Nishimura nishim...@mxp.nes.nec.co.jp,Dan Carpenter erro...@gmail.com,Dan Rosenberg drosenb...@vsecurity.com,Daniel Drake d...@laptop.org,Daniel Glöckner daniel...@gmx.net,Daniel Klaffenbach danielklaffenb...@gmail.com,Daniel T Chen crim...@ubuntu.com,Daniel Vetter daniel.vet...@ffwll.ch,Darius Augulis augulis.dar...@gmail.com,Darrick J. Wong djw...@us.ibm.com ,Dave Airlie airl...@redhat.com,Dave Chinner dchin...@redhat.com,David Daney dda...@caviumnetworks.com,David Henningsson david.hennings...@canonical.com,David Howells dhowe...@redhat.com,David S. Miller da...@davemloft.net,David Sterba dste...@suse.cz,Dean Nelson dnel...@redhat.com,Denis Kuplyakov dener@gmail.com,Dimitri Sivanich sivan...@sgi.com,Dimitris Papastamos d...@opensource.wolfsonmicro.com,Dmitry Artamonow mad_s...@inbox.ru,Dmitry Torokhov dmitry.torok...@gmail.com,Don Zickus dzic...@redhat.com,Eli Cohen e...@dev.mellanox.co.il,Eric Benard e...@eukrea.com,Eric Bénard e...@eukrea.com,Eric Dumazet eric.duma...@gmail.com,Felix Fietkau n...@openwrt.org,Feng Tang feng.t...@intel.com,Filip Aben f.a...@option.com,Florian Fainelli flor...@openwrt.org,Francisco Jerez curroje...@riseup.net,Frederic Weisbecker fweis...@gmail.com,Gerrit Renker ger...@erg.abdn.ac.uk,Giuseppe CAVALLARO peppe.cavall...@st.com,Giuseppe Cavallaro peppe.cavall...@st.com,Greg Kroah-Hartman gre...@suse.de,Greg Thelen gthe...@google.com,Guennadi Liakhovetski g.liakhovet...@gmx.de,Guenter Roeck guenter.ro...@ericsson.com,Hans J. Koch h...@hansjkoch.de,Heiko Carstens heiko.carst...@de.ibm.com,Hema Kalliguddi hem...@ti.com,Henrik Rydberg rydb...@euromail.se,Herton Ronaldo Krzesinski her...@mandriva.com.br,Huang Weiyi weiyi.hu...@gmail.com,Ian Campbell ian.campb...@citrix.com,Ian Kent ra...@themaw.net,Ingo Molnar mi...@elte.hu,Jacob Pan jacob.jun@linux.intel.com,Jacques Viviers jacques.vivi...@gmail.com,James Jones jajo...@nvidia.com,Jan Beulich jbeul...@novell.com,Jan Beulich jbeul...@novell.com,Jan Glauber j...@linux.vnet.ibm.com,Janusz Krzysztofik jkrzy...@tis.icnet.pl,Jarkko Nikula jhnik...@gmail.com,Jason Wessel jason.wes...@windriver.com,Jean Delvare kh...@linux-fr.org,Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com,Jeff Layton jlay...@redhat.com,Jens Axboe jax...@fusionio.com,Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com,Jeremy Fitzhardinge jer...@goop.org,Jesper Juhl j...@chaosbits.net,Jesse Marroquin jesse.marroq...@maxim-ic.com,Jiri Slaby jsl...@suse.cz,Joe Perches j...@perches.com,Johannes Berg johannes.b...@intel.com,John Fastabend john.r.fastab...@intel.com,John Tapsell johnf...@gmail.com,Josef Bacik jo...@redhat.com,Josh Wu josh...@atmel.com,Julia Lawall ju...@diku.dk,Jussi Kivilinna jussi.kivili...@mbnet.fi,Justin Maggard jmaggar...@gmail.com,KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com,KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com,Kailang Yang kail...@realtek.com,Keith Packard kei...@keithp.com,Ken Kawasaki ken_kawas...@spring.nifty.jp,Ken Sumrall ksumr...@android.com,Kevin Hilman khil...@deeprootsystems.com,Kirill A. Shutemov
Re: [PATCH 2/2] KVM: x86 emulator: add SVM intercepts
On 12/05/2010 12:18 PM, Avi Kivity wrote: Add intercept codes for instructions defined by SVM as interceptable. Note: this doesn't handle pause, aka 'rep nop', since we don't yet specialize decode based on rep prefixes. When we get it (needed for sse) we can add the decode, till then it doesn't pause any security issue since pause has no side effects. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Convert .flat files to 32-bit elf format
On 05.12.2010, at 09:15, Avi Kivity wrote: Recent qemus no longer load 64-bit elf kernels. Fix by converting to 32-bit elf. Signed-off-by: Avi Kivity a...@redhat.com --- config-x86-common.mak | 39 +-- 1 files changed, 21 insertions(+), 18 deletions(-) diff --git a/config-x86-common.mak b/config-x86-common.mak index b541c1c..c5508b3 100644 --- a/config-x86-common.mak +++ b/config-x86-common.mak @@ -20,9 +20,12 @@ CFLAGS += -m$(bits) libgcc := $(shell $(CC) -m$(bits) --print-libgcc-file-name) FLATLIBS = lib/libcflat.a $(libgcc) -%.flat: %.o $(FLATLIBS) flat.lds +%.elf: %.o $(FLATLIBS) flat.lds $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $(filter %.o, $^) $(FLATLIBS) +%.flat: %.elf + objcopy -O elf32-i386 $^ $@ Not sure it's that great to call 32bit elf binaries .flat. I'd rather expect a flat file when reading that file extension ;). Mind to just call it .elf32? Alternatively, you could also use real flat files and shove a multiboot header into the binary. Alex -- 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
Re: [PATCH] Convert .flat files to 32-bit elf format
On 12/05/2010 02:05 PM, Alexander Graf wrote: diff --git a/config-x86-common.mak b/config-x86-common.mak index b541c1c..c5508b3 100644 --- a/config-x86-common.mak +++ b/config-x86-common.mak @@ -20,9 +20,12 @@ CFLAGS += -m$(bits) libgcc := $(shell $(CC) -m$(bits) --print-libgcc-file-name) FLATLIBS = lib/libcflat.a $(libgcc) -%.flat: %.o $(FLATLIBS) flat.lds +%.elf: %.o $(FLATLIBS) flat.lds $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $(filter %.o, $^) $(FLATLIBS) +%.flat: %.elf + objcopy -O elf32-i386 $^ $@ Not sure it's that great to call 32bit elf binaries .flat. I'd rather expect a flat file when reading that file extension ;). Mind to just call it .elf32? It's a reminder from the good old days that these were flat files loaded by kvmctl. Alternatively, you could also use real flat files and shove a multiboot header into the binary. I'll rename them in a later patch. .elf32 isn't a good name either, it implies 32-bit execution, whereas it's just the file format due to multiboot constraints. Maybe .test (and .test32 and .test64 when we build both). -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] kvm: keep track of which task is running a KVM vcpu
On 12/03/2010 04:50 PM, Rik van Riel wrote: On 12/02/2010 08:18 PM, Chris Wright wrote: * Rik van Riel (r...@redhat.com) wrote: Keep track of which task is running a KVM vcpu. This helps us figure out later what task to wake up if we want to boost a vcpu that got preempted. Unfortunately there are no guarantees that the same task always keeps the same vcpu, so we can only track the task across a single run of the vcpu. So shouldn't it confine to KVM_RUN? The other vcpu_load callers aren't always a vcpu in a useful runnable state. Yeah, probably. If you want I can move the setting of vcpu-task to kvm_vcpu_ioctl. No need, it's not like something bad will happen. What I'd really like to see is a soft binding between a vcpu and its thread, so directed yield works even if we're in qemu while we were scheduled out. In fact it's not an unlikely pattern: spin_lock(lock) ... writel(some_port_handled_by_qemu) ... spin_unlock(lock) but that can wait. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Convert .flat files to 32-bit elf format
On 05.12.2010, at 13:37, Avi Kivity wrote: On 12/05/2010 02:05 PM, Alexander Graf wrote: diff --git a/config-x86-common.mak b/config-x86-common.mak index b541c1c..c5508b3 100644 --- a/config-x86-common.mak +++ b/config-x86-common.mak @@ -20,9 +20,12 @@ CFLAGS += -m$(bits) libgcc := $(shell $(CC) -m$(bits) --print-libgcc-file-name) FLATLIBS = lib/libcflat.a $(libgcc) -%.flat: %.o $(FLATLIBS) flat.lds +%.elf: %.o $(FLATLIBS) flat.lds $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $(filter %.o, $^) $(FLATLIBS) +%.flat: %.elf + objcopy -O elf32-i386 $^ $@ Not sure it's that great to call 32bit elf binaries .flat. I'd rather expect a flat file when reading that file extension ;). Mind to just call it .elf32? It's a reminder from the good old days that these were flat files loaded by kvmctl. Nothing's as permanent as an improvised solution :). Alternatively, you could also use real flat files and shove a multiboot header into the binary. I'll rename them in a later patch. .elf32 isn't a good name either, it implies 32-bit execution, whereas it's just the file format due to multiboot constraints. Maybe .test (and .test32 and .test64 when we build both). Yeah, anything really. The .flat is definitely just wrong ;). .test32 and .test64 always sounds good to me. No reason to be clever and also have .test. Alex -- 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
Re: [RFC PATCH 3/3] kvm: use yield_to instead of sleep in kvm_vcpu_on_spin
On 12/03/2010 04:24 AM, Chris Wright wrote:
* Rik van Riel (r...@redhat.com) wrote:
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1880,18 +1880,53 @@ void kvm_resched(struct kvm_vcpu *vcpu)
}
EXPORT_SYMBOL_GPL(kvm_resched);
-void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu)
+void kvm_vcpu_on_spin(struct kvm_vcpu *me)
{
- ktime_t expires;
- DEFINE_WAIT(wait);
+ struct kvm *kvm = me-kvm;
+ struct kvm_vcpu *vcpu;
+ int last_boosted_vcpu = me-kvm-last_boosted_vcpu;
s/me-//
+ int first_round = 1;
+ int i;
- prepare_to_wait(vcpu-wq,wait, TASK_INTERRUPTIBLE);
+ me-spinning = 1;
+
+ /*
+ * We boost the priority of a VCPU that is runnable but not
+ * currently running, because it got preempted by something
+ * else and called schedule in __vcpu_run. Hopefully that
+ * VCPU is holding the lock that we need and will release it.
+ * We approximate round-robin by starting at the last boosted VCPU.
+ */
+ again:
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ struct task_struct *task = vcpu-task;
+ if (first_round i last_boosted_vcpu) {
+ i = last_boosted_vcpu;
+ continue;
+ } else if (!first_round i last_boosted_vcpu)
+ break;
+ if (vcpu == me)
+ continue;
+ if (vcpu-spinning)
+ continue;
+ if (!task)
+ continue;
+ if (waitqueue_active(vcpu-wq))
+ continue;
+ if (task-flags PF_VCPU)
+ continue;
I wonder if you set vcpu-task in sched_out and then NULL it in sched_in
if you'd get what you want you could simplify the checks. Basically
that would be only the preempted runnable vcpus.
They may be sleeping due to some other reason (HLT, major page fault).
Better check is that the task is runnable but not running. Can we get
this information from a task?
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] kvm: keep track of which task is running a KVM vcpu
On 12/03/2010 04:16 PM, Rik van Riel wrote: On 12/03/2010 07:17 AM, Srivatsa Vaddagiri wrote: On Thu, Dec 02, 2010 at 02:43:24PM -0500, Rik van Riel wrote: mutex_lock(vcpu-mutex); +vcpu-task = current; Shouldn't we grab reference to current task_struct before storing a pointer to it? That should not be needed, since current cannot go away without setting vcpu-task back to NULL in vcpu_put. However, you do reference vcpu-task from other contexts. So some sort of safe reference is needed. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] directed yield for Pause Loop Exiting
On 12/03/2010 12:41 AM, Chris Wright wrote: * Rik van Riel (r...@redhat.com) wrote: When running SMP virtual machines, it is possible for one VCPU to be spinning on a spinlock, while the VCPU that holds the spinlock is not currently running, because the host scheduler preempted it to run something else. Both Intel and AMD CPUs have a feature that detects when a virtual CPU is spinning on a lock and will trap to the host. The current KVM code sleeps for a bit whenever that happens, which results in eg. a 64 VCPU Windows guest taking forever and a bit to boot up. This is because the VCPU holding the lock is actually running and not sleeping, so the pause is counter-productive. Seems like simply increasing the spin window help in that case? Or is it just too contended a lock (I think they use mcs locks, so I can see a single wrong sleep causing real contention problems). It may, but that just pushes the problem to a more contended lock or to a higher vcpu count. We want something that works after PLE threshold tuning has failed. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 rebased] KVM: MMU: Avoid dropping accessed bit while removing write access
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp One more KVM: MMU: Don't drop accessed bit while updating an spte. Sptes are accessed by both kvm and hardware. This patch uses update_spte() to fix the way of removing write access. Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp --- arch/x86/kvm/mmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 04c49b9..d75ba1e 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -3446,7 +3446,7 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm, int slot) for (i = 0; i PT64_ENT_PER_PAGE; ++i) /* avoid RMW */ if (is_writable_pte(pt[i])) - pt[i] = ~PT_WRITABLE_MASK; + update_spte(pt[i], pt[i] ~PT_WRITABLE_MASK); } kvm_flush_remote_tlbs(kvm); } -- 1.7.1 -- 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
[PATCH 2/2 rebased] KVM: MMU: Introduce a helper to access lpage_info
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Index calculation to access lpage_info appears three times.
A helper is worthwhile.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/mmu.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d75ba1e..e434503 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -476,6 +476,12 @@ static void kvm_mmu_page_set_gfn(struct kvm_mmu_page *sp,
int index, gfn_t gfn)
sp-gfns[index] = gfn;
}
+static unsigned long lpage_idx(gfn_t gfn, gfn_t base_gfn, int level)
+{
+ return (gfn KVM_HPAGE_GFN_SHIFT(level)) -
+ (base_gfn KVM_HPAGE_GFN_SHIFT(level));
+}
+
/*
* Return the pointer to the largepage write count for a given
* gfn, handling slots that are not large page aligned.
@@ -484,10 +490,8 @@ static int *slot_largepage_idx(gfn_t gfn,
struct kvm_memory_slot *slot,
int level)
{
- unsigned long idx;
+ unsigned long idx = lpage_idx(gfn, slot-base_gfn, level);
- idx = (gfn KVM_HPAGE_GFN_SHIFT(level)) -
- (slot-base_gfn KVM_HPAGE_GFN_SHIFT(level));
return slot-lpage_info[level - 2][idx].write_count;
}
@@ -591,8 +595,7 @@ static unsigned long *gfn_to_rmap(struct kvm *kvm, gfn_t
gfn, int level)
if (likely(level == PT_PAGE_TABLE_LEVEL))
return slot-rmap[gfn - slot-base_gfn];
- idx = (gfn KVM_HPAGE_GFN_SHIFT(level)) -
- (slot-base_gfn KVM_HPAGE_GFN_SHIFT(level));
+ idx = lpage_idx(gfn, slot-base_gfn, level);
return slot-lpage_info[level - 2][idx].rmap_pde;
}
@@ -887,11 +890,10 @@ static int kvm_handle_hva(struct kvm *kvm, unsigned long
hva,
for (j = 0; j KVM_NR_PAGE_SIZES - 1; ++j) {
unsigned long idx;
- int sh;
- sh = KVM_HPAGE_GFN_SHIFT(PT_DIRECTORY_LEVEL+j);
- idx = ((memslot-base_gfn+gfn_offset) sh) -
- (memslot-base_gfn sh);
+ idx = lpage_idx(memslot-base_gfn + gfn_offset,
+ memslot-base_gfn,
+ PT_DIRECTORY_LEVEL + j);
ret |= handler(kvm,
memslot-lpage_info[j][idx].rmap_pde,
data);
--
1.7.1
--
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
[PATCH 0/2] Keep cr3 cached in VMCS
This patchset keeps cr3 cached in the VMCS (GUEST_CR3) instead of syncing it every exit. Saves a VMEXIT on Intel with EPT enabled. Avi Kivity (2): KVM: Replace reads of vcpu-arch.cr3 by an accessor KVM: Fetch guest cr3 from hardware on demand arch/x86/include/asm/kvm_host.h |2 ++ arch/x86/kvm/kvm_cache_regs.h |7 +++ arch/x86/kvm/mmu.c |6 +++--- arch/x86/kvm/svm.c | 13 + arch/x86/kvm/vmx.c | 24 +++- arch/x86/kvm/x86.c | 19 ++- 6 files changed, 46 insertions(+), 25 deletions(-) -- 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
[PATCH 1/2] KVM: Replace reads of vcpu-arch.cr3 by an accessor
This allows us to keep cr3 in the VMCS, later on.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/kvm_cache_regs.h |5 +
arch/x86/kvm/mmu.c|6 +++---
arch/x86/kvm/svm.c|8
arch/x86/kvm/vmx.c|7 ---
arch/x86/kvm/x86.c| 19 ++-
5 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h
index 95ac3af..a6bf8db 100644
--- a/arch/x86/kvm/kvm_cache_regs.h
+++ b/arch/x86/kvm/kvm_cache_regs.h
@@ -73,6 +73,11 @@ static inline ulong kvm_read_cr4_bits(struct kvm_vcpu *vcpu,
ulong mask)
return vcpu-arch.cr4 mask;
}
+static inline ulong kvm_read_cr3(struct kvm_vcpu *vcpu)
+{
+ return vcpu-arch.cr3;
+}
+
static inline ulong kvm_read_cr4(struct kvm_vcpu *vcpu)
{
return kvm_read_cr4_bits(vcpu, ~0UL);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 04c49b9..e0c447f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2726,13 +2726,13 @@ void kvm_mmu_flush_tlb(struct kvm_vcpu *vcpu)
static void paging_new_cr3(struct kvm_vcpu *vcpu)
{
- pgprintk(%s: cr3 %lx\n, __func__, vcpu-arch.cr3);
+ pgprintk(%s: cr3 %lx\n, __func__, kvm_read_cr3(vcpu));
mmu_free_roots(vcpu);
}
static unsigned long get_cr3(struct kvm_vcpu *vcpu)
{
- return vcpu-arch.cr3;
+ return kvm_read_cr3(vcpu);
}
static void inject_page_fault(struct kvm_vcpu *vcpu,
@@ -3631,7 +3631,7 @@ static int kvm_pv_mmu_write(struct kvm_vcpu *vcpu,
static int kvm_pv_mmu_flush_tlb(struct kvm_vcpu *vcpu)
{
- (void)kvm_set_cr3(vcpu, vcpu-arch.cr3);
+ (void)kvm_set_cr3(vcpu, kvm_read_cr3(vcpu));
return 1;
}
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index ae943bb..5e4b120 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1135,7 +1135,7 @@ static void svm_cache_reg(struct kvm_vcpu *vcpu, enum
kvm_reg reg)
switch (reg) {
case VCPU_EXREG_PDPTR:
BUG_ON(!npt_enabled);
- load_pdptrs(vcpu, vcpu-arch.walk_mmu, vcpu-arch.cr3);
+ load_pdptrs(vcpu, vcpu-arch.walk_mmu, kvm_read_cr3(vcpu));
break;
default:
BUG();
@@ -2063,7 +2063,7 @@ static int nested_svm_vmexit(struct vcpu_svm *svm)
nested_vmcb-save.idtr = vmcb-save.idtr;
nested_vmcb-save.efer = svm-vcpu.arch.efer;
nested_vmcb-save.cr0= kvm_read_cr0(svm-vcpu);
- nested_vmcb-save.cr3= svm-vcpu.arch.cr3;
+ nested_vmcb-save.cr3= kvm_read_cr3(svm-vcpu);
nested_vmcb-save.cr2= vmcb-save.cr2;
nested_vmcb-save.cr4= svm-vcpu.arch.cr4;
nested_vmcb-save.rflags = vmcb-save.rflags;
@@ -2256,7 +2256,7 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
if (npt_enabled)
hsave-save.cr3= vmcb-save.cr3;
else
- hsave-save.cr3= svm-vcpu.arch.cr3;
+ hsave-save.cr3= kvm_read_cr3(svm-vcpu);
copy_vmcb_control_area(hsave, vmcb);
@@ -3507,7 +3507,7 @@ static void set_tdp_cr3(struct kvm_vcpu *vcpu, unsigned
long root)
svm-vmcb-control.nested_cr3 = root;
/* Also sync guest cr3 here in case we live migrate */
- svm-vmcb-save.cr3 = vcpu-arch.cr3;
+ svm-vmcb-save.cr3 = kvm_read_cr3(vcpu);
force_new_asid(vcpu);
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 72cfdb7..92f2c72 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1940,7 +1940,7 @@ static void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned
long cr3)
if (enable_ept) {
eptp = construct_eptp(cr3);
vmcs_write64(EPT_POINTER, eptp);
- guest_cr3 = is_paging(vcpu) ? vcpu-arch.cr3 :
+ guest_cr3 = is_paging(vcpu) ? kvm_read_cr3(vcpu) :
vcpu-kvm-arch.ept_identity_map_addr;
ept_load_pdptrs(vcpu);
}
@@ -3184,8 +3184,9 @@ static int handle_cr(struct kvm_vcpu *vcpu)
case 1: /*mov from cr*/
switch (cr) {
case 3:
- kvm_register_write(vcpu, reg, vcpu-arch.cr3);
- trace_kvm_cr_read(cr, vcpu-arch.cr3);
+ val = kvm_read_cr3(vcpu);
+ kvm_register_write(vcpu, reg, val);
+ trace_kvm_cr_read(cr, val);
skip_emulated_instruction(vcpu);
return 1;
case 8:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ed373ba..4748499 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -469,8 +469,8 @@ static bool pdptrs_changed(struct kvm_vcpu *vcpu)
(unsigned long *)vcpu-arch.regs_avail))
return true;
- gfn = (vcpu-arch.cr3 ~31u) PAGE_SHIFT;
- offset = (vcpu-arch.cr3 ~31u) (PAGE_SIZE - 1);
+ gfn =
[PATCH 2/2] KVM: Fetch guest cr3 from hardware on demand
Instead of syncing the guest cr3 every exit, which is expensince on vmx
with ept enabled, sync it only on demand.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/kvm_cache_regs.h |2 ++
arch/x86/kvm/svm.c |5 +
arch/x86/kvm/vmx.c | 17 +++--
4 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index cfbcbfa..4bd8daa 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -117,6 +117,7 @@ enum kvm_reg {
enum kvm_reg_ex {
VCPU_EXREG_PDPTR = NR_VCPU_REGS,
+ VCPU_EXREG_CR3,
};
enum {
@@ -532,6 +533,7 @@ struct kvm_x86_ops {
struct kvm_segment *var, int seg);
void (*get_cs_db_l_bits)(struct kvm_vcpu *vcpu, int *db, int *l);
void (*decache_cr0_guest_bits)(struct kvm_vcpu *vcpu);
+ void (*decache_cr3)(struct kvm_vcpu *vcpu);
void (*decache_cr4_guest_bits)(struct kvm_vcpu *vcpu);
void (*set_cr0)(struct kvm_vcpu *vcpu, unsigned long cr0);
void (*set_cr3)(struct kvm_vcpu *vcpu, unsigned long cr3);
diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h
index a6bf8db..3377d53 100644
--- a/arch/x86/kvm/kvm_cache_regs.h
+++ b/arch/x86/kvm/kvm_cache_regs.h
@@ -75,6 +75,8 @@ static inline ulong kvm_read_cr4_bits(struct kvm_vcpu *vcpu,
ulong mask)
static inline ulong kvm_read_cr3(struct kvm_vcpu *vcpu)
{
+ if (!test_bit(VCPU_EXREG_CR3, (ulong *)vcpu-arch.regs_avail))
+ kvm_x86_ops-decache_cr3(vcpu);
return vcpu-arch.cr3;
}
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 5e4b120..91af472 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1286,6 +1286,10 @@ static void svm_decache_cr0_guest_bits(struct kvm_vcpu
*vcpu)
{
}
+static void svm_decache_cr3(struct kvm_vcpu *vcpu)
+{
+}
+
static void svm_decache_cr4_guest_bits(struct kvm_vcpu *vcpu)
{
}
@@ -3683,6 +3687,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.get_cpl = svm_get_cpl,
.get_cs_db_l_bits = kvm_get_cs_db_l_bits,
.decache_cr0_guest_bits = svm_decache_cr0_guest_bits,
+ .decache_cr3 = svm_decache_cr3,
.decache_cr4_guest_bits = svm_decache_cr4_guest_bits,
.set_cr0 = svm_set_cr0,
.set_cr3 = svm_set_cr3,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 92f2c72..8d7b85a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1817,6 +1817,14 @@ static void vmx_decache_cr0_guest_bits(struct kvm_vcpu
*vcpu)
vcpu-arch.cr0 |= vmcs_readl(GUEST_CR0) cr0_guest_owned_bits;
}
+static void vmx_decache_cr3(struct kvm_vcpu *vcpu)
+{
+ /* Can only be called with EPT enabled */
+ if (enable_ept)
+ vcpu-arch.cr3 = vmcs_readl(GUEST_CR3);
+ __set_bit(VCPU_EXREG_CR3, (ulong *)vcpu-arch.regs_avail);
+}
+
static void vmx_decache_cr4_guest_bits(struct kvm_vcpu *vcpu)
{
ulong cr4_guest_owned_bits = vcpu-arch.cr4_guest_owned_bits;
@@ -3713,11 +3721,6 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu)
if (vmx-emulation_required emulate_invalid_guest_state)
return handle_invalid_guest_state(vcpu);
- /* Access CR3 don't cause VMExit in paging mode, so we need
-* to sync with guest real CR3. */
- if (enable_ept is_paging(vcpu))
- vcpu-arch.cr3 = vmcs_readl(GUEST_CR3);
-
if (exit_reason VMX_EXIT_REASONS_FAILED_VMENTRY) {
vcpu-run-exit_reason = KVM_EXIT_FAIL_ENTRY;
vcpu-run-fail_entry.hardware_entry_failure_reason
@@ -4034,7 +4037,8 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
);
vcpu-arch.regs_avail = ~((1 VCPU_REGS_RIP) | (1 VCPU_REGS_RSP)
- | (1 VCPU_EXREG_PDPTR));
+ | (1 VCPU_EXREG_PDPTR)
+ | (1 VCPU_EXREG_CR3));
vcpu-arch.regs_dirty = 0;
vmx-idt_vectoring_info = vmcs_read32(IDT_VECTORING_INFO_FIELD);
@@ -4306,6 +4310,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.get_cpl = vmx_get_cpl,
.get_cs_db_l_bits = vmx_get_cs_db_l_bits,
.decache_cr0_guest_bits = vmx_decache_cr0_guest_bits,
+ .decache_cr3 = vmx_decache_cr3,
.decache_cr4_guest_bits = vmx_decache_cr4_guest_bits,
.set_cr0 = vmx_set_cr0,
.set_cr3 = vmx_set_cr3,
--
1.7.1
--
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
Re: PCI passthrough on Sony Vaio F11 laptop...
Jan Kiszka wrote: Am 15.11.2010 22:55, Erik Brakkee wrote: Jan Kiszka wrote: Am 14.11.2010 14:21, Erik Brakkee wrote: Jan Kiszka wrote: Strange, should work. I would suggest to post your full kernel log, maybe there is some enlightening message hidden. I don't think it is a problem of your kernel version, but I'm able to pass through devices on OpenSUSE 11.3 with kernel-desktop-2.6.36-90.1.x86_64 from their kernel repository. Jan Exactly what server logs do you need. Is this only /var/log/messages or more? And do I need to set specific options there? Any other log files that you need? dmesg log-file Before, generating these logs I will upgrade to a later kernel. As far as I can tell, that will still be a 2.6.34 kernel. Perhaps I should try the 2.6.36 kernel as well. Do you have the URL for the kernel repository I should use? (cannot find an obvious kernel repository in YAST2). http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_11.3 Jan I have attached the logs of /var/log/messages, dmesg, and qemu log (other.log), as well as the kernel config parameters (/proc/config.gz). I did the test with two kernels (see the tar.gz file): one kernel a 2.6.34 and the other a 2.6.36 kernel. Comparing the dmesg with my kernel log, I'm missing messages like [0.023960] DMAR: Host address width 36 [0.023962] DMAR: DRHD base: 0x00fed9 flags: 0x0 [0.023968] IOMMU 0: reg_base_addr fed9 ver 1:0 cap c9008020e30272 ecap 1000 [0.023970] DMAR: DRHD base: 0x00fed93000 flags: 0x1 [0.023974] IOMMU 1: reg_base_addr fed93000 ver 1:0 cap c9008020630272 ecap 1000 [0.023976] DMAR: RMRR base: 0x00bf6e9000 end: 0x00bf6f [0.023978] DMAR: No ATSR found about the Intel DMAR (IOMMU) setup. Are you sure that you have an Intel chipset with the required features? And have you checked that VT-d is enabled in the BIOS (or however it may be called there)? Jan I have now done a PCI passthrough test on some real hardware. Supermicro X8DTi-F motherboard (intel 5520 chipset), Intel Xeon L5630 processor. I enabled Intel VT-d in the BIOS and them simply selected one of the network interfaces for passthrough the the VM. And then... it just worksd. Also, I am seeing output similar to what you posted above. -- 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
Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v4)
On Sat, Dec 04, 2010 at 08:43:21AM -0600, Anthony Liguori wrote: In certain use-cases, we want to allocate guests fixed time slices where idle guest cycles leave the machine idling. There are many approaches to achieve this but the most direct is to simply avoid trapping the HLT instruction which lets the guest directly execute the instruction putting the processor to sleep. A vcpu could be idle not just because of lack of work, but also because its waiting on IO completion. Normally idle vcpus that yield would allow their companion threads to run and possibly finish pending IO work faster. Now that idle vcpu won't yield, it would cause overall cpu cycle demand of VMs to go up (100% demand from VM's idle/not-idle vcpus + whatever their companion threads demand) not to mention any impact on IO latencies. Not sure how much of an issue this will be in practice, but something to keep in mind when we test! Also, just curious how this would work for idle vcpus that use mwait rather than hlt. - vatsa -- 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
Re: [PATCH 2/2] tools/virtio: virtio_test tool
On Tue, 30 Nov 2010 03:46:37 am Michael S. Tsirkin wrote: This is the userspace part of the tool: it includes a bunch of stubs for linux APIs, somewhat simular to linuxsched. This makes it possible to recompile the ring code in userspace. A small test example is implemented combining this with vhost_test module. Signed-off-by: Michael S. Tsirkin m...@redhat.com Hi Michael, I'm not sure what the point is of this work? You'll still need to benchmark on real systems, but it's not low-level enough to measure things like cache misses. I'm assuming you're thinking of playing with layout to measure cache behaviour. I was thinking of a complete userspace implementation where either it was run under cachegrind, or each access was wrapped to allow tracking of cachelines to give an exact measure of cache movement under various scenarios (esp. ring mostly empty, ring in steady state, ring mostly full). Cheers, Rusty. -- 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
Re: [PATCH 2/2 rebased] KVM: MMU: Introduce a helper to access lpage_info
On 12/06/2010 12:13 AM, Takuya Yoshikawa wrote: From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp Index calculation to access lpage_info appears three times. A helper is worthwhile. Why not get lpage_info instead of index in the helper? -- 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
Re: [PATCH 2/2 rebased] KVM: MMU: Introduce a helper to access lpage_info
(2010/12/06 15:37), Xiao Guangrong wrote: On 12/06/2010 12:13 AM, Takuya Yoshikawa wrote: From: Takuya Yoshikawayoshikawa.tak...@oss.ntt.co.jp Index calculation to access lpage_info appears three times. A helper is worthwhile. Why not get lpage_info instead of index in the helper? Seems a better way! I didn't think about it. I'll check and resend [2/2] if it's OK. Thanks, Takuya -- 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
