Re: [kvm-devel] [PATCH] raise tsc clocksource rating
* Ian Pratt [EMAIL PROTECTED] wrote: Sigh, I don't really want to have this fight again. i dont remember us having discussed this before, ever. If there's any fight about monotonicity and SMP then it would be a pretty onesided affair, with you being beaten up seriously ;-) Actually, it is possible, even for NUMA systems with CPUs running off completely different oscillators, and in the presence of CPU frequency changes, power management, and even in the presence of thermal throttling (though the latter introduces temporary inaccuracies it doesn't affect monotonicity or rate). Take a look at the Xen code to see how each physical CPU is independently calibrated on an ongoing basis, how movement of VCPUs between physical CPUs is tracked, and how shared variables are used to ensure montonicity if a guest requires it. I think that's wishful thinking. Check out: http://people.redhat.com/mingo/time-warp-test/time-warp-test.c change TEST_TSC to 0, run it on an SMP guest (on a reasonably fast machine) and let me know whether you can make SMP guests not come up with monotonicity violations in the CLOCK tests. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] raise tsc clocksource rating
* Dan Hecht [EMAIL PROTECTED] wrote: but if there's a perfect TSC available (there is such hardware) then the TSC _is_ the best clocksource. Paravirt now turns it off unconditionally in essence. Not really. In the case hardware TSC is perfect, the paravirt time counter can be implemented directly in terms of hardware TSC; there is no loss in optimization. This is done transparently. And virtual TSC can be implemented this way too. Of course if you duplicate all (or part) of the TSC clocksource driver in the paravirt guest code then the paravirt clocksource is at least as good as the TSC. But that argument is playing word-games, _of course_ if you use the same (or similar) code it's at least as good. The real question are clocksources that communicate out to the hypervisor, and hence have higher overhead than a native, TSC based clocksource - and clocksources that use the TSC in a broken way. The real improvement that a paravirt clocksource offers over the TSC clocksource is that the guest does not need to measure the TSC frequency itself against some other constant frequency source (which is problematic on a virtual machine). [...] hey, you need not tell me, i've implemented a hyper-clocksource driver myself. But calibration is a boot only issue and there's no reason why calibration _has_ to be fragile. For example we could easily extend the TSC clocksource driver to not calibrate in the guest but take calibration information from the host. It's in essence a trivial and obvious extension to calibration. That way we get the highest possible performance _and_ we share much of the clocksource driver with the host. also, the way the TSC is used by guests like Xen is fundamentally fragile on SMP. So i have a good reason to distrust the approach of hypervisors to timekeeping. The maintenance problem to me is that everyone in the paravirt space is busy coding away in their own (often broken) direction, replicating the essence of the TSC clocksource driver 4 times over again and again, with subtle bugs in each variant, even in cases where the TSC readout can be trusted perfectly well. Consolidation and sharing code is not a particularly strong point of the paravirt projects ;-) (ok, KVM is a notable exception there.) anyway, i do agree that this patch is wrong currently, mainly due to TSC calibration not being reliable in guest-space at the moment - but the whole concept of putting a separate clocksource driver into each paravirt guest, even in the case where the TSC is perfect, is madness. That code, once the hardware gets sane (and there are good signs for that), and once calibration can be passed from host to guest reliably, _will_ be consolidated, because it makes perfect technical sense. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] raise tsc clocksource rating
* Rusty Russell [EMAIL PROTECTED] wrote: No. tsc is very good, it's not perfect. If a paravirt clock registers 400 it really means pick me over the tsc. often the TSC is not perfect, but _IF_ it's perfect, using the paravirt driver is a pessimisation in performance. the main problem at the moment is that there's no mechanism at the moment to convey to the guest the information that the TSC is perfect, and to convey the calibration values. That's *why* they use 400: it's in the documentation. static values do not capture conditional quality like that of the TSC. and just in case it's not obvious: i am not arguing for the inclusion of the patch, i'm just pointing out the plain fact that in the case where the TSC _is_ reliable, 5 different clocksource drivers for has obvious disadvantages. Anyone arguing against that simple point needs his head examined :) Once we can pass around calibration information from the host to the guest (which we dont do at the moment) there will be reason not to use the native clocksource driver in the guest. in the long run, the paravirt clocksource drivers must become _fallback_ drivers, for the case when the TSC is not perfect. Instead of the current lets try to make it reliable but also nearly as fast as the TSC, which leads to inevitable breakage on SMP. Ingo - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
Avi Kivity wrote: David Brown wrote: I thought I'd try out the realtime patch set and it didn't work at all with kvm. The console didn't dump anything and the system completely locked up. Up to now, the unmodified kvm module never worked with any RT kernel. This would only change, if RT patched kernels were routinely used in the kvm release tests which is, for the time being, not the case. However, tglx once provided a hand-crafted kvm version that can be used together with a selected RT kernel - see Latest Stable (http://www.osadl.org/Latest-Stable.latest-stable-realtime-kernel.0.html) realtime kernel. It is based on kernel 2.6.21.6-rt21 and kvm-28. We used these modules to carry out a number of proof of concept tests which were very successful. The realtime capabilities of the host system remained unchanged irrespective of whether the kvm guest system (no graphics) was running or not. This was even the case while the guest system was booting. We are planning to provide another Latest Stable realtime kernel within the next month or so. It will probably be based on kernel 2.6.23. --cbe - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Question about KVM-test
It seems nice ! But is there any documentation ? I don't know how-to start it. -Alexey - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [Patch] adding some scripts at installing
Hi, I wanted to use network with --mac optin of kvm script on guest, but I didn't use it because I didn't know needing to copy some scripts. I think it is better that we can use --mac option after make install. So I modified install section in the Makefile. Signed-off-by: Akio Takebe [EMAIL PROTECTED] --- --- kvm-49/Makefile 2007-10-29 02:14:57.0 +0900 +++ kvm-49.new/Makefile 2007-10-30 18:14:42.0 +0900 @@ -43,6 +43,10 @@ install: $(kcmd)make -C kernel DESTDIR=$(DESTDIR) install make -C user DESTDIR=$(DESTDIR) install make -C qemu DESTDIR=$(DESTDIR) install + install -d $(DESTDIR)/$(confdir) + cp scripts/kvm $(DESTDIR)/$(initdir)/kvm + cp scripts/qemu-ifup $(DESTDIR)/$(confdir)/qemu-ifup + install -t $(DESTDIR)/etc/udev/rules.d scripts/*kvm*.rules tmpspec = .tmp.kvm.spec RPMDIR=$$(pwd)/RPMS Best Regards, Akio Takebe - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] adding some scripts at installing
-Original Message- From: [EMAIL PROTECTED] on behalf of Akio Takebe Sent: Tue 10/30/2007 2:29 AM To: kvm-devel@lists.sourceforge.net Subject: [kvm-devel] [Patch] adding some scripts at installing Hi, I wanted to use network with --mac optin of kvm script on guest, but I didn't use it because I didn't know needing to copy some scripts. I think it is better that we can use --mac option after make install. So I modified install section in the Makefile. Signed-off-by: Akio Takebe [EMAIL PROTECTED] = Yes, that would be better. However, I found that when using multiple virtual bridges (via brctl), you need to have several script files. In the future, I hope that bridging functionality could be integrated into Qemu/KVM, so that we won't need that script at all. -Alexey - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
Carsten Emde wrote: Avi Kivity wrote: David Brown wrote: I thought I'd try out the realtime patch set and it didn't work at all with kvm. The console didn't dump anything and the system completely locked up. Up to now, the unmodified kvm module never worked with any RT kernel. This would only change, if RT patched kernels were routinely used in the kvm release tests which is, for the time being, not the case. As far as I understood (but didn't re-test yet), latest kvm release does include all features required to run over -rt. This was at least the case for kvm-git I picked up last week and merged into 2.6.23-rt1. The only issue is that out-of-tree kvm doesn't enable the preemption notifiers (maybe there were one or two further minor issues, I think to recall missing smp_ops exports being one, but these were not -rt related). However, tglx once provided a hand-crafted kvm version that can be used together with a selected RT kernel - see Latest Stable (http://www.osadl.org/Latest-Stable.latest-stable-realtime-kernel.0.html) realtime kernel. It is based on kernel 2.6.21.6-rt21 and kvm-28. We used these modules to carry out a number of proof of concept tests which were very successful. The realtime capabilities of the host system remained unchanged irrespective of whether the kvm guest system (no graphics) was running or not. This was even the case while the guest system was booting. Interesting result - you've read about the wbinvd issues? Is there no wbinvd in the bios shipped with older kvm? Which VM extension did you test, both Intel and AMD? I would bet that your X issues are due to the same effect. X startup/shutdown involves a lot of wbinvd calls on my test boxes. To sum up my findings: kvm over whatever RT kernel is risky (latency-wise) unless you can audit or even para-virtualise your guest OS /wrt wbinvd. Maybe we can discuss this also in Linz by the end of the week. :) Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
On Oct 30, 2007, at 10:49 AM, Jan Kiszka wrote: Carsten Emde wrote: Avi Kivity wrote: David Brown wrote: I thought I'd try out the realtime patch set and it didn't work at all with kvm. The console didn't dump anything and the system completely locked up. Up to now, the unmodified kvm module never worked with any RT kernel. This would only change, if RT patched kernels were routinely used in the kvm release tests which is, for the time being, not the case. As far as I understood (but didn't re-test yet), latest kvm release does include all features required to run over -rt. This was at least the case for kvm-git I picked up last week and merged into 2.6.23-rt1. The only issue is that out-of-tree kvm doesn't enable the preemption notifiers (maybe there were one or two further minor issues, I think to recall missing smp_ops exports being one, but these were not -rt related). However, tglx once provided a hand-crafted kvm version that can be used together with a selected RT kernel - see Latest Stable (http://www.osadl.org/Latest-Stable.latest-stable-realtime-kernel. 0.html) realtime kernel. It is based on kernel 2.6.21.6-rt21 and kvm-28. We used these modules to carry out a number of proof of concept tests which were very successful. The realtime capabilities of the host system remained unchanged irrespective of whether the kvm guest system (no graphics) was running or not. This was even the case while the guest system was booting. Interesting result - you've read about the wbinvd issues? Is there no wbinvd in the bios shipped with older kvm? Which VM extension did you test, both Intel and AMD? I would bet that your X issues are due to the same effect. X startup/shutdown involves a lot of wbinvd calls on my test boxes. To sum up my findings: kvm over whatever RT kernel is risky (latency-wise) unless you can audit or even para-virtualise your guest OS /wrt wbinvd. Maybe we can discuss this also in Linz by the end of the week. :) As I will be in Linz by the end of the week as well, could you please try to do any coordination as to when you meet on the lists (or CC me)? I'd like to get the chance to join you on this :-). Thanks, Alex - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [Patch][RFC] fix make rpm
Hi,
This patch fix make rpm.
When I used the rpm option, I got some error.
So I fixed it, but it is a just sample?
What do you think about it?
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
---
--- kvm-49/Makefile 2007-10-29 02:14:57.0 +0900
+++ kvm-49.mod/Makefile 2007-10-30 17:29:35.0 +0900
@@ -1,9 +1,17 @@
-
include config.mak
DESTDIR=
+PWD:= `pwd`
+tmpspec = .tmp.kvm.spec
+BUILD_ROOT=${PWD}
+RPMDIR=${BUILD_ROOT}/RPMS
+SOURCES=${BUILD_ROOT}/SOURCES
+BUILD=${BUILD_ROOT}/BUILD
+SRPMS=${BUILD_ROOT}/SRPMS
+SPECS=${BUILD_ROOT}/SPECS
-rpmrelease = devel
+VERSION:=$(shell grep 'MODULE_INFO' ./kernel/kvm_main.c| cut -f 2 -d\ |cut -f
2 -d\- )
+RELEASE:=${VERSION}-devel
.PHONY: kernel user qemu bios clean
@@ -38,31 +46,32 @@ install-rpm:
cp scripts/kvm $(DESTDIR)/$(initdir)/kvm
cp scripts/qemu-ifup $(DESTDIR)/$(confdir)/qemu-ifup
install -t $(DESTDIR)/etc/udev/rules.d scripts/*kvm*.rules
+ $(kcmd)make -C kernel DESTDIR=$(DESTDIR)/ install
install:
$(kcmd)make -C kernel DESTDIR=$(DESTDIR) install
make -C user DESTDIR=$(DESTDIR) install
make -C qemu DESTDIR=$(DESTDIR) install
-tmpspec = .tmp.kvm.spec
-RPMDIR=$$(pwd)/RPMS
rpm: srpm
- mkdir -p BUILD $(RPMDIR)/$$(uname -i)
+ mkdir -p $(BUILD) $(RPMDIR)/$$(uname -i)
rpmbuild --rebuild \
--define=_rpmdir $(RPMDIR) \
---define=_topdir $$(pwd) \
- SRPMS/kvm-0.0-$(rpmrelease).src.rpm
+--define=_topdir ${PWD} \
+ SRPMS/kvm-$(RELEASE).src.rpm
srpm:
- mkdir -p SOURCES SRPMS
- sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec $(tmpspec)
- tar czf SOURCES/kvm.tar.gz qemu
- tar czf SOURCES/user.tar.gz user
- tar czf SOURCES/kernel.tar.gz kernel
- tar czf SOURCES/scripts.tar.gz scripts
- cp Makefile configure kvm_stat SOURCES
- rpmbuild --define=_topdir $$(pwd) -bs $(tmpspec)
+ export WANT_MODULE=y
+ mkdir -p $(SOURCES)
+ mkdir -p $(SRPMS)
+ mkdir -p $(SPECS)
+ mkdir -p ${BUILD_ROOT}/kvm-$(VERSION)
+ cp kvm.spec $(SPECS)/$(tmpspec)
+ cp -ax qemu user kernel scripts Makefile configure kvm_stat
${BUILD_ROOT}/kvm-$(VERSION)
+ cd ${BUILD_ROOT}
+ tar czf $(SOURCES)/kvm-$(RELEASE).tar.gz ./kvm-$(VERSION)
+ rpmbuild -vv -bs $(SPECS)/$(tmpspec)
$(RM) $(tmpspec)
clean:
--- kvm-49/kvm.spec 2007-10-29 02:14:57.0 +0900
+++ kvm-49.mod/kvm.spec 2007-10-30 17:39:54.0 +0900
@@ -1,106 +1,115 @@
Name: kvm
-Version:0.0
-Release:0
-Summary:Kernel Virtual Machine virtualization environment
+%define bindir /usr/bin
+%define bin %{bindir}/kvm
+%define initdir /etc/init.d
+%define confdir /etc/kvm
+%define utilsdir /etc/kvm/utils
+%define uname %(uname -r)
+
+Version:49
+Release:devel
+Summary:Kernel Virtual Machine virtualization environment
Group: System Environment/Kernel
License:GPL
URL:http://www.qumranet.com
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}
-
ExclusiveArch: i386 x86_64
-
-Requires: kvm-kmod bridge-utils
-
-%define Distribution %(cat /etc/redhat-release | awk '{ print $1}' | tr [A-Z]
[a-z])
-%define os_release %(rpm -q --qf '%%{version}' %{Distribution}-release)
-
-%if %{Distribution} == fedora %{os_release} == 5 || %{Distribution} ==
centos %{os_release} == 4
-BuildRequires: compat-gcc-32
-%else
-BuildRequires: compat-gcc-34
-%endif
-
+Requires: bridge-utils
BuildRequires: SDL-devel zlib-devel alsa-lib-devel
-
-%define _prebuilt %{?prebuilt:1}%{!?prebuilt:0}
-
-%if !%{_prebuilt}
-Source0: kvm.tar.gz
-Source1: user.tar.gz
-Source2: kernel.tar.gz
-Source3: scripts.tar.gz
-Source4: Makefile
-Source5: configure
-Source5: kvm_stat
-%endif
+Source0:%{name}-%{version}-%{release}.tar.gz
%description
The Kernel Virtual Machine provides a virtualization enviroment for processors
with hardware support for virtualization: Intel's VT and AMD's AMD-V.
%prep
-
-%if !%{_prebuilt}
-%setup -T -b 0 -n qemu
-%setup -T -b 1 -n user -D
-%setup -T -b 2 -n kernel -D
-%setup -T -b 3 -n scripts -D
-cd ..
-cp %{_sourcedir}/Makefile %{_sourcedir}/configure %{_sourcedir}/kvm_stat .
-%endif
+%setup
%build
-
rm -rf %{buildroot}
-
-%if !%{_prebuilt}
-cd ..
./configure --prefix=/usr/kvm
-make -C user
-#(cd qemu;
-#./co
-# kpath=$(readlink -f ../kernel/include)
-# upath=$(readlink -f ../user)
-# ./configure --target-list=$(uname -i)-softmmu \
-# --extra-cflags=-I$kpath -I$upath \
-# --extra-ldflags=-L$upath \
-# --disable-kqemu --enable-kvm --prefix=/usr/kvm
-#)
-make -C qemu
-%endif
+make
%install
-
-%if !%{_prebuilt}
-cd ..
-%else
-cd %{objdir}
-%endif
-
make DESTDIR=%{buildroot} install-rpm
-%define bindir /usr/bin
-%define bin %{bindir}/kvm
-%define initdir /etc/init.d
-%define confdir
Re: [kvm-devel] [Patch] adding some scripts at installing
Hi, Alexey Yes, that would be better. However, I found that when using multiple virtual bridges (via brctl), you need to have several script files. Thank you for your comment. Are there any other necessary files not including in my patch? I may forgot some files because my machine is installed Xen. If you found some of them, can you tell me them? In the future, I hope that bridging functionality could be integrated into Qemu/KVM, so that we won't need that script at all. It's nice. Best Regards, Akio Takebe - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] raise tsc clocksource rating
On Tuesday 30 October 2007 18:37:36 Ingo Molnar wrote: * Rusty Russell [EMAIL PROTECTED] wrote: No. tsc is very good, it's not perfect. If a paravirt clock registers 400 it really means pick me over the tsc. often the TSC is not perfect, but _IF_ it's perfect, using the paravirt driver is a pessimisation in performance. the main problem at the moment is that there's no mechanism at the moment to convey to the guest the information that the TSC is perfect, and to convey the calibration values. The host can communicate to the guest what clock to use: the guest can decide to register a paravirt clock or not depending on whether it wants to leave it to the TSC. For a while we couldn't remove the TSC cpuid capability in the guest, because if you configured your kernel in some ways it was hardcoded on. I think the all 686+ have a tsc assumption has now been fixed, so I should change the lguest clock to do as you said: register its clock at lower prio to the TSC and then the host can simply remove the TSC cpuid if it isn't suitable for the guest to use. ISTR the core TSC timing code (which lguest could use) and various hardware manipulations (which lguest couldn't) were intertwined, but I'll have to go back and check exactly what the issue was. and just in case it's not obvious: i am not arguing for the inclusion of the patch Unfortunately, you and Thomas both acked the patch. This says v bad things about how much review kernel patches get. Cheers, Rusty. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carsten Otte Sent: 2007年10月26日 20:02 To: Avi Kivity; Zhang, Xiantao; Hollis Blanchard Cc: kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3 This patch splits kvm_vm_ioctl into archtecture independent parts, and x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. The patch has been updated to current git, and it leaves out memory slot registration work which is currently subject to a detailed discussion. Common ioctls for all architectures are: KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION KVM_SET_USER_MEMORY_REGION implementation is no longer moved to x86.c. It seems to me that more fine-grained refinement then just moving the code is required here. x86 specific ioctls are: KVM_SET_MEMORY_REGION, KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP, KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP KVM_SET_TSS_ADDR KVM_SET_TSS_ADDR has been added to the list of x86 specifics, as Izik's commit states it is used for emulating real mode on intel. Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec which I assume to be generic though S390 may not take. thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carsten Otte Sent: 2007年10月26日 20:02 To: Avi Kivity; Zhang, Xiantao; Hollis Blanchard Cc: kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3 This patch splits kvm_vm_ioctl into archtecture independent parts, and x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. The patch has been updated to current git, and it leaves out memory slot registration work which is currently subject to a detailed discussion. Common ioctls for all architectures are: KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION KVM_SET_USER_MEMORY_REGION implementation is no longer moved to x86.c. It seems to me that more fine-grained refinement then just moving the code is required here. x86 specific ioctls are: KVM_SET_MEMORY_REGION, KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP, KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP KVM_SET_TSS_ADDR KVM_SET_TSS_ADDR has been added to the list of x86 specifics, as Izik's commit states it is used for emulating real mode on intel. Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec which I assume to be generic though S390 may not take. ia64 can probably share much. ppc will probably want KVM_IRQ_LINE with with different parameters. s390, as far as I understand, will not. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
Jan Kiszka wrote: Interesting result - you've read about the wbinvd issues? Is there no wbinvd in the bios shipped with older kvm? Which VM extension did you test, both Intel and AMD? I would bet that your X issues are due to the same effect. X startup/shutdown involves a lot of wbinvd calls on my test boxes. kvm.git now traps invd and wbinvd on amd, so there shouldn't be any issues there. I hope that Intel will add similar traps in future iterations of VT. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] [RESEND] Move libkvm (v2)
Hollis Blanchard wrote: Move libkvm into its own directory. No functional changes. Applied, thanks. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch] adding some scripts at installing
Akio Takebe wrote: Hi, Hi, I wanted to use network with --mac optin of kvm script on guest, but I didn't use it because I didn't know needing to copy some scripts. I think it is better that we can use --mac option after make install. So I modified install section in the Makefile. Signed-off-by: Akio Takebe [EMAIL PROTECTED] --- --- kvm-49/Makefile 2007-10-29 02:14:57.0 +0900 +++ kvm-49.new/Makefile 2007-10-30 18:14:42.0 +0900 @@ -43,6 +43,10 @@ install: $(kcmd)make -C kernel DESTDIR=$(DESTDIR) install make -C user DESTDIR=$(DESTDIR) install make -C qemu DESTDIR=$(DESTDIR) install + install -d $(DESTDIR)/$(confdir) + cp scripts/kvm $(DESTDIR)/$(initdir)/kvm + cp scripts/qemu-ifup $(DESTDIR)/$(confdir)/qemu-ifup + install -t $(DESTDIR)/etc/udev/rules.d scripts/*kvm*.rules The kvm initscript is only suitable for Fedora systems, no? I don't think it will run correctly on other distributions. Installing the udev rule is a good idea, but is udev backwards compatible enough so that older distributions don't choke when they see the new rule? Installing qemu-ifup is fine. [personally I don't use the initscript, so it's probably outdated and a little broken. I prefer to use Fedora's networking support for bridges instead of the initscript] -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote: Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec which I assume to be generic though S390 may not take. ACPI is not present on s390 and ppc. In fact, I doubt it is present on any architecture except those two intel ones: at least my mips router and my arm pda don't have it either. It's kind of based on the idea of having a bios alike code. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
Avi Kivity wrote: Jan Kiszka wrote: Interesting result - you've read about the wbinvd issues? Is there no wbinvd in the bios shipped with older kvm? Which VM extension did you test, both Intel and AMD? I would bet that your X issues are due to the same effect. X startup/shutdown involves a lot of wbinvd calls on my test boxes. kvm.git now traps invd and wbinvd on amd, so there shouldn't be any issues there. So kvm can then simply ignore the instructions, or what does it do about them? I recall some replies in the related thread that some more work may be required. I hope that Intel will add similar traps in future iterations of VT. Yep. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
OK, so how can a device inform kernel for an IRQ in S390? -Original Message- From: Carsten Otte [mailto:[EMAIL PROTECTED] Sent: 2007年10月30日 19:30 To: Dong, Eddie Cc: Avi Kivity; Zhang, Xiantao; Hollis Blanchard; kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3 Dong, Eddie wrote: Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec which I assume to be generic though S390 may not take. ACPI is not present on s390 and ppc. In fact, I doubt it is present on any architecture except those two intel ones: at least my mips router and my arm pda don't have it either. It's kind of based on the idea of having a bios alike code. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
Jan Kiszka wrote: Avi Kivity wrote: Jan Kiszka wrote: Interesting result - you've read about the wbinvd issues? Is there no wbinvd in the bios shipped with older kvm? Which VM extension did you test, both Intel and AMD? I would bet that your X issues are due to the same effect. X startup/shutdown involves a lot of wbinvd calls on my test boxes. kvm.git now traps invd and wbinvd on amd, so there shouldn't be any issues there. So kvm can then simply ignore the instructions, or what does it do about them? I recall some replies in the related thread that some more work may be required. It currently ignores the instructions. When device passthrough is implemented more work will be needed. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: VMX: Enable memory mappedTPR shadow(FlexPriority)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Izik Eidus Sent: 2007年10月29日 19:36 To: Yang, Sheng Cc: kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] [PATCH] KVM: VMX: Enable memory mappedTPR shadow(FlexPriority) On Mon, 2007-10-29 at 12:55 +0800, Yang, Sheng wrote: From 34ee5ae67ff5d3f4b8a0b9313dd80980f57705eb Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Mon, 29 Oct 2007 09:40:42 +0800 Subject: [PATCH] KVM: VMX: Enable memory mapped TPR shadow(FlexPriority) This patch based on CR8/TPR patch, and enable the TPR shadow(FlexPriority) for 32bit Windows. Since TPR is accessed very frequently by 32bit Windows, especially SMP guest, with FlexPriority enabled, we saw significant performance gain. patch look much better, and everything seems to be fine as i look at it. lets wait avi to review it Ack too :-) Basically this patch will have same functionality/result with what Avi did for optimizing Windows. Dynamic patch works on all HWs, but may crash the guest if guest kernel has integrity check or patch guard. This one avoid this issue, but require new HWs :-) I assume all comming processor will have this feature, some existing processor also has this feature, so now we can have whole bunch of solution: new HW will use HW features + any modern OSes; old HWs will use dynamic patching with assumption no patch guard in guest which is true so far. thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Avi Kivity wrote: Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec which I assume to be generic though S390 may not take. ia64 can probably share much. ppc will probably want KVM_IRQ_LINE with with different parameters. s390, as far as I understand, will not. I think we'll have to come up with a more modular approach later on: various aspects are of interest to various architectures and/or platforms. The generic kernel has CONFIG_FEATURE toggles for that. The portability patches are not intended to split kvm into components at this stage, I believe that is something that we will have to come up when actual ports are being integrated. In my optinion, a reasonable next-step refinement here would be to come up with a generic interrupt injection call that can inject an interrupt on any architecture and platform. After userspace has adopted to use that one, we can keep the old call for backward compatibility reasons in a deprecated state for some time before removing it. For now, my goal is to seperate what is generic in a way that it is a functionality that a portable user space program that uses kvm can expect to work the same way on all architectures and platforms. so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: VMX: Enable memory mappedTPR shadow(FlexPriority)
Dong, Eddie wrote: From: Sheng Yang [EMAIL PROTECTED] Date: Mon, 29 Oct 2007 09:40:42 +0800 Subject: [PATCH] KVM: VMX: Enable memory mapped TPR shadow(FlexPriority) This patch based on CR8/TPR patch, and enable the TPR shadow(FlexPriority) for 32bit Windows. Since TPR is accessed very frequently by 32bit Windows, especially SMP guest, with FlexPriority enabled, we saw significant performance gain. patch look much better, and everything seems to be fine as i look at it. lets wait avi to review it Ack too :-) Basically this patch will have same functionality/result with what Avi did for optimizing Windows. Dynamic patch works on all HWs, but may crash the guest if guest kernel has integrity check or patch guard. This one avoid this issue, but require new HWs :-) I assume all comming processor will have this feature, some existing processor also has this feature, so now we can have whole bunch of solution: new HW will use HW features + any modern OSes; old HWs will use dynamic patching with assumption no patch guard in guest which is true so far. Yes. FlexPriority will be both faster and safer for those who have it than my hack. It may turn out that patching can improve performance even with FlexPriority: we can patch the APIC EOI write to look if any interrupts are pending, and only exit if the EOI will result in a new interrupt being injected. But it is very possible that this will not be necessary if we can achieve good interrupt mitigation with virtio. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Carsten Otte wrote: I think we'll have to come up with a more modular approach later on: various aspects are of interest to various architectures and/or platforms. The generic kernel has CONFIG_FEATURE toggles for that. The portability patches are not intended to split kvm into components at this stage, I believe that is something that we will have to come up when actual ports are being integrated. In my optinion, a reasonable next-step refinement here would be to come up with a generic interrupt injection call that can inject an interrupt on any architecture and platform. After userspace has adopted to use that one, we can keep the old call for backward compatibility reasons in a deprecated state for some time before removing it. For now, my goal is to seperate what is generic in a way that it is a functionality that a portable user space program that uses kvm can expect to work the same way on all architectures and platforms. We have to be careful not to force too much portability on the code. After all, the instruction set is different and some of the hardware philosophy is different. You will never be able to run the same guest on different archs, or have exactly the same virtual devices. The differences are real, and the goal is not portability at any cost; it is to share as much as possible, but not more. Architectures which have interrupt request lines that are edge-triggered or level-triggered and emulate the interrupt controller in the kernel can share the KVM_IRQ_LINE API in some way; architectures that don't will need another method. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] raise tsc clocksource rating
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zachary Amsden escreveu: On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote: * Zachary Amsden [EMAIL PROTECTED] wrote: if it's inaccurate why are you exposing it to the guest then? Native only uses the TSC if it's safe and accurate to do so. Not every guest support paravirt, but for correctness, all guests require TSC, which must be exposed all the way up to userspace, no matter what the efficiency or accuracy may be. Zach However, with such accuracy, it will fail the tsc clocksources tests. If it passes, it'a good clocksource to use. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iD8DBQFHJxyujYI8LaFUWXMRAhI5AKCDl/O7iA3TdtpvElVg8NoSDVfKpgCeNvz3 ZEZDMxg8T7FA2R+5cgH/uKI= =8qSH -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] raise tsc clocksource rating
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ingo Molnar escreveu: * Rusty Russell [EMAIL PROTECTED] wrote: and just in case it's not obvious: i am not arguing for the inclusion of the patch, i'm just pointing out the plain fact that in the case where the TSC _is_ reliable, 5 different clocksource drivers for has obvious disadvantages. Anyone arguing against that simple point needs his head examined :) Once we can pass around calibration information from the host to the guest (which we dont do at the moment) there will be reason not to use the native clocksource driver in the guest. If you sustain that we cannot have a reliable synchronization test mechanism, neither do I. All this is based in the assumption that a bad tsc will fail such tests. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iD8DBQFHJyAHjYI8LaFUWXMRAtYoAJ9l5kNodRLfTsNHDvyioufM7SQzTACfarEy XXq3sDq9uxZ/72hhA46YmgM= =DwN/ -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch][RFC] fix make rpm
Hi, Avi
Thank you for your comments.
This patch fix make rpm.
When I used the rpm option, I got some error.
So I fixed it, but it is a just sample?
'make rpm' works for me on F7 (after I fixed fallout from the libkvm
separation patch). What distribution did you run it on? What error did
you get?
I used RHEL5. I got the following error at fist.
[EMAIL PROTECTED] kvm-49]# make rpm
mkdir -p SOURCES SRPMS
mkdir: `SOURCES' exists but is not a directory
make: *** [srpm] Error 1
[EMAIL PROTECTED] kvm-49]#
So I retried it after remaking SOURCES.
[EMAIL PROTECTED] kvm-49]# rm SOURCES
rm: remove regular file `SOURCES'? yes
[EMAIL PROTECTED] kvm-49]# mkdir SOURCES
[EMAIL PROTECTED] kvm-49]# make rpm
mkdir -p SOURCES SRPMS
sed 's/^Release:.*/Release: devel/' kvm.spec .tmp.kvm.spec
tar czf SOURCES/kvm.tar.gz qemu
tar czf SOURCES/user.tar.gz user
tar czf SOURCES/kernel.tar.gz kernel
tar czf SOURCES/scripts.tar.gz scripts
cp Makefile configure kvm_stat SOURCES
rpmbuild --define=_topdir $(pwd) -bs .tmp.kvm.spec
error: types must match
error: /root/kvm-49/.tmp.kvm.spec:18: parseExpressionBoolean returns -1
error: Package has no %description: kvm
make: *** [srpm] Error 1
[EMAIL PROTECTED] kvm-49]#
After I fixed above, I got some more errors...
I think we can't treat it as more than a sample because we can't expect
it to work everywhere (e.g. debian). But i will accept patches to
improve it.
OK, I agree.
What do you think about it?
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
-/usr/kvm
+%dir /usr/kvm
+%dir /usr/kvm/bin
+/usr/kvm/bin/qemu-img
+/usr/kvm/bin/qemu-system-x86_64
+%dir /usr/kvm/share
+%dir /usr/kvm/share/qemu
+/usr/kvm/share/qemu/bios.bin
+%dir /usr/kvm/share/qemu/keymaps
+/usr/kvm/share/qemu/keymaps/ar
+/usr/kvm/share/qemu/keymaps/common
+/usr/kvm/share/qemu/keymaps/da
+/usr/kvm/share/qemu/keymaps/de
+/usr/kvm/share/qemu/keymaps/de-ch
+/usr/kvm/share/qemu/keymaps/en-gb
+/usr/kvm/share/qemu/keymaps/en-us
+/usr/kvm/share/qemu/keymaps/es
+/usr/kvm/share/qemu/keymaps/et
+/usr/kvm/share/qemu/keymaps/fi
+/usr/kvm/share/qemu/keymaps/fo
+/usr/kvm/share/qemu/keymaps/fr
+/usr/kvm/share/qemu/keymaps/fr-be
+/usr/kvm/share/qemu/keymaps/fr-ca
+/usr/kvm/share/qemu/keymaps/fr-ch
+/usr/kvm/share/qemu/keymaps/hr
+/usr/kvm/share/qemu/keymaps/hu
+/usr/kvm/share/qemu/keymaps/is
+/usr/kvm/share/qemu/keymaps/it
+/usr/kvm/share/qemu/keymaps/ja
+/usr/kvm/share/qemu/keymaps/lt
+/usr/kvm/share/qemu/keymaps/lv
+/usr/kvm/share/qemu/keymaps/mk
+/usr/kvm/share/qemu/keymaps/modifiers
+/usr/kvm/share/qemu/keymaps/nl
+/usr/kvm/share/qemu/keymaps/nl-be
+/usr/kvm/share/qemu/keymaps/no
+/usr/kvm/share/qemu/keymaps/pl
+/usr/kvm/share/qemu/keymaps/pt
+/usr/kvm/share/qemu/keymaps/pt-br
+/usr/kvm/share/qemu/keymaps/ru
+/usr/kvm/share/qemu/keymaps/sl
+/usr/kvm/share/qemu/keymaps/sv
+/usr/kvm/share/qemu/keymaps/th
+/usr/kvm/share/qemu/keymaps/tr
+/usr/kvm/share/qemu/openbios-sparc32
+/usr/kvm/share/qemu/ppc_rom.bin
+/usr/kvm/share/qemu/pxe-ne2k_pci.bin
+/usr/kvm/share/qemu/pxe-pcnet.bin
+/usr/kvm/share/qemu/pxe-rtl8139.bin
+/usr/kvm/share/qemu/vgabios-cirrus.bin
+/usr/kvm/share/qemu/vgabios.bin
+/usr/kvm/share/qemu/video.x
+%dir /lib/modules/%{uname}/extra
+/lib/modules/%{uname}/extra/kvm.ko
+/lib/modules/%{uname}/extra/kvm-intel.ko
+/lib/modules/%{uname}/extra/kvm-amd.ko
%changelog
Why is this change necessary? Doesn't '/usr/kvm' work? This way, every
time qemu adds a file we have to update the rpm spec.
Exactly, I think better writing these, but actually these are not needed.
So when qemu is updated, we need to update these as you said.
I'll put back them because it's messy.
Best Regards,
Akio Takebe
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote: OK, so how can a device inform kernel for an IRQ in S390? Oooh, that is a looong explanation. If you want to peek at it, see http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf . Chapter 6 covers Interruptions. I'd recommend to start with reading external interruptions, because that is the one we'll be primarily be using with kvm. External interruptions are used for things like timers, hypercalls, and IPIs. The Program Interruption Coditions are also worth reading, they cover things similar to general protection fault on x86. Chapter 11 covers a different type of Interruptions, such as error detection of hardware failures and hot-standby component failover. Chapter 16 is also of interrest, it covers I/O interruptions. Whenever you see me in person (next kvm forum maybe?), you are invited to a lot of beer: I'll bring pen and paper and try to give you an overview while we get drunk :-). so long, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch][RFC] fix make rpm
Akio Takebe wrote: Hi, Avi Thank you for your comments. This patch fix make rpm. When I used the rpm option, I got some error. So I fixed it, but it is a just sample? 'make rpm' works for me on F7 (after I fixed fallout from the libkvm separation patch). What distribution did you run it on? What error did you get? I used RHEL5. I got the following error at fist. [EMAIL PROTECTED] kvm-49]# make rpm mkdir -p SOURCES SRPMS mkdir: `SOURCES' exists but is not a directory make: *** [srpm] Error 1 [EMAIL PROTECTED] kvm-49]# Ah, SOURCES only exists in the distributed package, not in the git tree. That's why I never got an error. It's probably best to push all the rpm build directories under a new subdirectory rpm/. So I retried it after remaking SOURCES. [EMAIL PROTECTED] kvm-49]# rm SOURCES rm: remove regular file `SOURCES'? yes [EMAIL PROTECTED] kvm-49]# mkdir SOURCES [EMAIL PROTECTED] kvm-49]# make rpm mkdir -p SOURCES SRPMS sed 's/^Release:.*/Release: devel/' kvm.spec .tmp.kvm.spec tar czf SOURCES/kvm.tar.gz qemu tar czf SOURCES/user.tar.gz user tar czf SOURCES/kernel.tar.gz kernel tar czf SOURCES/scripts.tar.gz scripts cp Makefile configure kvm_stat SOURCES rpmbuild --define=_topdir $(pwd) -bs .tmp.kvm.spec error: types must match error: /root/kvm-49/.tmp.kvm.spec:18: parseExpressionBoolean returns -1 This can be fixed by updating the check on line 18 to include RHEL. We do need the BuildRequires below... error: Package has no %description: kvm make: *** [srpm] Error 1 [EMAIL PROTECTED] kvm-49]# After I fixed above, I got some more errors... -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Avi Kivity wrote:
But that doesn't make the code portable. The s390 userspace has to know
how to encode the number, and x86 will do it differently.
If it's really different, let's keep it different. Unless you can push
the encoding so far back it's transparent to userspace (e.g. qemu).
I agree that we should keep it seperate unless it makes sense to have
commonality.
A paravirt driver for example could make use of this abstraction: it
could request an interrupt, and hand the __u64 that it got back to a
function that actually sends the interrupt over.
But for now, I agree we should keep it seperate. I am just thinking
loud here.
In addition, I would love to be able to specify which target CPUs may
receive that interrupt because our IPI equivalent comes out just like
a regular interrupt on just one target CPU.
That boils down to something like this:
struct kvm_interrupt_data {
__u64 interrupt_number;
cpuset_t possible_target_cpus;
}
and an KVM_INJECT_INTERRUPT common ioctl for the vm to provide this.
Are cpusets exported to userspace?
x86 has something similar (IPI to a set of cpus) but it's handled 100%
in the kernel these days.
No they are'nt. We'd need to come up with a different data structure
for that. Does IPI have an interrupt number too?
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Carsten Otte wrote:
In addition, I would love to be able to specify which target CPUs
may receive that interrupt because our IPI equivalent comes out just
like a regular interrupt on just one target CPU.
That boils down to something like this:
struct kvm_interrupt_data {
__u64 interrupt_number;
cpuset_t possible_target_cpus;
}
and an KVM_INJECT_INTERRUPT common ioctl for the vm to provide this.
Are cpusets exported to userspace?
x86 has something similar (IPI to a set of cpus) but it's handled
100% in the kernel these days.
No they are'nt. We'd need to come up with a different data structure
for that.
A bitmap would do it, but what size? Expandable ones are messy.
Does IPI have an interrupt number too?
No, it's a command (mmio) to the APIC, you tell it which vector you want
and to which cpus you want it delivered. So you can have many IPI
interrupt vectors.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Avi Kivity wrote: A bitmap would do it, but what size? Expandable ones are messy. We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific header files that go to include/asm/. For s390, we have one of our rocket science virtualization accelerating facilities that limits us to 64 cpus per guest. This may well be extended later on, but for now that would be sufficient. Thinking about Christoph Lameter with his 4k CPU boxes, I believe ia64 would want fr more than that. No, it's a command (mmio) to the APIC, you tell it which vector you want and to which cpus you want it delivered. So you can have many IPI interrupt vectors. I see. But the interrupt vector can be encoded in __u64? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Carsten Otte wrote:
Avi Kivity wrote:
A bitmap would do it, but what size? Expandable ones are messy.
We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific
header files that go to include/asm/. For s390, we have one of our
rocket science virtualization accelerating facilities that limits us
to 64 cpus per guest. This may well be extended later on, but for now
that would be sufficient. Thinking about Christoph Lameter with his 4k
CPU boxes, I believe ia64 would want fr more than that.
If there's a single variable length array (which is the case here) it
can be tucked on at the end:
struct kvm_ipi {
__u64 vector;
__u32 size; /* bytes, must be multiple of 8 */
__u32 pad;
__u64 cpuset[0];
};
We have this in a few places. Not pretty, but serviceable.
No, it's a command (mmio) to the APIC, you tell it which vector you
want and to which cpus you want it delivered. So you can have many
IPI interrupt vectors.
I see. But the interrupt vector can be encoded in __u64?
The vector is just a u8.
The x86 interrupt path looks like this:
[devices] -- irq -- [interrupt controllers] vector --- [processor]
The interrupt controllers translate irq lines into vectors, which the
processor consumes. Before kvm-irqchip, the API taked about vectors
since the interrupt controller was in userspace. Nowadays userspace
talks irq lines to the kernel, which converts them into vectors.
If I uderstand correctly, s390 is interrupt vector oriented, no?
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Question about KVM-test
* Alexey Eremenko [EMAIL PROTECTED] [2007-10-30 04:26]: It seems nice ! But is there any documentation ? I don't know how-to start it. Have you read the wiki page? http://kvm.qumranet.com/kvmwiki/KVMTest basically, you want to use kvm-test-record where you would normally use qemu. So, if you launch your guest with: qemu -hda /dev/hda1 -boot d -snapshot You would run: kvm-test-record -hda /dev/hda1 -boot d -snapshot In the screen that pops up, there is a menu item (Barriers) where you can make a barrier. When you are done making barriers for this guest run, you can replay the session using: kvm-test-replay in the same directory where the vm.log and screenshots were recorded. kvm-test-replay will re-run qemu as you invoked it with kvm-test-record and attempt to inject the same inputs at the recorded time intervals and match the barriers if any exist. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Question about KVM-test
-Original Message- From: Ryan Harper [mailto:[EMAIL PROTECTED] Sent: Tue 10/30/2007 7:46 AM To: Alexey Eremenko Cc: kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] Question about KVM-test * Alexey Eremenko [EMAIL PROTECTED] [2007-10-30 04:26]: It seems nice ! But is there any documentation ? I don't know how-to start it. Have you read the wiki page? http://kvm.qumranet.com/kvmwiki/KVMTest basically, you want to use kvm-test-record where you would normally use qemu. So, if you launch your guest with: qemu -hda /dev/hda1 -boot d -snapshot You would run: kvm-test-record -hda /dev/hda1 -boot d -snapshot In the screen that pops up, there is a menu item (Barriers) where you can make a barrier. When you are done making barriers for this guest run, you can replay the session using: kvm-test-replay in the same directory where the vm.log and screenshots were recorded. kvm-test-replay will re-run qemu as you invoked it with kvm-test-record and attempt to inject the same inputs at the recorded time intervals and match the barriers if any exist. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] == Thanks, but how do I download this ?!?: http://gtk-vnc.sourceforge.net/hg/aliguori.hg/file/5a5dcebe8d86 Is there .tar.gz around, or documentation about downloading it ? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
[EMAIL PROTECTED] wrote: Avi Kivity wrote: A bitmap would do it, but what size? Expandable ones are messy. We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific header files that go to include/asm/. For s390, we have one of our rocket science virtualization accelerating facilities that limits us to 64 cpus per guest. This may well be extended later on, but for now that would be sufficient. Thinking about Christoph Lameter with his 4k CPU boxes, I believe ia64 would want fr more than that. IA64/KVM will handle interrupt in kernel including IPI IMO, so what user level need to tell kernel is which platform IRQ pin is set/cleared. Can't S390 do in similar way? From platform point of view, each irq can have a unique # and the device itself doesn;t need to know which CPU will receive it. Are talking about having your interrupt controller in user space? or I missed something. Love to study the spec later :-) Eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch][RFC] fix make rpm
On Tue, 2007-10-30 at 13:59 +0200, Avi Kivity wrote: -/usr/kvm +%dir /usr/kvm +%dir /usr/kvm/bin +/usr/kvm/bin/qemu-img +/usr/kvm/bin/qemu-system-x86_64 [...] Why is this change necessary? Doesn't '/usr/kvm' work? This way, every time qemu adds a file we have to update the rpm spec. FYI, I got burned by exactly this problem once. Due to a missing prereq, a package build didn't produce all the output it should have. However, because I hadn't listed every output explicitly, rpm happily packaged everything else, and the package shipped in a distro before anybody realized anything was missing. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch portability: split kvm_vm_ioctl v3
Dong, Eddie wrote:
IA64/KVM will handle interrupt in kernel including IPI IMO, so what
user level need to tell kernel is which platform IRQ pin is set/cleared.
Can't S390 do in similar way? From platform point of view, each
irq can have a unique # and the device itself doesn;t need to know
which CPU will receive it. Are talking about having your interrupt
controller in user space? or I missed something.
We don't have interrupt controllers in the first place, and therefore
we don't need to emulate them. We want to handle IPI inside the kernel
too, and we also need to be able to inject interrupts from userspace.
Would you be able to encode your interrupt related information into an
__u64 data type? Do all CPUs have the same interrupts pending, or is
the information per-cpu? Does the data structure that Avi suggested
fit your interrupt injection needs?
struct kvm_interrupt {
__u64 vector;
__u32 size; /* bytes, must be multiple of 8 */
__u32 pad;
__u64 cpuset[0];
};
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Question about KVM-test
* Alexey Eremenko [EMAIL PROTECTED] [2007-10-30 10:11]: -Original Message- From: Ryan Harper [mailto:[EMAIL PROTECTED] Sent: Tue 10/30/2007 7:46 AM To: Alexey Eremenko Cc: kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] Question about KVM-test * Alexey Eremenko [EMAIL PROTECTED] [2007-10-30 04:26]: It seems nice ! But is there any documentation ? I don't know how-to start it. Have you read the wiki page? http://kvm.qumranet.com/kvmwiki/KVMTest basically, you want to use kvm-test-record where you would normally use qemu. So, if you launch your guest with: qemu -hda /dev/hda1 -boot d -snapshot You would run: kvm-test-record -hda /dev/hda1 -boot d -snapshot In the screen that pops up, there is a menu item (Barriers) where you can make a barrier. When you are done making barriers for this guest run, you can replay the session using: kvm-test-replay in the same directory where the vm.log and screenshots were recorded. kvm-test-replay will re-run qemu as you invoked it with kvm-test-record and attempt to inject the same inputs at the recorded time intervals and match the barriers if any exist. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] == Thanks, but how do I download this ?!?: http://gtk-vnc.sourceforge.net/hg/aliguori.hg/file/5a5dcebe8d86 hg clone http://gtk-vnc.sourceforge.net/hg/aliguori.hg Is there .tar.gz around, or documentation about downloading it ? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch 1/3 portability: move kvm_get/set_msr[_common] to x86.c
This patch moves the implementation of the functions of kvm_get/set_msr,
kvm_get/set_msr_common, and set_efer from kvm_main.c to x86.c. The
definition of EFER_RESERVED_BITS is moved too.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
kvm_main.c | 133
x86.c | 134 +
2 files changed, 134 insertions(+), 133 deletions(-)
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-30 11:28:41.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-30 14:30:34.0 +0100
@@ -90,8 +90,6 @@
static struct dentry *debugfs_dir;
-#define EFER_RESERVED_BITS 0xf2fe
-
static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
unsigned long arg);
@@ -1347,137 +1345,6 @@
}
}
-int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
-{
- u64 data;
-
- switch (msr) {
- case 0xc0010010: /* SYSCFG */
- case 0xc0010015: /* HWCR */
- case MSR_IA32_PLATFORM_ID:
- case MSR_IA32_P5_MC_ADDR:
- case MSR_IA32_P5_MC_TYPE:
- case MSR_IA32_MC0_CTL:
- case MSR_IA32_MCG_STATUS:
- case MSR_IA32_MCG_CAP:
- case MSR_IA32_MC0_MISC:
- case MSR_IA32_MC0_MISC+4:
- case MSR_IA32_MC0_MISC+8:
- case MSR_IA32_MC0_MISC+12:
- case MSR_IA32_MC0_MISC+16:
- case MSR_IA32_UCODE_REV:
- case MSR_IA32_PERF_STATUS:
- case MSR_IA32_EBL_CR_POWERON:
- /* MTRR registers */
- case 0xfe:
- case 0x200 ... 0x2ff:
- data = 0;
- break;
- case 0xcd: /* fsb frequency */
- data = 3;
- break;
- case MSR_IA32_APICBASE:
- data = kvm_get_apic_base(vcpu);
- break;
- case MSR_IA32_MISC_ENABLE:
- data = vcpu-ia32_misc_enable_msr;
- break;
-#ifdef CONFIG_X86_64
- case MSR_EFER:
- data = vcpu-shadow_efer;
- break;
-#endif
- default:
- pr_unimpl(vcpu, unhandled rdmsr: 0x%x\n, msr);
- return 1;
- }
- *pdata = data;
- return 0;
-}
-EXPORT_SYMBOL_GPL(kvm_get_msr_common);
-
-/*
- * Reads an msr value (of 'msr_index') into 'pdata'.
- * Returns 0 on success, non-0 otherwise.
- * Assumes vcpu_load() was already called.
- */
-int kvm_get_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata)
-{
- return kvm_x86_ops-get_msr(vcpu, msr_index, pdata);
-}
-
-#ifdef CONFIG_X86_64
-
-static void set_efer(struct kvm_vcpu *vcpu, u64 efer)
-{
- if (efer EFER_RESERVED_BITS) {
- printk(KERN_DEBUG set_efer: 0x%llx #GP, reserved bits\n,
- efer);
- inject_gp(vcpu);
- return;
- }
-
- if (is_paging(vcpu)
-(vcpu-shadow_efer EFER_LME) != (efer EFER_LME)) {
- printk(KERN_DEBUG set_efer: #GP, change LME while paging\n);
- inject_gp(vcpu);
- return;
- }
-
- kvm_x86_ops-set_efer(vcpu, efer);
-
- efer = ~EFER_LMA;
- efer |= vcpu-shadow_efer EFER_LMA;
-
- vcpu-shadow_efer = efer;
-}
-
-#endif
-
-int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
-{
- switch (msr) {
-#ifdef CONFIG_X86_64
- case MSR_EFER:
- set_efer(vcpu, data);
- break;
-#endif
- case MSR_IA32_MC0_STATUS:
- pr_unimpl(vcpu, %s: MSR_IA32_MC0_STATUS 0x%llx, nop\n,
- __FUNCTION__, data);
- break;
- case MSR_IA32_MCG_STATUS:
- pr_unimpl(vcpu, %s: MSR_IA32_MCG_STATUS 0x%llx, nop\n,
- __FUNCTION__, data);
- break;
- case MSR_IA32_UCODE_REV:
- case MSR_IA32_UCODE_WRITE:
- case 0x200 ... 0x2ff: /* MTRRs */
- break;
- case MSR_IA32_APICBASE:
- kvm_set_apic_base(vcpu, data);
- break;
- case MSR_IA32_MISC_ENABLE:
- vcpu-ia32_misc_enable_msr = data;
- break;
- default:
- pr_unimpl(vcpu, unhandled wrmsr: 0x%x\n, msr);
- return 1;
- }
- return 0;
-}
-EXPORT_SYMBOL_GPL(kvm_set_msr_common);
-
-/*
- * Writes msr value into into the appropriate register.
- * Returns 0 on success, non-0 otherwise.
- * Assumes vcpu_load() was already called.
- */
-int kvm_set_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 data)
-{
- return kvm_x86_ops-set_msr(vcpu, msr_index, data);
-}
-
void kvm_resched(struct kvm_vcpu *vcpu)
{
if (!need_resched())
Index: kvm/drivers/kvm/x86.c
===
--- kvm.orig/drivers/kvm/x86.c 2007-10-30 11:28:41.0 +0100
+++ kvm/drivers/kvm/x86.c 2007-10-30
[kvm-devel] RFC/patch 0/3 portability: please review
Thanks to Xiantao and Hollis for your quick review of last patch series. Thanks Avi for finding time to pick up last patches on your trip to Japan. This series of patches moves more code from kvm_main.c to x86.c. I start seeing the light at the end of the tunnel, I think these should be the last big blocks that don't fit into kvm_main.c for s390. From here on, I think I will use a much smaller hammer to get all the details right. :-) Please review the patches to make sure nothing gets moved out that should be common. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] RFC/patch 3/3 portability: move pio emulation functions to x86.c
This patch moves implementation of the following functions from
kvm_main.c to x86.c:
free_pio_guest_pages, vcpu_find_pio_dev, pio_copy_data, complete_pio,
kernel_pio, pio_string_write, kvm_emulate_pio, kvm_emulate_pio_string
The function inject_gp, which was duplicated by yesterday's patch
series, is removed from kvm_main.c now because it is not needed anymore.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
kvm_main.c | 248 -
x86.c | 243 +++
x86.h |1
3 files changed, 244 insertions(+), 248 deletions(-)
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-10-30 18:27:56.0 +0100
+++ kvm/drivers/kvm/kvm_main.c 2007-10-30 18:30:48.0 +0100
@@ -271,17 +271,6 @@
kvm_free_physmem_slot(kvm-memslots[i], NULL);
}
-static void free_pio_guest_pages(struct kvm_vcpu *vcpu)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(vcpu-pio.guest_pages); ++i)
- if (vcpu-pio.guest_pages[i]) {
- kvm_release_page(vcpu-pio.guest_pages[i]);
- vcpu-pio.guest_pages[i] = NULL;
- }
-}
-
static void kvm_unload_vcpu_mmu(struct kvm_vcpu *vcpu)
{
vcpu_load(vcpu);
@@ -330,11 +319,6 @@
return 0;
}
-static void inject_gp(struct kvm_vcpu *vcpu)
-{
- kvm_x86_ops-inject_gp(vcpu, 0);
-}
-
void fx_init(struct kvm_vcpu *vcpu)
{
unsigned after_mxcsr_mask;
@@ -817,12 +801,6 @@
}
}
-static struct kvm_io_device *vcpu_find_pio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
-{
- return kvm_io_bus_find_dev(vcpu-kvm-pio_bus, addr);
-}
-
/*
* The vCPU has executed a HLT instruction with in-kernel mode enabled.
*/
@@ -1032,232 +1010,6 @@
}
EXPORT_SYMBOL_GPL(kvm_emulate_cpuid);
-static int pio_copy_data(struct kvm_vcpu *vcpu)
-{
- void *p = vcpu-pio_data;
- void *q;
- unsigned bytes;
- int nr_pages = vcpu-pio.guest_pages[1] ? 2 : 1;
-
- q = vmap(vcpu-pio.guest_pages, nr_pages, VM_READ|VM_WRITE,
-PAGE_KERNEL);
- if (!q) {
- free_pio_guest_pages(vcpu);
- return -ENOMEM;
- }
- q += vcpu-pio.guest_page_offset;
- bytes = vcpu-pio.size * vcpu-pio.cur_count;
- if (vcpu-pio.in)
- memcpy(q, p, bytes);
- else
- memcpy(p, q, bytes);
- q -= vcpu-pio.guest_page_offset;
- vunmap(q);
- free_pio_guest_pages(vcpu);
- return 0;
-}
-
-static int complete_pio(struct kvm_vcpu *vcpu)
-{
- struct kvm_pio_request *io = vcpu-pio;
- long delta;
- int r;
-
- kvm_x86_ops-cache_regs(vcpu);
-
- if (!io-string) {
- if (io-in)
- memcpy(vcpu-regs[VCPU_REGS_RAX], vcpu-pio_data,
- io-size);
- } else {
- if (io-in) {
- r = pio_copy_data(vcpu);
- if (r) {
- kvm_x86_ops-cache_regs(vcpu);
- return r;
- }
- }
-
- delta = 1;
- if (io-rep) {
- delta *= io-cur_count;
- /*
-* The size of the register should really depend on
-* current address size.
-*/
- vcpu-regs[VCPU_REGS_RCX] -= delta;
- }
- if (io-down)
- delta = -delta;
- delta *= io-size;
- if (io-in)
- vcpu-regs[VCPU_REGS_RDI] += delta;
- else
- vcpu-regs[VCPU_REGS_RSI] += delta;
- }
-
- kvm_x86_ops-decache_regs(vcpu);
-
- io-count -= io-cur_count;
- io-cur_count = 0;
-
- return 0;
-}
-
-static void kernel_pio(struct kvm_io_device *pio_dev,
- struct kvm_vcpu *vcpu,
- void *pd)
-{
- /* TODO: String I/O for in kernel device */
-
- mutex_lock(vcpu-kvm-lock);
- if (vcpu-pio.in)
- kvm_iodevice_read(pio_dev, vcpu-pio.port,
- vcpu-pio.size,
- pd);
- else
- kvm_iodevice_write(pio_dev, vcpu-pio.port,
- vcpu-pio.size,
- pd);
- mutex_unlock(vcpu-kvm-lock);
-}
-
-static void pio_string_write(struct kvm_io_device *pio_dev,
-struct kvm_vcpu *vcpu)
-{
- struct kvm_pio_request *io = vcpu-pio;
- void *pd = vcpu-pio_data;
- int i;
-
- mutex_lock(vcpu-kvm-lock);
-
Re: [kvm-devel] RFC/patch 2/3 portability: move x86 emulation and mmio device hook to x86.c
On Tue, 2007-10-30 at 18:44 +0100, Carsten Otte wrote:
-/*
- * Only apic need an MMIO device hook, so shortcut now..
- */
-static struct kvm_io_device *vcpu_find_pervcpu_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
-{
- struct kvm_io_device *dev;
-
- if (vcpu-apic) {
- dev = vcpu-apic-dev;
- if (dev-in_range(dev, addr))
- return dev;
- }
- return NULL;
-}
-
-static struct kvm_io_device *vcpu_find_mmio_dev(struct kvm_vcpu *vcpu,
- gpa_t addr)
-{
- struct kvm_io_device *dev;
-
- dev = vcpu_find_pervcpu_dev(vcpu, addr);
- if (dev == NULL)
- dev = kvm_io_bus_find_dev(vcpu-kvm-mmio_bus, addr);
- return dev;
-}
-
static struct kvm_io_device *vcpu_find_pio_dev(struct kvm_vcpu *vcpu,
gpa_t addr)
{
return kvm_io_bus_find_dev(vcpu-kvm-pio_bus, addr);
}
These are APIC-specific for now, but as the shortcut comment implies
they should be generalized in the future, and I expect they will be
useful for PowerPC.
I'm fine with the patch as-is; I just want to point out that future work
will be needed in this area.
Acked-by: Hollis Blanchard [EMAIL PROTECTED]
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 3/3 portability: move pio emulation functions to x86.c
On Tue, 2007-10-30 at 18:44 +0100, Carsten Otte wrote: This patch moves implementation of the following functions from kvm_main.c to x86.c: free_pio_guest_pages, vcpu_find_pio_dev, pio_copy_data, complete_pio, kernel_pio, pio_string_write, kvm_emulate_pio, kvm_emulate_pio_string The function inject_gp, which was duplicated by yesterday's patch series, is removed from kvm_main.c now because it is not needed anymore. Signed-off-by: Carsten Otte [EMAIL PROTECTED] Acked-by: Hollis Blanchard [EMAIL PROTECTED] -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Carsten Otte wrote: Thanks to Xiantao and Hollis for your quick review of last patch series. Thanks Avi for finding time to pick up last patches on your trip to Japan. This series of patches moves more code from kvm_main.c to x86.c. I start seeing the light at the end of the tunnel, I think these should be the last big blocks that don't fit into kvm_main.c for s390. From here on, I think I will use a much smaller hammer to get all the details right. :-) Please review the patches to make sure nothing gets moved out that should be common. Basically, It doesn't impact our side. For patch 2/3, we had better find an approach to handle mmio-realted functions, becasue they may exist in most archs. For IA64, if this move happens, we have to duplicate them in IA64 side. Thanks Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Show this to the kids
I know you hate junk mail, but this is just plane old fun. http://75.20.182.164/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Zhang, Xiantao wrote: Basically, It doesn't impact our side. For patch 2/3, we had better find an approach to handle mmio-realted functions, becasue they may exist in most archs. For IA64, if this move happens, we have to duplicate them in IA64 side. Thanks for your feedback. This matches Hollis' view, I'll try to rework that patch. We're really the only platform without mmio, that's a s390 special case. I'll leave it in common and find a way around for s390. cheers, Carsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote: Zhang, Xiantao wrote: Basically, It doesn't impact our side. For patch 2/3, we had better find an approach to handle mmio-realted functions, becasue they may exist in most archs. For IA64, if this move happens, we have to duplicate them in IA64 side. Thanks for your feedback. This matches Hollis' view, I'll try to rework that patch. We're really the only platform without mmio, that's a s390 special case. I'll leave it in common and find a way around for s390. Well, those functions right now are hacks that assume the only in-kernel device is an APIC. That won't even build for anybody who doesn't have vcpu-apic... that's why I say go ahead and move them, and we can worry about it later. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Hollis Blanchard wrote: On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote: Zhang, Xiantao wrote: Basically, It doesn't impact our side. For patch 2/3, we had better find an approach to handle mmio-realted functions, becasue they may exist in most archs. For IA64, if this move happens, we have to duplicate them in IA64 side. Thanks for your feedback. This matches Hollis' view, I'll try to rework that patch. We're really the only platform without mmio, that's a s390 special case. I'll leave it in common and find a way around for s390. Well, those functions right now are hacks that assume the only in-kernel device is an APIC. That won't even build for anybody who doesn't have vcpu-apic... that's why I say go ahead and move them, and we can worry about it later. Right. Xiantao, does ia64 have an apic? Or do you intend to use the code different from x86? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch] (big) real mode emulation - mul instruction from group 3
Hi Avi, Attached is the patch to implement mul instruction from the group 3 opcodes. Please Apply. -- Thanks Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open 0001-Implement-multipy-instruction-from-the-group-3.patch Description: application/mbox signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Carsten Otte wrote: Thanks to Xiantao and Hollis for your quick review of last patch series. Thanks Avi for finding time to pick up last patches on your trip to Japan. This series of patches moves more code from kvm_main.c to x86.c. I start seeing the light at the end of the tunnel, I think these should be the last big blocks that don't fit into kvm_main.c for s390. From here on, I think I will use a much smaller hammer to get all the details right. :-) Thanks; all three applied. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch] (big) real mode emulation - aas
Hi Avi, Attached is the patch to implement emulation of instruction aas please apply. -- Thanks Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open 0002-Implement-emulation-of-instruction-aas.patch Description: application/mbox signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch] (big) real mode emulation - xchg
Hi Avi, Attached is the patch to implement emulation of further xchg instructions. -- Thanks Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open 0003-Implement-emulation-of-instructions-xchg.patch Description: application/mbox signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch] (big) real mode emulation - jb
Hi Avi, Attached is the patch to implement emulation of instruction: jb (opcode 0xe3) Please apply. -- Thanks Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open 0005-Implement-emulation-of-instruction.patch Description: application/mbox signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch] (big) real mode emulation - mov rl/rh/r
Hi Avi, Attached is the patch to implement emulation of instructions mov rl, imm8 (opcodes 0xb0-0xb3) mov rh, imm8 (opcodes 0xb4-0xb7) mov r, imm (opcodes0xb8-0xbf) please apply. -- Thanks Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open 0004-Implement-emulation-of-instructions-mov-rl-rh-r.patch Description: application/mbox signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: VMX: Enable memory mappedTPR shadow(FlexPriority)
Dong, Eddie wrote: Yes. FlexPriority will be both faster and safer for those who have it than my hack. It may turn out that patching can improve performance even with FlexPriority: we can patch the APIC EOI write to look if any interrupts are pending, and only exit if the EOI will result in a new interrupt being injected. But it is very possible that this will not be necessary if we can achieve good interrupt mitigation with virtio. Mmm, I won't say so. The issues is: A guest EOI (level triggered IRQ) need to clear remote IRR bit in IOAPIC side and resample that pin in IOAPIC side. This one is not easy to do in patched code. Hmm... The patched code needs to answer the question what will happen if I EOI this vector now? I think kvm can prepare the answer for that question, since it knows the irq is still asserted and that the mode is level-triggered. Basically the kvm lapic code has to calculate the IRR for a speculative EOI and post that in the shared memory block. If something changes (the IRQ line is de-asserted, for example) again it has to recalculate it. So yes, it will not be easy. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch][RFC] fix make rpm
Hollis Blanchard wrote: On Tue, 2007-10-30 at 13:59 +0200, Avi Kivity wrote: -/usr/kvm +%dir /usr/kvm +%dir /usr/kvm/bin +/usr/kvm/bin/qemu-img +/usr/kvm/bin/qemu-system-x86_64 [...] Why is this change necessary? Doesn't '/usr/kvm' work? This way, every time qemu adds a file we have to update the rpm spec. FYI, I got burned by exactly this problem once. Due to a missing prereq, a package build didn't produce all the output it should have. However, because I hadn't listed every output explicitly, rpm happily packaged everything else, and the package shipped in a distro before anybody realized anything was missing. Yeah, perhaps the script should have a dangerous label. Or all rpm scripts. Listing the files doesn't actually solve the problem. How does a packager know if a file was removed intenrionally or accidentally? -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - aas
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instruction aas
+ case 0x3f: /* aas */ {
+ u8 al, ah, af, cf;
+ al = c-regs[VCPU_REGS_RAX] 0xff;
+ ah = (c-regs[VCPU_REGS_RAX] 8) 0xff;
+ af = (ctxt-eflags EFLG_AF);
+ cf = (ctxt-eflags EFLG_CF);
+ if (((al 0x0f) 9) || af) {
+ al = al - 6;
+ ah = ah - 1;
+ af = cf = 1;
+ } else {
+ cf = af = 0;
+ }
+ al = al 0x0f;
+ if (af)
+ ctxt-eflags |= EFLG_AF;
+ else
+ ctxt-eflags = ~EFLG_AF;
+ if (cf)
+ ctxt-eflags |= EFLG_CF;
+ else
+ ctxt-eflags = ~EFLG_CF;
+ *(u16 *) c-regs[VCPU_REGS_RAX] = (ah 8) al;
+ }
+ break;
Please move the whole thing to a static function in order to reduce clutter.
Also, a helper
static void set_flag_value(struct emulate_context *ctxt, u32 mask,
int value) {... }
can simplify some of the code.
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - stc,cld
Nitin A Kamble wrote: Hi Avi, Attached is the patch to implement emulation of instructions stc (opcode 0xf9) cld (opcode 0xfc) + case 0xfc: /* cld */ + ctxt-eflags |= X86_EFLAGS_DF; + c-dst.type = OP_NONE; /* Disable writeback. */ + break; } This is 'cld', but it looks like you're setting DF? -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - jb
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instruction:
jb (opcode 0xe3)
[PATCH] Implement emulation of instruction jb (conditional jump)
opcodes: 0xe3
From:
Nitin A Kamble [EMAIL PROTECTED]
To:
Date:
2007-10-31 05:41
Signed-off-by: Nitin A Kamble [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c | 25 -
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 579cfcf..1357355 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -165,7 +165,7 @@ static u16 opcode_table[256] = {
/* 0xD8 - 0xDF */
0, 0, 0, 0, 0, 0, 0, 0,
/* 0xE0 - 0xE7 */
- 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, ImplicitOps, 0, 0, 0, 0,
/* 0xE8 - 0xEF */
ImplicitOps, SrcImm|ImplicitOps, 0, SrcImmByte|ImplicitOps, 0,
0, 0, 0,
/* 0xF0 - 0xF7 */
@@ -1446,6 +1446,29 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops)
c-src.val = c-regs[VCPU_REGS_RCX];
emulate_grp2(ctxt);
break;
+ case 0xe3 : /* jb */ {
+ int rel = insn_fetch(s8, 1, c-eip);
+ int condition = 0;
+ if (test_cc(c-b, ctxt-eflags)) {
+ switch (c-op_bytes) {
+ case 2:
+ condition =
+ (0 == *(u16 *)
c-regs[VCPU_REGS_RCX]);
+ break;
+ case 4:
+ condition =
+ (0 == *(u32 *)
c-regs[VCPU_REGS_RCX]);
+ break;
+ case 8:
+ condition =
+ (0 == *(u64 *)
c-regs[VCPU_REGS_RCX]);
+ break;
+ }
+ }
+ if (condition)
+ JMP_REL(rel);
+ break;
+ }
case 0xf6 ... 0xf7: /* Grp3 */
rc = emulate_grp3(ctxt, ops);
if (rc != 0)
This looks more like jcxz?
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - mul instruction from group 3
Nitin A Kamble wrote: Hi Avi, Attached is the patch to implement mul instruction from the group 3 opcodes. diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c index 3959c20..5815128 100644 --- a/drivers/kvm/x86_emulate.c +++ b/drivers/kvm/x86_emulate.c @@ -1034,6 +1034,8 @@ static inline int emulate_grp3(struct x86_emulate_ctxt *ctxt, case 3:/* neg */ emulate_1op(neg, c-dst, ctxt-eflags); break; +case 4: /* mul */ +emulate_1op(mul, c-dst, ctxt-eflags); default: DPRINTF(Cannot emulate %02x\n, c-b); rc = X86EMUL_UNHANDLEABLE; This is missing a break;. How are you testing these patches? -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - mov rl/rh/r
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instructions
mov rl, imm8 (opcodes 0xb0-0xb3)
mov rh, imm8 (opcodes 0xb4-0xb7)
mov r, imm (opcodes0xb8-0xbf)
@@ -146,8 +146,12 @@ static u16 opcode_table[256] = {
0, 0, ByteOp | ImplicitOps | Mov, ImplicitOps | Mov,
ByteOp | ImplicitOps | Mov, ImplicitOps | Mov,
ByteOp | ImplicitOps, ImplicitOps,
- /* 0xB0 - 0xBF */
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ /* 0xB0 - 0xB7 */
+ Mov | SrcImmByte, Mov | SrcImmByte, Mov | SrcImmByte, Mov |
SrcImmByte,
+ Mov | SrcImmByte, Mov | SrcImmByte, Mov | SrcImmByte, Mov |
SrcImmByte,
+ /* 0xB8 - 0xBF */
+ Mov | SrcImm, Mov | SrcImm, Mov | SrcImm, Mov | SrcImm,
+ Mov | SrcImm, Mov | SrcImm, Mov | SrcImm, Mov | SrcImm,
/* 0xC0 - 0xC7 */
Perhaps adding DstReg would reduce the decoding code later on?
--
Any sufficiently difficult bug is indistinguishable from a feature.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM-49 crash on XP(SP2) install
Tim Dempsey wrote: Avi, I have subscribed to the mailing list, so hopefully my responses will be threaded. You don't actually need to subscribe for that. Simply hitting reply-to-all every time should work. The patch you sent appeared to work initially. But when I repeated the install I received the same symptom. A blank qemu/kvm window with stopped in the title bar. Looks like you're hitting a different problem now. Code: 31 d9 31 f8 09 c1 74 2b 8b 0c 24 b8 01 00 00 00 31 db 89 86 74 0d 00 00 89 ea 89 f8 09 da 81 e1 01 08 00 00 09 c8 b9 80 00 00 c0 0f 30 ff 86 b0 00 00 00 8b 5c 24 08 8b 74 24 0c 8b 7c 24 10 8b EIP: [f8f99222] vmx_save_host_state+0x132/0x190 [kvm_intel] SS:ESP Hmm, the EFER-less T2600 strikes again. I'll prepare a patch. -- Any sufficiently difficult bug is indistinguishable from a feature. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Carsten Otte wrote: Hollis Blanchard wrote: On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote: Zhang, Xiantao wrote: Basically, It doesn't impact our side. For patch 2/3, we had better find an approach to handle mmio-realted functions, becasue they may exist in most archs. For IA64, if this move happens, we have to duplicate them in IA64 side. Thanks for your feedback. This matches Hollis' view, I'll try to rework that patch. We're really the only platform without mmio, that's a s390 special case. I'll leave it in common and find a way around for s390. Well, those functions right now are hacks that assume the only in-kernel device is an APIC. That won't even build for anybody who doesn't have vcpu-apic... that's why I say go ahead and move them, and we can worry about it later. Right. Xiantao, does ia64 have an apic? Or do you intend to use the code different from x86? Yes, IA64 has sapic which has mostly same logic with apic. So, we can reuse all ioapic code belongs to x86. I will find the approach to handle it once IA64 code in. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] RFC/patch 0/3 portability: please review
Hollis Blanchard wrote: On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote: Zhang, Xiantao wrote: Basically, It doesn't impact our side. For patch 2/3, we had better find an approach to handle mmio-realted functions, becasue they may exist in most archs. For IA64, if this move happens, we have to duplicate them in IA64 side. Thanks for your feedback. This matches Hollis' view, I'll try to rework that patch. We're really the only platform without mmio, that's a s390 special case. I'll leave it in common and find a way around for s390. Well, those functions right now are hacks that assume the only in-kernel device is an APIC. That won't even build for anybody who doesn't have vcpu-apic... that's why I say go ahead and move them, and we can worry about it later. IA64 has apic, and would reuse all ioapic code for in-kernel ioapic emualtion. But for now, we can move it, and handle it later. :) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - mul instruction from group 3
On Tue, 2007-10-30 at 17:53 -0700, Avi Kivity wrote: This is missing a break;. Hi Avi, You are right. The break statement should be there. It was my mistake while getting the patch out from the test tree to the push tree. Even if it is a small patch I should not retype it. How are you testing these patches? I am running SL101 guest through my test tree. In my test tree the patch is good, it was the bug introduced while copying. -- Thanks Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - mov rl/rh/r
On Tue, 2007-10-30 at 18:06 -0700, Avi Kivity wrote:
Nitin A Kamble wrote:
Hi Avi,
Attached is the patch to implement emulation of instructions
mov rl, imm8 (opcodes 0xb0-0xb3)
mov rh, imm8 (opcodes 0xb4-0xb7)
mov r, imm (opcodes0xb8-0xbf)
@@ -146,8 +146,12 @@ static u16 opcode_table[256] = {
0, 0, ByteOp | ImplicitOps | Mov, ImplicitOps | Mov,
ByteOp | ImplicitOps | Mov, ImplicitOps | Mov,
ByteOp | ImplicitOps, ImplicitOps,
- /* 0xB0 - 0xBF */
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ /* 0xB0 - 0xB7 */
+ Mov | SrcImmByte, Mov | SrcImmByte, Mov | SrcImmByte, Mov |
SrcImmByte,
+ Mov | SrcImmByte, Mov | SrcImmByte, Mov | SrcImmByte, Mov |
SrcImmByte,
+ /* 0xB8 - 0xBF */
+ Mov | SrcImm, Mov | SrcImm, Mov | SrcImm, Mov | SrcImm,
+ Mov | SrcImm, Mov | SrcImm, Mov | SrcImm, Mov | SrcImm,
/* 0xC0 - 0xC7 */
Perhaps adding DstReg would reduce the decoding code later on?
Avi,
The decoding of register is significantly different for these
instructions. It will be just moving code from one place to other place.
+ c-dst.ptr =
+ (unsigned long *)c-regs[VCPU_REGS_RAX + (c-b
0x3)];
+ c-dst.ptr =
+ ((void *)c-regs[VCPU_REGS_RAX + (c-b 0x3)]
+ 1);
+ c-dst.ptr =
+ (unsigned long *)c-regs[VCPU_REGS_RAX + (c-b
0x7)];
--
Any sufficiently difficult bug is indistinguishable from a feature.
--
Thanks Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when it's open
signature.asc
Description: This is a digitally signed message part
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [patch] (big) real mode emulation - stc,cld
On Tue, 2007-10-30 at 18:02 -0700, Avi Kivity wrote: This is 'cld', but it looks like you're setting DF? Good catch. Same problem hand copy of the patch. It should look like this. + case 0xfc: /* cld */ + ctxt-eflags = ~EFLG_DF; -- Thanks Regards, Nitin Open Source Technology Center, Intel Corporation - The mind is like a parachute; it works much better when it's open signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
