Re: [GIT PULL] KVM/ARM Changes for 3.10
On Mon, Apr 29, 2013 at 7:11 PM, Marcelo Tosatti wrote: > On Sun, Apr 28, 2013 at 10:29:07PM -0700, Christoffer Dall wrote: >> Hi Marcelo and Gleb, >> >> These are the changes for KVM/ARM for 3.10. >> >> The patches depend on the cleanup branch, which you've already merged. >> >> Main thing is the reworking of Hyp idmaps, which is now handled by KVM >> instead of arm/mm and includes several nasty bug fixes from Marc in >> the progress. >> >> Thanks! >> >> The following changes since commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6: >> >> KVM: nVMX: Skip PF interception check when queuing during nested run >> (2013-04-28 13:34:39 +0300) >> >> are available in the git repository at: >> >> git://github.com/columbia/linux-kvm-arm.git kvm-arm-for-3.10 >> >> for you to fetch changes up to d4e071ce6acf8d5eddb7615a953193a8b0ad7c38: >> >> ARM: KVM: iterate over all CPUs for CPU compatibility check >> (2013-04-28 22:23:23 -0700) > > Christoffer, > > Please email the patches to kvm@vger. > > each of them were already cc'ed on the kvm mailing list when they were reviewed I believe, but would you like to have them re-sent as they are not in this pull request even if it means re-sending them? -Christoffer -- 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: KVM_CAP_IOMMU only available with device assignment
On Mon, Apr 29, 2013 at 09:59:30AM -0700, Randy Dunlap wrote: > On 04/29/13 09:54, Alex Williamson wrote: > > Fix build with CONFIG_PCI unset by linking KVM_CAP_IOMMU to > > device assignment config option. It has no purpose otherwise. > > > > Signed-off-by: Alex Williamson > > Reported-by: Randy Dunlap > Acked-by: Randy Dunlap > > Thanks. Applied, thanks. -- 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: [GIT PULL] KVM/ARM Changes for 3.10
On Sun, Apr 28, 2013 at 10:29:07PM -0700, Christoffer Dall wrote: > Hi Marcelo and Gleb, > > These are the changes for KVM/ARM for 3.10. > > The patches depend on the cleanup branch, which you've already merged. > > Main thing is the reworking of Hyp idmaps, which is now handled by KVM > instead of arm/mm and includes several nasty bug fixes from Marc in > the progress. > > Thanks! > > The following changes since commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6: > > KVM: nVMX: Skip PF interception check when queuing during nested run > (2013-04-28 13:34:39 +0300) > > are available in the git repository at: > > git://github.com/columbia/linux-kvm-arm.git kvm-arm-for-3.10 > > for you to fetch changes up to d4e071ce6acf8d5eddb7615a953193a8b0ad7c38: > > ARM: KVM: iterate over all CPUs for CPU compatibility check > (2013-04-28 22:23:23 -0700) Christoffer, Please email the patches to kvm@vger. -- 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 unit test] add test for "mov[zs]x %ah, ..." instruction
On Wed, Apr 24, 2013 at 01:50:40PM +0300, Gleb Natapov wrote: > > Signed-off-by: Gleb Natapov > diff --git a/x86/realmode.c b/x86/realmode.c Applied, thanks. -- 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] kvm/ppc/mpic: remove default routes from documentation
The default routes were removed from the code during patchset respinning, but were not removed from the documentation. Signed-off-by: Scott Wood --- Documentation/virtual/kvm/devices/mpic.txt |3 --- 1 file changed, 3 deletions(-) diff --git a/Documentation/virtual/kvm/devices/mpic.txt b/Documentation/virtual/kvm/devices/mpic.txt index ad0ac77..8257397 100644 --- a/Documentation/virtual/kvm/devices/mpic.txt +++ b/Documentation/virtual/kvm/devices/mpic.txt @@ -50,7 +50,4 @@ IRQ Routing: regard to any subdivisions in chip documentation such as "internal" or "external" interrupts. - Default routes are established for these pins, with the GSI being equal - to the pin number. - Access to non-SRC interrupts is not implemented through IRQ routing mechanisms. -- 1.7.10.4 -- 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: virtio PCI on KVM without IO BARs
On 04/29/2013 07:48 AM, Don Dutile wrote: > > c) it's architecture neutral, or can be made architecture neutral. >e.g., inb/outb & PCI ioport support is very different btwn x86 & > non-x86. >A hypercall interface would not have that dependency/difference. > You are joking, right? Hypercalls are if anything *more* architecture and OS dependent. -hpa -- 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: recent kvm-kmod commit breaks on F18
On Mon, Apr 29, 2013 at 10:41:36PM +0200, Jan Kiszka wrote: > On 2013-04-29 22:39, Gabriel L. Somlo wrote: > > On Mon, Apr 29, 2013 at 10:33:29PM +0200, Jan Kiszka wrote: > >> I dare to say that ../kvm/virt/kvm/irqchip.c does not exit, thus your > >> external kvm directory is not recent enough. > > > git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git > > git checkout [-b ] origin/next > > If you run "git submodule update" from inside kvm-mod, this checkout is > done for you already. Hmm... "origin/next" doesn't seem to be an available option. Aside from "kvm-XYZ" and "vX.Y.Z-rcABC", there's HEAD, master, origin/HEAD, and origin/MASTER. Picking either one of those doesn't seem to help. FWIW, "git submodule update" checks out commit 5a2892ce72e010e3cb96b438d7cdddce0c88e0e6 as a detached head, but explicitly checking that out in the vanilla clone of KVM before using LINUX=../kvm still doesn't work... Aside from wondering what's wrong with just the kvm default "master", I think I need to go learn some more about git :) Thanks, --Gabriel -- 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: recent kvm-kmod commit breaks on F18
On 2013-04-29 22:39, Gabriel L. Somlo wrote: > On Mon, Apr 29, 2013 at 10:33:29PM +0200, Jan Kiszka wrote: >> I dare to say that ../kvm/virt/kvm/irqchip.c does not exit, thus your >> external kvm directory is not recent enough. > > That's weird, I just did a > > git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git git checkout [-b ] origin/next If you run "git submodule update" from inside kvm-mod, this checkout is done for you already. Jan > > literally five minutes ago, specifically to test your "LINUX=..." > method before replying, on the off chance there would have been a > difference in behavior vs. the symlink thing I was complaining > about earlier... > > --G > signature.asc Description: OpenPGP digital signature
Re: recent kvm-kmod commit breaks on F18
On Mon, Apr 29, 2013 at 10:33:29PM +0200, Jan Kiszka wrote: > I dare to say that ../kvm/virt/kvm/irqchip.c does not exit, thus your > external kvm directory is not recent enough. That's weird, I just did a git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git literally five minutes ago, specifically to test your "LINUX=..." method before replying, on the off chance there would have been a difference in behavior vs. the symlink thing I was complaining about earlier... --G -- 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: recent kvm-kmod commit breaks on F18
On 2013-04-29 22:30, Gabriel L. Somlo wrote: > On Mon, Apr 29, 2013 at 10:09:42PM +0200, Jan Kiszka wrote: >> On 2013-04-29 21:44, Gabriel L. Somlo wrote: >>> On Mon, Apr 29, 2013 at 09:06:37PM +0200, Jan Kiszka wrote: > Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417 >> Linking should work as well, though is unnecessary: >> >>make LINUX=/path/to/your/repo sync >> >> That's what I'm doing all the time to test my kvm hacks on my >> not-so-recent host kernel. > > OK, I "git clone"d both kvm and kvm-kmod right alongside each other in > a test directory. I then went into kvm-kmod, and did > > ./configure > make LINUX=../kvm sync > make > > and got the same error as before: > > > make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` \ > LINUXINCLUDE="-I`pwd`/include -I`pwd`/include/uapi -Iinclude \ > -Iinclude2 > -I/lib/modules/3.8.9-200.fc18.x86_64/source/include > -I/lib/modules/3.8.9-200.fc18.x86_64/source/include/uapi > -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include > -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include/uapi \ > -Iinclude/generated/uapi -Iarch/x86/include/generated > \ > -Iarch/x86/include/generated/uapi \ > -I`pwd`/include-compat -I`pwd`/x86 \ > -include include/generated/autoconf.h \ > -include `pwd`/x86/external-module-compat.h" \ > "$@" > make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > make[3]: *** No rule to make target > `/home/somlo/FOO/kvm-kmod/x86/irqchip.o', needed by > `/home/somlo/FOO/kvm-kmod/x86/kvm.o'. Stop. > make[2]: *** [/home/somlo/FOO/kvm-kmod/x86] Error 2 > make[1]: *** [_module_/home/somlo/FOO/kvm-kmod] Error 2 > make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > make: *** [all] Error 2 > > > This happens when I symlink (or use LINUX=../kvm with "make sync"), > but works OK with "git submodule update --init" (which I'd rather > avoid if possible). I dare to say that ../kvm/virt/kvm/irqchip.c does not exit, thus your external kvm directory is not recent enough. Jan signature.asc Description: OpenPGP digital signature
Re: recent kvm-kmod commit breaks on F18
On Mon, Apr 29, 2013 at 10:09:42PM +0200, Jan Kiszka wrote: > On 2013-04-29 21:44, Gabriel L. Somlo wrote: > > On Mon, Apr 29, 2013 at 09:06:37PM +0200, Jan Kiszka wrote: > >>> Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417 > Linking should work as well, though is unnecessary: > >make LINUX=/path/to/your/repo sync > > That's what I'm doing all the time to test my kvm hacks on my > not-so-recent host kernel. OK, I "git clone"d both kvm and kvm-kmod right alongside each other in a test directory. I then went into kvm-kmod, and did ./configure make LINUX=../kvm sync make and got the same error as before: make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` \ LINUXINCLUDE="-I`pwd`/include -I`pwd`/include/uapi -Iinclude \ -Iinclude2 -I/lib/modules/3.8.9-200.fc18.x86_64/source/include -I/lib/modules/3.8.9-200.fc18.x86_64/source/include/uapi -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include/uapi \ -Iinclude/generated/uapi -Iarch/x86/include/generated \ -Iarch/x86/include/generated/uapi \ -I`pwd`/include-compat -I`pwd`/x86 \ -include include/generated/autoconf.h \ -include `pwd`/x86/external-module-compat.h" \ "$@" make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' make[3]: *** No rule to make target `/home/somlo/FOO/kvm-kmod/x86/irqchip.o', needed by `/home/somlo/FOO/kvm-kmod/x86/kvm.o'. Stop. make[2]: *** [/home/somlo/FOO/kvm-kmod/x86] Error 2 make[1]: *** [_module_/home/somlo/FOO/kvm-kmod] Error 2 make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' make: *** [all] Error 2 This happens when I symlink (or use LINUX=../kvm with "make sync"), but works OK with "git submodule update --init" (which I'd rather avoid if possible). Thanks, --Gabriel -- 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: recent kvm-kmod commit breaks on F18
On 2013-04-29 21:44, Gabriel L. Somlo wrote: > On Mon, Apr 29, 2013 at 09:06:37PM +0200, Jan Kiszka wrote: >>> Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417 >> >> That commit alone is broken as it depends on the refactorings being >> selected by the submodule update. >> >> Does the problem persist with current master checked out into a clean >> folder? > > OK, after further digging, following your canonical steps > (i.e. "git submodule update --init") seems to work without problems. > > Instead, i was replacing the "linux" directory from kvm-kmod with a > symlink to ../kvm (itself obtained via "git clone"), in a (potentially > misguided) attempt to stay on the master branch of both projects. > > That *used* to work until the recent update. Now that I know I'm > "off the reservation", I haven't yet figured out how "reasonable" vs. > "bone-headed" of a thing that is... :) Linking should work as well, though is unnecessary: make LINUX=/path/to/your/repo sync That's what I'm doing all the time to test my kvm hacks on my not-so-recent host kernel. Jan signature.asc Description: OpenPGP digital signature
Re: recent kvm-kmod commit breaks on F18
On Mon, Apr 29, 2013 at 09:06:37PM +0200, Jan Kiszka wrote: > > Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417 > > That commit alone is broken as it depends on the refactorings being > selected by the submodule update. > > Does the problem persist with current master checked out into a clean > folder? OK, after further digging, following your canonical steps (i.e. "git submodule update --init") seems to work without problems. Instead, i was replacing the "linux" directory from kvm-kmod with a symlink to ../kvm (itself obtained via "git clone"), in a (potentially misguided) attempt to stay on the master branch of both projects. That *used* to work until the recent update. Now that I know I'm "off the reservation", I haven't yet figured out how "reasonable" vs. "bone-headed" of a thing that is... :) Any further clue much appreciated ! Thx, --Gabriel -- 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: recent kvm-kmod commit breaks on F18
On 2013-04-29 20:33, Gabriel L. Somlo wrote: > Jan, > > Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417 That commit alone is broken as it depends on the refactorings being selected by the submodule update. Does the problem persist with current master checked out into a clean folder? Jan > to kvm-kmod is what causes breakage on my (otherwise stock) F18 box > (with kernel version 3.8.9-200.fc18.x86_64): > > make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` clean > make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > CLEAN /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/.tmp_versions > make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > rm -f config.mak kvm-kmod-config.h include/asm include-compat/asm > .tmp.kvm-kmod.spec > make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` clean > make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > ./sync -v v3.8-12811-gebe8054 -l ./linux > make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` \ > LINUXINCLUDE="-I`pwd`/include -I`pwd`/include/uapi -Iinclude \ > -Iinclude2 > -I/lib/modules/3.8.9-200.fc18.x86_64/source/include > -I/lib/modules/3.8.9-200.fc18.x86_64/source/include/uapi > -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include > -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include/uapi \ > -Iinclude/generated/uapi -Iarch/x86/include/generated > \ > -Iarch/x86/include/generated/uapi \ > -I`pwd`/include-compat -I`pwd`/x86 \ > -include include/generated/autoconf.h \ > -include `pwd`/x86/external-module-compat.h" \ > "$@" > make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > LD /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/built-in.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/svm.o > /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/svm.c:2790:12: warning: > `invalid_op_interception' defined but not used [-Wunused-function] > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/vmx.o > /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/vmx.c:5313:12: warning: > `handle_invalid_op' defined but not used [-Wunused-function] > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/kvm_main.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/mmu.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/emulate.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/irq.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/i8259.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/pmu.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/lapic.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/ioapic.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/preempt.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/i8254.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/coalesced_mmio.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/irq_comm.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/eventfd.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/compat-x86.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/async_pf.o > CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/cpuid.o > make[3]: *** No rule to make target > `/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/irqchip.o', needed by > `/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/kvm.o'. Stop. > make[2]: *** [/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86] Error 2 > make[1]: *** [_module_/home/somlo/KVM-OSX/SCRATCH/kvm-kmod] Error 2 > make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' > make: *** [all] Error 2 > > Thanks, > --Gabriel signature.asc Description: OpenPGP digital signature
recent kvm-kmod commit breaks on F18
Jan, Bisect says that commit 4fb60de74f93a601775dbda053b3237634d7a417 to kvm-kmod is what causes breakage on my (otherwise stock) F18 box (with kernel version 3.8.9-200.fc18.x86_64): make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` clean make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' CLEAN /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/.tmp_versions make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' rm -f config.mak kvm-kmod-config.h include/asm include-compat/asm .tmp.kvm-kmod.spec make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` clean make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' ./sync -v v3.8-12811-gebe8054 -l ./linux make -C /lib/modules/3.8.9-200.fc18.x86_64/build M=`pwd` \ LINUXINCLUDE="-I`pwd`/include -I`pwd`/include/uapi -Iinclude \ -Iinclude2 -I/lib/modules/3.8.9-200.fc18.x86_64/source/include -I/lib/modules/3.8.9-200.fc18.x86_64/source/include/uapi -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include -I/lib/modules/3.8.9-200.fc18.x86_64/source/arch/x86/include/uapi \ -Iinclude/generated/uapi -Iarch/x86/include/generated \ -Iarch/x86/include/generated/uapi \ -I`pwd`/include-compat -I`pwd`/x86 \ -include include/generated/autoconf.h \ -include `pwd`/x86/external-module-compat.h" \ "$@" make[1]: Entering directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' LD /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/built-in.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/svm.o /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/svm.c:2790:12: warning: `invalid_op_interception' defined but not used [-Wunused-function] CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/vmx.o /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/vmx.c:5313:12: warning: `handle_invalid_op' defined but not used [-Wunused-function] CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/kvm_main.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/x86.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/mmu.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/emulate.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/irq.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/i8259.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/pmu.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/lapic.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/ioapic.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/preempt.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/i8254.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/coalesced_mmio.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/irq_comm.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/eventfd.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/compat-x86.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/async_pf.o CC [M] /home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/cpuid.o make[3]: *** No rule to make target `/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/irqchip.o', needed by `/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86/kvm.o'. Stop. make[2]: *** [/home/somlo/KVM-OSX/SCRATCH/kvm-kmod/x86] Error 2 make[1]: *** [_module_/home/somlo/KVM-OSX/SCRATCH/kvm-kmod] Error 2 make[1]: Leaving directory `/usr/src/kernels/3.8.9-200.fc18.x86_64' make: *** [all] Error 2 Thanks, --Gabriel -- 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 v3 08/32] arm64: KVM: architecture specific MMU backend
On Mon, Apr 08, 2013 at 05:17:10PM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm64/include/asm/kvm_mmu.h
> b/arch/arm64/include/asm/kvm_mmu.h
> new file mode 100644
> index 000..2eb2230
> --- /dev/null
> +++ b/arch/arm64/include/asm/kvm_mmu.h
...
> +/*
> + * Align KVM with the kernel's view of physical memory. Should be
> + * 40bit IPA, with PGD being 8kB aligned.
> + */
> +#define KVM_PHYS_SHIFT PHYS_MASK_SHIFT
Just wondering - do we allow the IPA to be bigger than what qemu/kvmtool
can map?
> +#define KVM_PHYS_SIZE(1UL << KVM_PHYS_SHIFT)
> +#define KVM_PHYS_MASK(KVM_PHYS_SIZE - 1UL)
> +
> +#ifdef CONFIG_ARM64_64K_PAGES
> +#define PAGE_LEVELS 2
> +#define BITS_PER_LEVEL 13
> +#else /* 4kB pages */
> +#define PAGE_LEVELS 3
> +#define BITS_PER_LEVEL 9
You could use (PAGE_SHIFT - 3) for BITS_PER_LEVEL if that's any clearer
but you can get rid of these entirely (see below).
> +#endif
> +
> +/* Make sure we get the right size, and thus the right alignment */
> +#define BITS_PER_S2_PGD (KVM_PHYS_SHIFT - (PAGE_LEVELS - 1) * BITS_PER_LEVEL
> - PAGE_SHIFT)
> +#define PTRS_PER_S2_PGD (1 << max(BITS_PER_LEVEL, BITS_PER_S2_PGD))
> +#define S2_PGD_ORDER get_order(PTRS_PER_S2_PGD * sizeof(pgd_t))
> +#define S2_PGD_SIZE (1 << S2_PGD_ORDER)
It looks like lots of calculations which I can't fully follow ;). So we
need to map KVM_PHYS_SHIFT (40-bit) with a number of stage 2 pgds. We
know that a pgd entry can map PGDIR_SHIFT bits. So the pointers you need
in S2 pgd:
#define PTRS_PER_S2_PGD (1 << (KVM_PHYS_SHIFT - PGDIR_SHIFT))
(no need of PAGE_LEVELS)
With some more juggling you can probably get rid of get_order as well,
though it should be a compile-time constant. Basically KVM_PHYS_SHIFT -
PGDIR_SHIFT - PAGE_SHIFT + 3 (and cope with the negative value for the
64K pages).
> +static inline void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn)
> +{
> + unsigned long hva = gfn_to_hva(kvm, gfn);
> + flush_icache_range(hva, hva + PAGE_SIZE);
Even ARMv8 can have aliasing VIPT I-cache. Do we need to flush some more
here?
> +#define kvm_flush_dcache_to_poc(a,l) __flush_dcache_area((a), (l))
I had a brief look at the other hyp reworking patches and this function
is used in two situations: (1) flush any data before the Hyp is
initialised and (2) page table creation. The first case looks fine but
the second is not needed on AArch64 (and SMP AArch32) nor entirely
optimal as it should flush to PoU for page table walks. Can we have
different functions, at least we can make one a no-op?
--
Catalin
--
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: linux-next: Tree for Apr 29 (kvm)
On Mon, 2013-04-29 at 18:46 +0200, Paolo Bonzini wrote: > Il 29/04/2013 18:31, Gleb Natapov ha scritto: > >> > arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': > >> > arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use > >> > in this function) > >> > > >> > > >> > Oops, CONFIG_PCI is not enabled. > > Alex, can you look at this please. Before "kvm: Allow build-time > > configuration > > of KVM device assignment" commit KVM depended on PCI to be enabled. > > > > KVM_CAP_IOMMU probably should depend on device assignment. It doesn't > really belong in KVM at all, and is only there for device assignment. Yep, exactly. -- 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: KVM_CAP_IOMMU only available with device assignment
On 04/29/13 09:54, Alex Williamson wrote: > Fix build with CONFIG_PCI unset by linking KVM_CAP_IOMMU to > device assignment config option. It has no purpose otherwise. > > Signed-off-by: Alex Williamson Reported-by: Randy Dunlap Acked-by: Randy Dunlap Thanks. > --- > arch/ia64/kvm/kvm-ia64.c |2 ++ > arch/x86/kvm/x86.c |2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c > index dcc5607..5b2dc0d 100644 > --- a/arch/ia64/kvm/kvm-ia64.c > +++ b/arch/ia64/kvm/kvm-ia64.c > @@ -204,9 +204,11 @@ int kvm_dev_ioctl_check_extension(long ext) > case KVM_CAP_COALESCED_MMIO: > r = KVM_COALESCED_MMIO_PAGE_OFFSET; > break; > +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT > case KVM_CAP_IOMMU: > r = iommu_present(&pci_bus_type); > break; > +#endif > default: > r = 0; > } > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 73e443f..f83a8e0 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -2543,9 +2543,11 @@ int kvm_dev_ioctl_check_extension(long ext) > case KVM_CAP_PV_MMU:/* obsolete */ > r = 0; > break; > +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT > case KVM_CAP_IOMMU: > r = iommu_present(&pci_bus_type); > break; > +#endif > case KVM_CAP_MCE: > r = KVM_MAX_MCE_BANKS; > break; > > -- -- ~Randy -- 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] kvm: KVM_CAP_IOMMU only available with device assignment
Fix build with CONFIG_PCI unset by linking KVM_CAP_IOMMU to device assignment config option. It has no purpose otherwise. Signed-off-by: Alex Williamson --- arch/ia64/kvm/kvm-ia64.c |2 ++ arch/x86/kvm/x86.c |2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c index dcc5607..5b2dc0d 100644 --- a/arch/ia64/kvm/kvm-ia64.c +++ b/arch/ia64/kvm/kvm-ia64.c @@ -204,9 +204,11 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_COALESCED_MMIO: r = KVM_COALESCED_MMIO_PAGE_OFFSET; break; +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT case KVM_CAP_IOMMU: r = iommu_present(&pci_bus_type); break; +#endif default: r = 0; } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 73e443f..f83a8e0 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2543,9 +2543,11 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_PV_MMU:/* obsolete */ r = 0; break; +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT case KVM_CAP_IOMMU: r = iommu_present(&pci_bus_type); break; +#endif case KVM_CAP_MCE: r = KVM_MAX_MCE_BANKS; break; -- 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: linux-next: Tree for Apr 29 (kvm)
On Mon, 2013-04-29 at 19:31 +0300, Gleb Natapov wrote: > On Mon, Apr 29, 2013 at 08:52:56AM -0700, Randy Dunlap wrote: > > On 04/29/13 02:17, Stephen Rothwell wrote: > > > Hi all, > > > > > > Changes since 20130426: > > > > > > > > > on x86_64: > > > > arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': > > arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in > > this function) > > > > > > Oops, CONFIG_PCI is not enabled. > Alex, can you look at this please. Before "kvm: Allow build-time configuration > of KVM device assignment" commit KVM depended on PCI to be enabled. Yep, patch coming... -- 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: linux-next: Tree for Apr 29 (kvm)
Il 29/04/2013 18:31, Gleb Natapov ha scritto: >> > arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': >> > arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in >> > this function) >> > >> > >> > Oops, CONFIG_PCI is not enabled. > Alex, can you look at this please. Before "kvm: Allow build-time configuration > of KVM device assignment" commit KVM depended on PCI to be enabled. > KVM_CAP_IOMMU probably should depend on device assignment. It doesn't really belong in KVM at all, and is only there for device assignment. Paolo -- 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: linux-next: Tree for Apr 29 (kvm)
On Mon, Apr 29, 2013 at 08:52:56AM -0700, Randy Dunlap wrote: > On 04/29/13 02:17, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20130426: > > > > > on x86_64: > > arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': > arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in > this function) > > > Oops, CONFIG_PCI is not enabled. Alex, can you look at this please. Before "kvm: Allow build-time configuration of KVM device assignment" commit KVM depended on PCI to be enabled. > > Full randconfig file is attached. > > > -- > ~Randy > # > # Automatically generated file; DO NOT EDIT. > # Linux/x86_64 3.9.0-rc8 Kernel Configuration > # > CONFIG_64BIT=y > CONFIG_X86_64=y > CONFIG_X86=y > CONFIG_INSTRUCTION_DECODER=y > CONFIG_OUTPUT_FORMAT="elf64-x86-64" > CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_HAVE_LATENCYTOP_SUPPORT=y > CONFIG_MMU=y > CONFIG_NEED_DMA_MAP_STATE=y > CONFIG_NEED_SG_DMA_LENGTH=y > CONFIG_GENERIC_BUG=y > CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_ARCH_HAS_CPU_RELAX=y > CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > CONFIG_ARCH_HAS_CPU_AUTOPROBE=y > CONFIG_HAVE_SETUP_PER_CPU_AREA=y > CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y > CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > CONFIG_ZONE_DMA32=y > CONFIG_AUDIT_ARCH=y > CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y > CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi > -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 > -fcall-saved-r10 -fcall-saved-r11" > CONFIG_ARCH_SUPPORTS_UPROBES=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > CONFIG_IRQ_WORK=y > CONFIG_BUILDTIME_EXTABLE_SORT=y > > # > # General setup > # > CONFIG_BROKEN_ON_SMP=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_CROSS_COMPILE="" > CONFIG_LOCALVERSION="" > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_HAVE_KERNEL_GZIP=y > CONFIG_HAVE_KERNEL_BZIP2=y > CONFIG_HAVE_KERNEL_LZMA=y > CONFIG_HAVE_KERNEL_XZ=y > CONFIG_HAVE_KERNEL_LZO=y > CONFIG_HAVE_KERNEL_LZ4=y > # CONFIG_KERNEL_GZIP is not set > # CONFIG_KERNEL_BZIP2 is not set > # CONFIG_KERNEL_LZMA is not set > CONFIG_KERNEL_XZ=y > # CONFIG_KERNEL_LZO is not set > # CONFIG_KERNEL_LZ4 is not set > CONFIG_DEFAULT_HOSTNAME="(none)" > CONFIG_SYSVIPC=y > # CONFIG_POSIX_MQUEUE is not set > CONFIG_FHANDLE=y > CONFIG_AUDIT=y > # CONFIG_AUDITSYSCALL is not set > # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set > CONFIG_HAVE_GENERIC_HARDIRQS=y > > # > # IRQ subsystem > # > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_GENERIC_IRQ_SHOW=y > CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_DOMAIN_DEBUG=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_SPARSE_IRQ=y > CONFIG_CLOCKSOURCE_WATCHDOG=y > CONFIG_ARCH_CLOCKSOURCE_DATA=y > CONFIG_ALWAYS_USE_PERSISTENT_CLOCK=y > CONFIG_GENERIC_TIME_VSYSCALL=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y > CONFIG_GENERIC_CMOS_UPDATE=y > > # > # Timers subsystem > # > CONFIG_TICK_ONESHOT=y > CONFIG_HZ_PERIODIC=y > # CONFIG_NO_HZ_IDLE is not set > # CONFIG_NO_HZ is not set > CONFIG_HIGH_RES_TIMERS=y > > # > # CPU/Task time and stats accounting > # > CONFIG_TICK_CPU_ACCOUNTING=y > # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set > # CONFIG_IRQ_TIME_ACCOUNTING is not set > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_TASKSTATS=y > CONFIG_TASK_DELAY_ACCT=y > CONFIG_TASK_XACCT=y > CONFIG_TASK_IO_ACCOUNTING=y > > # > # RCU Subsystem > # > CONFIG_TINY_RCU=y > # CONFIG_PREEMPT_RCU is not set > CONFIG_RCU_STALL_COMMON=y > # CONFIG_TREE_RCU_TRACE is not set > # CONFIG_IKCONFIG is not set > CONFIG_LOG_BUF_SHIFT=17 > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y > CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y > CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y > CONFIG_CGROUPS=y > # CONFIG_CGROUP_DEBUG is not set > CONFIG_CGROUP_FREEZER=y > # CONFIG_CGROUP_DEVICE is not set > CONFIG_CPUSETS=y > # CONFIG_PROC_PID_CPUSET is not set > CONFIG_CGROUP_CPUACCT=y > # CONFIG_RESOURCE_COUNTERS is not set > # CONFIG_CGROUP_PERF is not set > CONFIG_CGROUP_SCHED=y > CONFIG_FAIR_GROUP_SCHED=y > CONFIG_CFS_BANDWIDTH=y > # CONFIG_RT_GROUP_SCHED is not set > CONFIG_CHECKPOINT_RESTORE=y > # CONFIG_NAMESPACES is not set > CONFIG_UIDGID_CONVERTED=y > CONFIG_UIDGID_STRICT_TYPE_CHECKS=y > CONFIG_SCHED_AUTOGROUP=y > # CONFIG_SYSFS_DEPRECATED is not set > # CONFIG_RELAY is not set > CONFIG_BLK_DEV_INITRD=y > CONFIG_INITRAMFS_SOURCE="" > CONFIG_RD_GZIP=y > # CONFIG_RD_BZIP2 is not set > CONFIG_RD_LZMA=y > CONFIG_RD_XZ=y > # CONFIG_RD_LZO is not set > CONFIG_RD_LZ4=y > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_ANON_INODES=y > CONFIG_HAVE_UID16=y > CONFIG_SYSCTL_EXCEPTION_TRACE=y > CONFIG_HOTPLUG=y > CONFIG_HAVE_PCSPKR_PLATFO
Re: [PATCH v3 07/32] arm64: KVM: fault injection into a guest
On Mon, Apr 08, 2013 at 05:17:09PM +0100, Marc Zyngier wrote:
> +static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long
> addr)
> +{
> + unsigned long cpsr = *vcpu_cpsr(vcpu);
> + int is_aarch32;
> + u32 esr = 0;
> +
> + is_aarch32 = vcpu_mode_is_32bit(vcpu);
Minor thing - use bool here to match the function definition?
--
Catalin
--
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: linux-next: Tree for Apr 29 (kvm)
On 04/29/13 02:17, Stephen Rothwell wrote: > Hi all, > > Changes since 20130426: > on x86_64: arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in this function) Oops, CONFIG_PCI is not enabled. Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.9.0-rc8 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_FHANDLE=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ALWAYS_USE_PERSISTENT_CLOCK=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y CONFIG_UIDGID_STRICT_TYPE_CHECKS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set CONFIG_RD_LZMA=y CONFIG_RD_XZ=y # CONFIG_RD_LZO is not set CONFIG_RD_LZ4=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HOTPLUG=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_PCSPKR_PLATFORM is not set CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_SHMEM is not set # CONFIG_AIO is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_DEBUG_PERF_USE_VMALLOC=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEB
Re: [PATCH 11/11] nEPT: Provide the correct exit qualification upon EPT
On Mon, Apr 29, 2013 at 8:37 AM, Paolo Bonzini wrote: > Il 26/04/2013 08:43, Jun Nakajima ha scritto: >> diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h >> index e13b6c5..bd370e7 100644 >> --- a/arch/x86/kvm/paging_tmpl.h >> +++ b/arch/x86/kvm/paging_tmpl.h >> @@ -349,7 +349,12 @@ error: >> >> walker->fault.vector = PF_VECTOR; >> walker->fault.error_code_valid = true; >> +#if PTTYPE != PTTYPE_EPT >> walker->fault.error_code = errcode; >> +#else >> + /* Reuse bits [2:0] of EPT violation */ >> + walker->fault.error_code = vcpu->arch.exit_qualification & 0x7; >> +#endif >> walker->fault.address = addr; >> walker->fault.nested_page_fault = mmu != vcpu->arch.walk_mmu; >> > > I'm not sure that this is a step in the right direction. > > errcode is dropped completely, but it would be needed to rebuild bits > 3:5 of the exit qualification. > > Perhaps it is better to access vcpu->arch.exit_qualification in > nested_ept_inject_page_fault, and mix it with the error code from > walker->fault to compute bits 3:5? Yes. We need to generate those bits from the walk of the guest EPT page tables, and combine them. I'll update the patches, fixing the issues in Xinhao's patch. -- Jun Intel Open Source Technology Center -- 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 v2] KVM: x86: Account for failing enable_irq_window for NMI window request
Il 29/04/2013 16:46, Jan Kiszka ha scritto:
> With VMX, enable_irq_window can now return -EBUSY, in which case an
> immediate exit shall be requested before entering the guest. Account for
> this also in enable_nmi_window which uses enable_irq_window in absence
> of vnmi support, e.g.
>
> Signed-off-by: Jan Kiszka
Reviewed-by: Paolo Bonzini
> ---
>
> Changes in v2:
> - check return code of enable_nmi_window against 0 instead of using it
>directly
>
> arch/x86/include/asm/kvm_host.h |2 +-
> arch/x86/kvm/svm.c |5 +++--
> arch/x86/kvm/vmx.c | 16 +++-
> arch/x86/kvm/x86.c |3 ++-
> 4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index ec14b72..3741c65 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -695,7 +695,7 @@ struct kvm_x86_ops {
> int (*nmi_allowed)(struct kvm_vcpu *vcpu);
> bool (*get_nmi_mask)(struct kvm_vcpu *vcpu);
> void (*set_nmi_mask)(struct kvm_vcpu *vcpu, bool masked);
> - void (*enable_nmi_window)(struct kvm_vcpu *vcpu);
> + int (*enable_nmi_window)(struct kvm_vcpu *vcpu);
> int (*enable_irq_window)(struct kvm_vcpu *vcpu);
> void (*update_cr8_intercept)(struct kvm_vcpu *vcpu, int tpr, int irr);
> int (*vm_has_apicv)(struct kvm *kvm);
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 7f896cb..3421d5a 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -3649,13 +3649,13 @@ static int enable_irq_window(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> -static void enable_nmi_window(struct kvm_vcpu *vcpu)
> +static int enable_nmi_window(struct kvm_vcpu *vcpu)
> {
> struct vcpu_svm *svm = to_svm(vcpu);
>
> if ((svm->vcpu.arch.hflags & (HF_NMI_MASK | HF_IRET_MASK))
> == HF_NMI_MASK)
> - return; /* IRET will cause a vm exit */
> + return 0; /* IRET will cause a vm exit */
>
> /*
>* Something prevents NMI from been injected. Single step over possible
> @@ -3664,6 +3664,7 @@ static void enable_nmi_window(struct kvm_vcpu *vcpu)
> svm->nmi_singlestep = true;
> svm->vmcb->save.rflags |= (X86_EFLAGS_TF | X86_EFLAGS_RF);
> update_db_bp_intercept(vcpu);
> + return 0;
> }
>
> static int svm_set_tss_addr(struct kvm *kvm, unsigned int addr)
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 55a1aa0..2f7af9c 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -4417,22 +4417,20 @@ static int enable_irq_window(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> -static void enable_nmi_window(struct kvm_vcpu *vcpu)
> +static int enable_nmi_window(struct kvm_vcpu *vcpu)
> {
> u32 cpu_based_vm_exec_control;
>
> - if (!cpu_has_virtual_nmis()) {
> - enable_irq_window(vcpu);
> - return;
> - }
> + if (!cpu_has_virtual_nmis())
> + return enable_irq_window(vcpu);
> +
> + if (vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & GUEST_INTR_STATE_STI)
> + return enable_irq_window(vcpu);
>
> - if (vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & GUEST_INTR_STATE_STI) {
> - enable_irq_window(vcpu);
> - return;
> - }
> cpu_based_vm_exec_control = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
> cpu_based_vm_exec_control |= CPU_BASED_VIRTUAL_NMI_PENDING;
> vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, cpu_based_vm_exec_control);
> + return 0;
> }
>
> static void vmx_inject_irq(struct kvm_vcpu *vcpu)
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 8747fef..24724b42 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5754,7 +5754,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>
> /* enable NMI/IRQ window open exits if needed */
> if (vcpu->arch.nmi_pending)
> - kvm_x86_ops->enable_nmi_window(vcpu);
> + req_immediate_exit =
> + kvm_x86_ops->enable_nmi_window(vcpu) != 0;
> else if (kvm_cpu_has_injectable_intr(vcpu) || req_int_win)
> req_immediate_exit =
> kvm_x86_ops->enable_irq_window(vcpu) != 0;
>
--
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 11/11] nEPT: Provide the correct exit qualification upon EPT
Il 26/04/2013 08:43, Jun Nakajima ha scritto: > diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h > index e13b6c5..bd370e7 100644 > --- a/arch/x86/kvm/paging_tmpl.h > +++ b/arch/x86/kvm/paging_tmpl.h > @@ -349,7 +349,12 @@ error: > > walker->fault.vector = PF_VECTOR; > walker->fault.error_code_valid = true; > +#if PTTYPE != PTTYPE_EPT > walker->fault.error_code = errcode; > +#else > + /* Reuse bits [2:0] of EPT violation */ > + walker->fault.error_code = vcpu->arch.exit_qualification & 0x7; > +#endif > walker->fault.address = addr; > walker->fault.nested_page_fault = mmu != vcpu->arch.walk_mmu; > I'm not sure that this is a step in the right direction. errcode is dropped completely, but it would be needed to rebuild bits 3:5 of the exit qualification. Perhaps it is better to access vcpu->arch.exit_qualification in nested_ept_inject_page_fault, and mix it with the error code from walker->fault to compute bits 3:5? Paolo -- 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 10/11] nEPT: Miscelleneous cleanups
Il 26/04/2013 08:43, Jun Nakajima ha scritto:
> Some trivial code cleanups not really related to nested EPT.
>
> Signed-off-by: Nadav Har'El
> Signed-off-by: Jun Nakajima
> Signed-off-by: Xinhao Xu
> ---
> arch/x86/kvm/vmx.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index c67eb06..95304cc 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -616,7 +616,6 @@ static void nested_release_page_clean(struct page *page)
> static u64 construct_eptp(unsigned long root_hpa);
> static void kvm_cpu_vmxon(u64 addr);
> static void kvm_cpu_vmxoff(void);
> -static void vmx_set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3);
> static int vmx_set_tss_addr(struct kvm *kvm, unsigned int addr);
> static void vmx_set_segment(struct kvm_vcpu *vcpu,
> struct kvm_segment *var, int seg);
> @@ -912,8 +911,7 @@ static inline bool nested_cpu_has2(struct vmcs12 *vmcs12,
> u32 bit)
> (vmcs12->secondary_vm_exec_control & bit);
> }
>
> -static inline bool nested_cpu_has_virtual_nmis(struct vmcs12 *vmcs12,
> - struct kvm_vcpu *vcpu)
> +static inline bool nested_cpu_has_virtual_nmis(struct vmcs12 *vmcs12)
> {
> return vmcs12->pin_based_vm_exec_control & PIN_BASED_VIRTUAL_NMIS;
> }
> @@ -6321,7 +6319,7 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu)
>
> if (unlikely(!cpu_has_virtual_nmis() && vmx->soft_vnmi_blocked &&
> !(is_guest_mode(vcpu) && nested_cpu_has_virtual_nmis(
> - get_vmcs12(vcpu), vcpu {
> + get_vmcs12(vcpu) {
> if (vmx_interrupt_allowed(vcpu)) {
> vmx->soft_vnmi_blocked = 0;
> } else if (vmx->vnmi_blocked_time > 10LL &&
>
Reviewed-by: Paolo Bonzini
--
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 02/11] nEPT: Add EPT tables support to paging_tmpl.h
Il 26/04/2013 08:43, Jun Nakajima ha scritto:
> This is the first patch in a series which adds nested EPT support to KVM's
> nested VMX. Nested EPT means emulating EPT for an L1 guest so that L1 can use
> EPT when running a nested guest L2. When L1 uses EPT, it allows the L2 guest
> to set its own cr3 and take its own page faults without either of L0 or L1
> getting involved. This often significanlty improves L2's performance over the
> previous two alternatives (shadow page tables over EPT, and shadow page
> tables over shadow page tables).
>
> This patch adds EPT support to paging_tmpl.h.
>
> paging_tmpl.h contains the code for reading and writing page tables. The code
> for 32-bit and 64-bit tables is very similar, but not identical, so
> paging_tmpl.h is #include'd twice in mmu.c, once with PTTTYPE=32 and once
> with PTTYPE=64, and this generates the two sets of similar functions.
>
> There are subtle but important differences between the format of EPT tables
> and that of ordinary x86 64-bit page tables, so for nested EPT we need a
> third set of functions to read the guest EPT table and to write the shadow
> EPT table.
>
> So this patch adds third PTTYPE, PTTYPE_EPT, which creates functions (prefixed
> with "EPT") which correctly read and write EPT tables.
>
> Signed-off-by: Nadav Har'El
> Signed-off-by: Jun Nakajima
> Signed-off-by: Xinhao Xu
> ---
> arch/x86/kvm/mmu.c | 35 ++--
> arch/x86/kvm/paging_tmpl.h | 133
> ++---
> 2 files changed, 130 insertions(+), 38 deletions(-)
I would split this patch so that first prefetch_invalid_gpte and
gpte_access are moved to paging_tmpl.h (adding the FNAME everywhere).
The second patch then can add the EPT special cases.
>
> +static inline int FNAME(check_write_user_access)(struct kvm_vcpu *vcpu,
> +bool write_fault, bool user_fault,
> +unsigned long pte)
> +{
> +#if PTTYPE == PTTYPE_EPT
> + if (unlikely(write_fault && !(pte & VMX_EPT_WRITABLE_MASK)
> + && (user_fault || is_write_protection(vcpu
> + return false;
> + return true;
> +#else
> + u32 access = ((kvm_x86_ops->get_cpl(vcpu) == 3) ? PFERR_USER_MASK : 0)
> +| (write_fault ? PFERR_WRITE_MASK : 0);
>
> + return !permission_fault(vcpu->arch.walk_mmu, vcpu->arch.access,
> access);
> +#endif
> +}
> +
I think check_write_user_access doesn't exist anymore? Perhaps a wrong
conflict resolution.
Paolo
--
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: virtio PCI on KVM without IO BARs
On 02/28/2013 10:24 AM, Michael S. Tsirkin wrote: OK we talked about this a while ago, here's a summary and some proposals: At the moment, virtio PCI uses IO BARs for all accesses. The reason for IO use is the cost of different VM exit types of transactions and their emulation on KVM on x86 (it would be trivial to use memory BARs on non x86 platforms if they don't have PIO). Example benchmark (cycles per transaction): (io access) outw 1737 (memory access) movw 4341 for comparison: (hypercall access): vmcall 1566 (pv memory access) movw_fast 1817 (*explanation what this is below) This creates a problem if we want to make virtio devices proper PCI express devices with native hotplug support. This is because each hotpluggable PCI express device always has a PCI express port (port per device), where each port is represented by a PCI to PCI bridge. In turn, a PCI to PCI bridge claims a 4Kbyte aligned range of IO addresses. This means that we can have at most 15 such devices, this is a nasty limitation. Another problem with PIO is support for physical virtio devices, and nested virt: KVM currently programs all PIO accesses to cause vm exit, so using this device in a VM will be slow. So we really want to stop using IO BARs completely if at all possible, but looking at the table above, switching to memory BAR and movw for notifications will not work well. Possible solutions: 1. hypercall instead of PIO basically add a hypercall that gets an MMIO address/data and does an MMIO write for us. We'll want some capability in the device to let guest know this is what it should do. Pros: even faster than PIO Cons: this won't help nested or assigned devices (won't hurt them either as it will be conditional on the capability above). Cons: need host kernel support, which then has to be maintained forever, even if intel speeds up MMIO exits. 2. pv memory access There are two reasons that memory access is slower: - one is that it's handled as an EPT misconfiguration error so handled by cpu slow path - one is that we need to decode the x86 instruction in software, to calculate address/data for the access. We could agree that guests would use a specific instruction for virtio accesses, and fast-path it specifically. This is the pv memory access option above. Pros: helps assigned devices and nested virt Pros: easy to drop if hardware support is there Cons: a bit slower than IO Cons: need host kernel support 3. hypervisor assigned IO address qemu can reserve IO addresses and assign to virtio devices. 2 bytes per device (for notification and ISR access) will be enough. So we can reserve 4K and this gets us 2000 devices. From KVM perspective, nothing changes. We'll want some capability in the device to let guest know this is what it should do, and pass the io address. One way to reserve the addresses is by using the bridge. Pros: no need for host kernel support Pros: regular PIO so fast Cons: does not help assigned devices, breaks nested virt Simply counting pros/cons, option 3 seems best. It's also the easiest to implement. Comments? apologies for late response... It seems that solution 1 would be the best option for the following reasons: a) (nearly?) every virt technology out there (xen, kvm, vmware, hyperv) has pv drivers in the major OS's using virt (Windows, Linux), so having a hypercall table searched, initialized and used for fast virtio register access is trivially simple to do. b) the support can be added with whatever pvdriver set is provided w/o impacting OS core support. c) it's architecture neutral, or can be made architecture neutral. e.g., inb/outb & PCI ioport support is very different btwn x86 & non-x86. A hypercall interface would not have that dependency/difference. d) it doesn't require new OS support in std/core areas for new standard(s), as another thread proposed; this kind of approach has a long, time delay to get defined & implemented across OS's. In contrast, a hypercall defined interface can be indep. of standards bodies, and if built into a pvdriver core, can change &/or adapt rapidly, and have additional i/f mechanisms for version-levels, which enables cross-hypervisor(version) migration. e) the hypercall can be extended to do pv-specific hot add/remove, eliminating dependencies on emulation support of ACPI-hp or PCIe-hp, and simply(?) track core interfaces for hot-plug of (class) devices. f) For migration, hypercall interfaces could be extended for better/faster migration as well (suspend/resume pv device). my (late) 5 cents (I'll admit it was more than 2 cents)... Don -- To unsubscribe from this list: se
[PATCH v2] KVM: x86: Account for failing enable_irq_window for NMI window request
With VMX, enable_irq_window can now return -EBUSY, in which case an
immediate exit shall be requested before entering the guest. Account for
this also in enable_nmi_window which uses enable_irq_window in absence
of vnmi support, e.g.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- check return code of enable_nmi_window against 0 instead of using it
directly
arch/x86/include/asm/kvm_host.h |2 +-
arch/x86/kvm/svm.c |5 +++--
arch/x86/kvm/vmx.c | 16 +++-
arch/x86/kvm/x86.c |3 ++-
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index ec14b72..3741c65 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -695,7 +695,7 @@ struct kvm_x86_ops {
int (*nmi_allowed)(struct kvm_vcpu *vcpu);
bool (*get_nmi_mask)(struct kvm_vcpu *vcpu);
void (*set_nmi_mask)(struct kvm_vcpu *vcpu, bool masked);
- void (*enable_nmi_window)(struct kvm_vcpu *vcpu);
+ int (*enable_nmi_window)(struct kvm_vcpu *vcpu);
int (*enable_irq_window)(struct kvm_vcpu *vcpu);
void (*update_cr8_intercept)(struct kvm_vcpu *vcpu, int tpr, int irr);
int (*vm_has_apicv)(struct kvm *kvm);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7f896cb..3421d5a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3649,13 +3649,13 @@ static int enable_irq_window(struct kvm_vcpu *vcpu)
return 0;
}
-static void enable_nmi_window(struct kvm_vcpu *vcpu)
+static int enable_nmi_window(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
if ((svm->vcpu.arch.hflags & (HF_NMI_MASK | HF_IRET_MASK))
== HF_NMI_MASK)
- return; /* IRET will cause a vm exit */
+ return 0; /* IRET will cause a vm exit */
/*
* Something prevents NMI from been injected. Single step over possible
@@ -3664,6 +3664,7 @@ static void enable_nmi_window(struct kvm_vcpu *vcpu)
svm->nmi_singlestep = true;
svm->vmcb->save.rflags |= (X86_EFLAGS_TF | X86_EFLAGS_RF);
update_db_bp_intercept(vcpu);
+ return 0;
}
static int svm_set_tss_addr(struct kvm *kvm, unsigned int addr)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 55a1aa0..2f7af9c 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4417,22 +4417,20 @@ static int enable_irq_window(struct kvm_vcpu *vcpu)
return 0;
}
-static void enable_nmi_window(struct kvm_vcpu *vcpu)
+static int enable_nmi_window(struct kvm_vcpu *vcpu)
{
u32 cpu_based_vm_exec_control;
- if (!cpu_has_virtual_nmis()) {
- enable_irq_window(vcpu);
- return;
- }
+ if (!cpu_has_virtual_nmis())
+ return enable_irq_window(vcpu);
+
+ if (vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & GUEST_INTR_STATE_STI)
+ return enable_irq_window(vcpu);
- if (vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & GUEST_INTR_STATE_STI) {
- enable_irq_window(vcpu);
- return;
- }
cpu_based_vm_exec_control = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
cpu_based_vm_exec_control |= CPU_BASED_VIRTUAL_NMI_PENDING;
vmcs_write32(CPU_BASED_VM_EXEC_CONTROL, cpu_based_vm_exec_control);
+ return 0;
}
static void vmx_inject_irq(struct kvm_vcpu *vcpu)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8747fef..24724b42 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5754,7 +5754,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
/* enable NMI/IRQ window open exits if needed */
if (vcpu->arch.nmi_pending)
- kvm_x86_ops->enable_nmi_window(vcpu);
+ req_immediate_exit =
+ kvm_x86_ops->enable_nmi_window(vcpu) != 0;
else if (kvm_cpu_has_injectable_intr(vcpu) || req_int_win)
req_immediate_exit =
kvm_x86_ops->enable_irq_window(vcpu) != 0;
--
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: x86: Account for failing enable_irq_window for NMI window request
Il 28/04/2013 18:40, Jan Kiszka ha scritto: > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 8747fef..6974ca8 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -5754,7 +5754,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > > /* enable NMI/IRQ window open exits if needed */ > if (vcpu->arch.nmi_pending) > - kvm_x86_ops->enable_nmi_window(vcpu); > + req_immediate_exit = > + kvm_x86_ops->enable_nmi_window(vcpu); != 0 for consistency with below? Paolo > else if (kvm_cpu_has_injectable_intr(vcpu) || req_int_win) > req_immediate_exit = > kvm_x86_ops->enable_irq_window(vcpu) != 0; > -- 1.7.3.4 -- 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
KVM call agenda for 2013-04-30
Hi Please send in any agenda topics you are interested in. Later, Juan. -- 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
./configure options when building KVM-Qemu
Sorry to be a nuisance, but this should be an easy one. Looking at the man page for ./configure, in 1.2 I need to set --cpu=CPU to enable host cpu's in the command line, am I right? This appears to have been a default in 1.0, and even with an ancient 2.6.38 kernel we can use -cpu host on a core i5 and get an accurate cpu return type in a windows guest. With default 1.2 we get BSOD when using any specific type or host type. I really hope this is only a configuration tweak. Regards, Simon -- 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
