[Xen-devel] [linux-next test] 33122: regressions - FAIL
flight 33122 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33122/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 33087 Regressions which are regarded as allowable (not blocking): build-armhf-libvirt 5 libvirt-buildfail like 33087 build-i386-libvirt5 libvirt-buildfail like 33087 build-amd64-libvirt 5 libvirt-buildfail like 33087 test-amd64-i386-freebsd10-amd64 7 freebsd-install fail like 33087 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 33087 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33087 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 33087 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: linux35393dcb2ed331e8698a548fbba8042457f5fd32 baseline version: linuxd753856c9f9ae33a980192aa7b81d8b97d79dec2 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail
[Xen-devel] Fw: Dataset for pre-copy while migrating VM???
i want to extract dirty page bitmap so it can able to make possible statistics of those pages - historical analysis i am forwarding previous email with this I request to give me little idea. How people use Xen hypervisor for this task on MATLAB/R language/Other tool On Friday, 2 January 2015 1:15 PM, Minalkumar Patel patel...@yahoo.co.in wrote: My idea is to get dataset of pre-copy at the time of live migration. basically i am planning to write few code into opnesource so i need dataset. actually, from which file/log file i can able to get page modificaiton information. let take scenario, if VM is migrating, then it will check dirty page in each iteration. if found dirty pages, then it would skip those pages and may send them in next round (not current round) once they are non-dirty. so from which file, these information can be possible to collect/gather or where i can modify code to print such output in xc_domain_save. Verbose -vvv utility can't give detail statastic but it gives number of pages dirty/iteration number etc but non the informaiotn page-vise. I get daily message from xen-devel so how to avoid daily messages? Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xenstored crashes with SIGSEGV
Hello, happy new year to everyone. On 19.12.2014 13:36, Philipp Hahn wrote: On 18.12.2014 11:17, Ian Campbell wrote: On Tue, 2014-12-16 at 16:13 +, Frediano Ziglio wrote: Do we have a bug in Xen that affect SSE instructions (possibly already fixed after Philipp version) ? I've had a niggling feeling of Deja Vu over this which I'd been putting down to an old Xen on ARM bug in the area of FPU register switching. But it seems at some point (possibly even still) there was a similar issue with pvops kernels on x86, see: http://bugs.xenproject.org/xen/bug/40 That definitely looks interesting. Philipp, what kernel are you guys using? The crash 2014-12-06 01:26:21 xenstored[4337] happened on linux-3.10.46. I looked through the changes of v3.10.46..v3.10.63 and found the following patches: | fb5b6e7 x86, fpu: shift drop_init_fpu() from save_xstate_sig() to handle_signal() | b888e3d x86, fpu: __restore_xstate_sig()-math_state_restore() needs preempt_disable() They look interesting enough to may have fixed the bug, which could explain the strange bit pattern caused by not restoring the FPU state correctly. Because of that and because of the missing commit d1cc001905146d58c17ac8452eb96f226767819d Author: Silesh C V svella...@mvista.com Date: Wed Jul 23 13:59:59 2014 -0700 coredump: fix the setting of PF_DUMPCORE commit aed8adb7688d5744cb484226820163af31d2499a upstream. we're now working on upgrading the dom0 kernel which should give use usable core dumps again and may also fix the underlying problem. It that bug ever happens again I'll keep you informed. Thanks so far to everybody for the excellent support. Sincerely Philipp Hahn ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dom0 as pvh boot problem
Elena Ufimtseva ufimts...@gmail.com 01/02/15 7:32 PM The last successful command is the reading status register of second IOMMU unit: snip from iommu_enable_translation() in ./xen/drivers/passthrough/vtd/iommu.c 746:sts = dmar_readl(iommu-reg, DMAR_GSTS_REG); 747:dmar_writel(iommu-reg, DMAR_GCMD_REG, sts | DMA_GCMD_TE); /snip After dmar_writel for second iommu the machine hangs. That's rather odd - you say it doesn't even reach the IOMMU_WAIT_OP() right after that? That would suggest a fault or other abnormal condition raised by the translation enabling (i.e. some problem with the page tables, albeit that should then have been a problem for the first IOMMU already). Yet an eventual fault can't be delivered at that point due to interrupts being disabled. Perhaps the VT-d maintainers (now Cc-ed) have some suggestion as to what's going on or how to diagnose. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 33111: regressions - FAIL
flight 33111 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33111/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 7 redhat-installfail REGR. vs. 32598 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 32598 test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail REGR. vs. 32598 test-amd64-i386-rhel6hvm-amd 7 redhat-installfail REGR. vs. 32598 build-i386-libvirt5 libvirt-build fail REGR. vs. 32598 test-amd64-i386-freebsd10-amd64 8 guest-startfail REGR. vs. 32598 test-amd64-amd64-xl-win7-amd64 7 windows-install fail REGR. vs. 32598 test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 32598 test-amd64-i386-freebsd10-i386 8 guest-start fail REGR. vs. 32598 build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32598 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598 test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 32598 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 32598 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 32598 test-amd64-i386-xl-qemuu-win7-amd64 7 windows-installfail REGR. vs. 32598 test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail REGR. vs. 32598 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 32598 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 32598 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 32598 test-amd64-i386-xl-winxpsp3 7 windows-install fail REGR. vs. 32598 test-amd64-i386-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 32598 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32598 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass version targeted for testing: qemuuab0302ee764fd702465aef6d88612cdff4302809 baseline version: qemuu7e58e2ac7778cca3234c33387e49577bb7732714 People who touched revisions under test: Alex Williamson alex.william...@redhat.com Eric Auger eric.au...@linaro.org Fabian Aggeler aggel...@ethz.ch Frank Blaschka blasc...@linux.vnet.ibm.com Greg Bellows greg.bell...@linaro.org Kim Phillips kim.phill...@linaro.org Laszlo Ersek ler...@redhat.com Marcel Apfelbaum marce...@redhat.com Paolo Bonzini pbonz...@redhat.com Peter Maydell peter.mayd...@linaro.org jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
At 19:12 + on 02 Jan (1420222343), Andrew Cooper wrote: supervisor_mode_kernel was an x86_32-only feature which permitted a PV dom0 to run in ring 0, but at the expense of not being able to start any domUs. As the x86_32 Xen build has been removed from tree, removing the remaining supervisor_mode_kernel code. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Reviewed-by: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 33083: regressions - FAIL
On Sun, 2015-01-04 at 09:42 +, xen.org wrote: flight 33083 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33083/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32877 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 32877 build-i386-libvirt5 libvirt-build fail REGR. vs. 32877 1 out of 2 hunks FAILED -- saving rejects to file /tmp/glk81Xud/ssize_t.m4.rej /home/osstest/build.32902.build-amd64-libvirt/gnulib-libvirt/gnulib-tool: *** patch file gnulib/local/m4/ssize_t.m4.diff didn't apply cleanly /home/osstest/build.32902.build-amd64-libvirt/gnulib-libvirt/gnulib-tool: *** Stop. sed: can't read gnulib/tests/gnulib.mk: No such file or directory This seems to be due to a bug in osstest relating to how we handle the .gnulib submodule -- we always take the latest upstream gnulib version instead of following the version encoded into libvirt.git's submodule metadata. In this case libvirt.git currently points to 3914f3153576 which predates the problematic commit (see all the bisect logs) b9bfe78424b8. That commit updates all the copyright years in gnulib which breaks applying the patches which libvirt carries locally (which is why it's important to use the declared version). I'll have to have a think about what change we need to make to osstest here... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/x86: properly retrieve NMI reason
On 19/12/14 16:16, Jan Beulich wrote: Using the native code here can't work properly, as the hypervisor would normally have cleared the two reason bits by the time Dom0 gets to see the NMI (if passed to it at all). There's a shared info field for this, and there's an existing hook to use - just fit the two together. Note that the hook can (and should) be used irrespective of whether being in Dom0, as accessing port 0x61 in a DomU would be even worse, while the shared info field would just hold zero all the time. Signed-off-by: Jan Beulich jbeul...@suse.com This doesn't build. In file included from /local/davidvr/work/k.org/tip/arch/x86/xen/enlighten.c:43:0: /local/davidvr/work/k.org/tip/include/xen/interface/nmi.h:44:1: warning: data definition has no type or storage class [enabled by default] /local/davidvr/work/k.org/tip/include/xen/interface/nmi.h:44:1: error: type defaults to ‘int’ in declaration of ‘DEFINE_XEN_GUEST_HANDLE’ [-Werror=implicit-int] cc1: some warnings being treated as errors David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Gt for beginners
Good morning and happy new year, Currently we have the procedure to install Xen GT on 13.04 or 12.04 ubuntu environment. As such, this procedure makes us import graphics libraries for ubuntu. However, we must do with Tizen and CrossWalk. We miss graphics bookstores. I dont know if anything will be displayed when launching Xen GT on dom0 and vms. If I was not clear, do not hesitate to tell us. Anton Leissenovic Cleman Stephanovic ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] IO-APIC interrupts getting stuck
Roger Pau Monnéroger@citrix.com 12/22/14 7:44 PM
To make sure FreeBSD was not playing tricks behind Xen's back, and
AFAICT FreeBSD is not touching the IO APIC at all. Also Xen doesn't show
any pending EOI timers ('a' debug key).
Btw, as I'm not sure it was said explicitly earlier: Does use of interrupt
remapping matter here?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 33117: regressions - FAIL
flight 33117 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 32648
build-i386-libvirt5 libvirt-build fail REGR. vs. 32648
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32648
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
version targeted for testing:
libvirt 262d913ffc6a20ceafbf4ba2f174854a0a583805
baseline version:
libvirt 2360fe5d24175835d3f5fd1c7e8e6e13addab629
People who touched revisions under test:
Chunyan Liu cy...@suse.com
Jim Fehlig jfeh...@suse.com
Kiarie Kahurani davidkiar...@gmail.com
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt fail
build-armhf-libvirt fail
build-i386-libvirt fail
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt blocked
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt blocked
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
commit 262d913ffc6a20ceafbf4ba2f174854a0a583805
Author: Chunyan Liu cy...@suse.com
Date: Tue Dec 23 14:36:05 2014 +0800
Add tests to xmconfigtest
Add tests to testing HVM default features (pae, acpi, apic)
conversion from xm config to libvirt xml. If no pae|acpi|apic
specified in xm config, after conversion, libvirt xml should
by default include:
features
pae/
apic/
acpi/
/features
Signed-off-by: Chunyan Liu cy...@suse.com
commit 90ed3bd0aac6d29f0c184bd5e168fc9956c04848
Author: Chunyan Liu cy...@suse.com
Date: Tue Dec 23 14:36:04 2014 +0800
xenconfig: set HVM pae/apic/acpi/ default to 1
According to xm.config manual, HVM pae|apic|acpi feature default
is 1 (enabled). But in conversion from xm config to libvirt xml,
if xm config doesn't contain pae|apic|acpi, it sets default value
to 0, this causes some problems in HVM guest.
Update parser codes to set HVM pae|apic|acpi default value to 1
to match xm config convension.
Signed-off-by: Chunyan Liu cy...@suse.com
commit 4f524212ce614e1ca84b34dd8330a48957c8f823
Author: Kiarie Kahurani davidkiar...@gmail.com
Date: Thu Sep 11 07:10:34 2014 +0300
libxl: Add support for parsing/formating Xen XL config
Now that xenconfig supports parsing and formatting Xen's
XL config format, integrate it into the libxl driver's
connectDomainXML{From,To}Native functions.
Signed-off-by: Kiarie Kahurani davidkiar...@gmail.com
Signed-off-by: Jim Fehlig jfeh...@suse.com
commit 6b818d3b09f4e74ac2ea1d4020896be1e6871867
Author: Kiarie Kahurani davidkiar...@gmail.com
Date: Thu Sep 11 07:10:35 2014 +0300
tests: Tests for the xen-xl parser
add tests for the xen_xl config parser
Signed-off-by: Kiarie Kahurani davidkiar...@gmail.com
Signed-off-by: Jim Fehlig jfeh...@suse.com
commit 2c78051a14acfb7aba078d569b1632dfe0ca0853
Author: Kiarie Kahurani davidkiar...@gmail.com
Date: Thu Sep 11 07:10:33 2014 +0300
src/xenconfig: Xen-xl parser
Introduce a Xen xl parser
This parser allows for users to convert the new xl disk format and
spice graphics config to libvirt xml format and vice versa. Regarding
the spice graphics config, the code is pretty much straight forward.
For the disk {formating, parsing}, this parser takes care of the new
xl format which include positional parameters and key/value parameters.
In xl format disk config a diskspec consists of parameters separated
[Xen-devel] [linux-3.10 test] 33108: regressions - FAIL
flight 33108 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33108/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 26303 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 26303 build-i386-libvirt5 libvirt-build fail REGR. vs. 26303 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-i386-xl-win7-amd64 7 windows-install fail like 26261 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 5 xen-boot fail never pass test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: linuxa472efc75989c7092187fe00f0400e02c495c436 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 816 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64
Re: [Xen-devel] [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
On Thu, 2014-12-18 at 11:13 +, David Vrabel wrote: Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make feature-rx-notify mandatory) incorrectly assumed that there were no frontends in use that did not support this feature. But the frontend driver in MiniOS does not and since this is used by (qemu) stubdoms, these stopped working. Netback sort of works as-is in this mode except: - If there are no Rx requests and the internal Rx queue fills, only the drain timeout will wake the thread. The default drain timeout of 10 s would give unacceptable pauses. - If an Rx stall was detected and the internal Rx queue is drained, then the Rx thread would never wake. Handle these two cases (when feature-rx-notify is disabled) by: - Reducing the drain timeout to 30 ms. - Disabling Rx stall detection. Reported-by: John j...@nuclearfallout.net Tested-by: John j...@nuclearfallout.net Signed-off-by: David Vrabel david.vra...@citrix.com FYI I've seen a report[0] that Windows 2012 R2 domu with GPLPV drivers also suffered without feature-rx-notify support in the backend. Ian. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767261#103 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: avoid freeing static 'name' when kasprintf() fails
On 01/05/15 14:19, David Vrabel wrote:
On 05/01/15 13:06, Vitaly Kuznetsov wrote:
In case kasprintf() fails in xen_setup_timer() we assign name to the static
string timer kasprintf failed. We, however, don't check that fact before
issuing kfree() in xen_teardown_timer(), kernel is supposed to crash with
'kernel BUG at mm/slub.c:3341!'
Solve the issue by making name a fixed length string inside struct
xen_clock_event_device. 16 bytes should be enough.
The issue was discovered by Laszlo Ersek.
Add Reported-by: Laszlo ... tag perhaps?
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -391,7 +391,7 @@ static const struct clock_event_device *xen_clockevent =
struct xen_clock_event_device {
struct clock_event_device evt;
-char *name;
+char name[16];
};
static DEFINE_PER_CPU(struct xen_clock_event_device, xen_clock_events) = {
.evt.irq = -1 };
@@ -420,14 +420,11 @@ void xen_teardown_timer(int cpu)
if (evt-irq = 0) {
unbind_from_irqhandler(evt-irq, NULL);
evt-irq = -1;
-kfree(per_cpu(xen_clock_events, cpu).name);
-per_cpu(xen_clock_events, cpu).name = NULL;
}
}
void xen_setup_timer(int cpu)
{
-char *name;
struct clock_event_device *evt;
struct xen_clock_event_device *xevt = ...;
int irq;
@@ -438,21 +435,19 @@ void xen_setup_timer(int cpu)
printk(KERN_INFO installing Xen timer for CPU %d\n, cpu);
-name = kasprintf(GFP_KERNEL, timer%d, cpu);
-if (!name)
-name = timer kasprintf failed;
+snprintf(per_cpu(xen_clock_events, cpu).name, 16, timer%d, cpu);
Use sizeof(xevt-name) here.
Yes, I wanted to recommend sizeof too.
Also the standard Reported-by tag would be nice.
Thanks!
Laszlo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.5] tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ssid_label
libxl_dominfo contains a ssid_label pointer which will have memory allocated
for it in libxl_domain_info() if the hypervisor has CONFIG_XSM compiled.
However, the lack of appropriate use of libxl_dominfo_{init,dispose}() will
cause the label string to be leaked, even in success cases.
This was discovered by XenServers Coverity scanning, and are issues not
identified by upstream Coverity Scan.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Requesting a release-exception as suggested by IanJ. These are memory leaks
which accumulate via the successful completion of libxl library functions (if
XSM is enabled), which will undoubtedly cause issues for the likes of libvirt
and xenopsd-libxl which use libxl in daemon processes.
As we are very close to the release, I have opted for the more
obviously-correct code rather than the pragmatically better code, particularly
in two locations where libxl_domain_info() is called in a loop, and the
dispose()/init() pair is required to prevent leaking the allocation on each
iteration.
All of the uses of libxl_domain_info() patched here could better be an
xc_dominfo_getlist() which reduces the quantity of hypercalls made, and the
amount of data transformation done behind the scenes.
---
tools/libxl/libxl.c | 26 --
tools/libxl/libxl_dom.c | 14 ++
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 50a8928..372dd3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -364,6 +364,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
char *uuid;
const char *vm_name_path;
+libxl_dominfo_init(info);
+
dom_path = libxl__xs_get_dompath(gc, domid);
if (!dom_path) goto x_nomem;
@@ -481,6 +483,7 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
rc = 0;
x_rc:
if (our_trans) xs_transaction_end(ctx-xsh, our_trans, 1);
+libxl_dominfo_dispose(info);
return rc;
x_fail: rc = ERROR_FAIL; goto x_rc;
@@ -4594,6 +4597,8 @@ static int libxl__fill_dom0_memory_info(libxl__gc *gc,
uint32_t *target_memkb,
libxl_ctx *ctx = libxl__gc_owner(gc);
uint32_t free_mem_slack_kb = 0;
+libxl_dominfo_init(info);
+
retry_transaction:
t = xs_transaction_start(ctx-xsh);
@@ -4626,6 +4631,8 @@ retry_transaction:
}
}
+libxl_dominfo_dispose(info);
+libxl_dominfo_init(info);
rc = libxl_domain_info(ctx, info, 0);
if (rc 0)
goto out;
@@ -4664,7 +4671,7 @@ out:
rc = ERROR_FAIL;
}
-
+libxl_dominfo_dispose(info);
return rc;
}
@@ -4999,6 +5006,8 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t
domid, int wait_secs)
uint32_t target_memkb = 0;
libxl_dominfo info;
+libxl_dominfo_init(info);
+
do {
wait_secs--;
sleep(1);
@@ -5007,9 +5016,11 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx,
uint32_t domid, int wait_secs)
if (rc 0)
goto out;
+libxl_dominfo_dispose(info);
+libxl_dominfo_init(info);
rc = libxl_domain_info(ctx, info, domid);
if (rc 0)
-return rc;
+goto out;
} while (wait_secs 0 (info.current_memkb + info.outstanding_memkb)
target_memkb);
if ((info.current_memkb + info.outstanding_memkb) = target_memkb)
@@ -5018,6 +5029,7 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t
domid, int wait_secs)
rc = ERROR_FAIL;
out:
+libxl_dominfo_dispose(info);
return rc;
}
@@ -5435,6 +5447,8 @@ static int libxl__set_vcpuonline_xenstore(libxl__gc *gc,
uint32_t domid,
xs_transaction_t t;
int i, rc = ERROR_FAIL;
+libxl_dominfo_init(info);
+
if (libxl_domain_info(CTX, info, domid) 0) {
LOGE(ERROR, getting domain info list);
goto out;
@@ -5454,6 +5468,7 @@ retry_transaction:
} else
rc = 0;
out:
+libxl_dominfo_dispose(info);
return rc;
}
@@ -5463,8 +5478,11 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc,
uint32_t domid,
libxl_dominfo info;
int i;
+libxl_dominfo_init(info);
+
if (libxl_domain_info(CTX, info, domid) 0) {
LOGE(ERROR, getting domain info list);
+libxl_dominfo_dispose(info);
return ERROR_FAIL;
}
for (i = 0; i = info.vcpu_max_id; i++) {
@@ -5477,6 +5495,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc,
uint32_t domid,
libxl__qmp_cpu_add(gc, domid, i);
}
}
+libxl_dominfo_dispose(info);
return 0;
}
@@ -6569,12 +6588,15 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx,
uint32_t domid,
/* Domain UUID */
{
libxl_dominfo info;
+libxl_dominfo_init(info);
rc =
[Xen-devel] [PATCH OSSTEST] ts-libvirt-build: use Osstest::BuildSupport::submodulefixup
Instead of cloning gnulib manually which can break if upstream gnulib
gets ahead of libvirt.git (which applies patches on the fly etc). By
using submodulefixup we automatically DTRT and use the version of
gnulib specified by the libvirt.git submodule metadata, but with a
runvar override if necessary.
This also removes a whole bunch of faffing in ap-*, cr-daily-branch
and mfi-common to get the version of gnulib to use, which was always a
bit of a wart (ungated for one thing...).
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
ap-common| 3 ---
ap-fetch-version | 4
ap-fetch-version-old | 4
ap-print-url | 3 ---
ap-push | 5 -
cr-daily-branch | 4
mfi-common | 1 -
ts-libvirt-build | 15 ---
8 files changed, 4 insertions(+), 35 deletions(-)
diff --git a/ap-common b/ap-common
index ff50754..96cbd14 100644
--- a/ap-common
+++ b/ap-common
@@ -37,8 +37,6 @@
: ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
: ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
-: ${TREE_GNULIB_LIBVIRT:=$(besteffort_repo git://git.sv.gnu.org/gnulib.git)}
-
: ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
: ${TREEVCS_RUMPUSERXEN:=git}
: ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
@@ -77,7 +75,6 @@ fi
: ${LOCALREV_XEN:=daily-cron.$branch}
: ${LOCALREV_LINUX:=daily-cron.$branch}
: ${LOCALREV_LIBVIRT:=daily-cron.$branch}
-: ${LOCALREV_GNULIB_LIBVIRT:=daily-cron.$branch}
: ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
: ${LOCALREV_SEABIOS:=daily-cron.$branch}
diff --git a/ap-fetch-version b/ap-fetch-version
index 9c189b4..f6c65d8 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -77,10 +77,6 @@ libvirt)
repo_tree_rev_fetch_git libvirt \
$TREE_LIBVIRT master $LOCALREV_LIBVIRT
;;
-gnulib-libvirt)
- repo_tree_rev_fetch_git gnulib-libvirt \
- $TREE_GNULIB_LIBVIRT master $LOCALREV_GNULIB_LIBVIRT
- ;;
rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index f3cf339..43c997c 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -88,10 +88,6 @@ rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$BASE_TREE_RUMPUSERXEN xen-tested-master
$BASE_LOCALREV_RUMPUSERXEN
;;
-gnulib-libvirt)
- # No push gate, same as ap-fetch-version
- ./ap-fetch-version $branch
- ;;
seabios)
repo_tree_rev_fetch_git seabios \
$BASE_TREE_SEABIOS xen-tested-master $BASE_LOCALREV_SEABIOS
diff --git a/ap-print-url b/ap-print-url
index a14d2a6..7b27e1e 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -52,9 +52,6 @@ linuxfirmware)
libvirt)
echo $TREE_LIBVIRT
;;
-gnulib-libvirt)
- echo $TREE_GNULIB_LIBVIRT
- ;;
rumpuserxen)
echo $TREE_RUMPUSERXEN
;;
diff --git a/ap-push b/ap-push
index 9df900a..a2aa747 100755
--- a/ap-push
+++ b/ap-push
@@ -88,11 +88,6 @@ rumpuserxen)
cd $repos/rumpuserxen
git push $TREE_RUMPUSERXEN $revision:xen-tested-master
;;
-gnulib-libvirt)
- # No gate
- echo gnulib-libvirt has not push gate, refusing to push 2
- exit 1
- ;;
seabios)
cd $repos/seabios
git push $TREE_SEABIOS $revision:refs/heads/xen-tested-master
diff --git a/cr-daily-branch b/cr-daily-branch
index 17bb2c9..fc663ce 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -150,10 +150,6 @@ if [ x$REVISION_LIBVIRT = x ]; then
determine_version REVISION_LIBVIRT libvirt LIBVIRT
export REVISION_LIBVIRT
fi
-if [ x$REVISION_GNULIB_LIBVIRT = x ]; then
- determine_version REVISION_GNULIB_LIBVIRT gnulib-libvirt GNULIB_LIBVIRT
- export REVISION_GNULIB_LIBVIRT
-fi
if [ x$REVISION_RUMPUSERXEN = x ]; then
determine_version REVISION_RUMPUSERXEN rumpuserxen RUMPUSERXEN
export REVISION_RUMPUSERXEN
diff --git a/mfi-common b/mfi-common
index 5c4f5d5..e167606 100644
--- a/mfi-common
+++ b/mfi-common
@@ -187,7 +187,6 @@ create_build_jobs () {
host_hostflags=$build_hostflags \
buildjob=${bfi}build-$arch \
tree_libvirt=$TREE_LIBVIRT revision_libvirt=$REVISION_LIBVIRT\
-tree_gnulib_libvirt=$TREE_GNULIB_LIBVIRT
revision_gnulib_libvirt=$REVISION_GNULIB_LIBVIRT\
fi
diff --git a/ts-libvirt-build b/ts-libvirt-build
index 940c034..1e7d0ad 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -25,6 +25,8 @@ tsreadconfig();
selectbuildhost(\@ARGV);
builddirsprops();
+our %submodmap = qw(gnulib gnulib);
+
sub libvirtd_init ();
sub checkout () {
@@ -32,7 +34,7 @@ sub checkout () {
xendist();
build_clone($ho, 'libvirt', $builddir, 'libvirt');
-build_clone($ho,
Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine
FWIW in the future please configure git to chain all your patches to one thread. :-) What I usually do is to git format-patch HEAD~NNN --cover --subject-prefix='PATCH vXX' ... edit -cover-letter.patch ... git send-email --to xen-devel@ --cc XXX All patches will be chained to 00/00 cover letter. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] tools: libxl: code preparation for MBM
On Tue, Dec 23, 2014 at 04:54:38PM +0800, Chao Peng wrote:
[...]
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..f4534ec 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7845,12 +7845,13 @@ out:
}
#ifdef LIBXL_HAVE_PSR_CMT
-static void psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
+static void psr_cmt_print_domain_l3_info(libxl_dominfo *dominfo,
+libxl_psr_cmt_type type,
uint32_t nr_sockets)
Indentation.
{
char *domain_name;
uint32_t socketid;
-uint32_t l3_cache_occupancy;
+uint32_t data;
if (!libxl_psr_cmt_domain_attached(ctx, dominfo-domid))
return;
@@ -7860,15 +7861,21 @@ static void
psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
free(domain_name);
for (socketid = 0; socketid nr_sockets; socketid++) {
-if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo-domid,
- socketid, l3_cache_occupancy) )
-printf(%13u KB, l3_cache_occupancy);
+switch (type) {
+case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
+if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo-domid,
+ socketid, data) )
+printf(%13u KB, data);
+break;
+default:
+return;
+}
}
printf(\n);
}
-static int psr_cmt_show_cache_occupancy(uint32_t domid)
+static int psr_cmt_show_l3_info(libxl_psr_cmt_type type, uint32_t domid)
{
uint32_t i, socketid, nr_sockets, total_rmid;
uint32_t l3_cache_size;
@@ -7904,18 +7911,22 @@ static int psr_cmt_show_cache_occupancy(uint32_t
domid)
printf(%14s %d, Socket, socketid);
printf(\n);
-/* Total L3 cache size */
-printf(%-46s, Total L3 Cache Size);
-for (socketid = 0; socketid nr_sockets; socketid++) {
-rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid, l3_cache_size);
-if (rc 0) {
-fprintf(stderr, Failed to get system l3 cache size for
socket:%d\n,
-socketid);
-return -1;
-}
-printf(%13u KB, l3_cache_size);
+if ( type == LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY ) {
Coding style, no space after ( and before ).
I missed this issue when I reviewed your previous patches. You can fix
this style problem here while you're at it.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] tools: add total/local memory bandwith monitoring
On Tue, Dec 23, 2014 at 04:54:39PM +0800, Chao Peng wrote:
[...]
+static int libxl__psr_cmt_get_mem_bandwidth(libxl__gc *gc, uint32_t domid,
+xc_psr_cmt_type type, uint32_t socketid, uint32_t *bandwidth)
+{
+uint64_t sample1, sample2;
+uint32_t upscaling_factor;
+int rc;
+
+rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+type, socketid, sample1);
+if (rc 0)
+return ERROR_FAIL;
+
+usleep(1);
+
+rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+type, socketid, sample2);
+if (rc 0)
+ return ERROR_FAIL;
+
+if (sample2 sample1) {
+ LOGE(ERROR, event counter overflowed between two samplings);
+ return ERROR_FAIL;
+}
+
What's the likelihood of counter overflows? Can we handle this more
gracefully? Say, retry (with maximum retry cap) when counter overflows?
+rc = xc_psr_cmt_get_l3_upscaling_factor(CTX-xch, upscaling_factor);
+if (rc 0) {
+LOGE(ERROR, failed to get L3 upscaling factor);
+return ERROR_FAIL;
+}
+
+*bandwidth = (sample2 - sample1) * 100 * upscaling_factor / 1024;
+return rc;
+}
+
+int libxl_psr_cmt_get_total_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+uint32_t socketid, uint32_t *bandwidth)
+{
+GC_INIT(ctx);
+int rc;
+
+rc = libxl__psr_cmt_get_mem_bandwidth(gc, domid,
+XC_PSR_CMT_TOTAL_MEM_BANDWIDTH, socketid, bandwidth);
+GC_FREE;
+return rc;
+}
+
+int libxl_psr_cmt_get_local_mem_bandwidth(libxl_ctx *ctx, uint32_t domid,
+uint32_t socketid, uint32_t *bandwidth)
+{
+GC_INIT(ctx);
+int rc;
+
+rc = libxl__psr_cmt_get_mem_bandwidth(gc, domid,
+XC_PSR_CMT_LOCAL_MEM_BANDWIDTH, socketid, bandwidth);
+GC_FREE;
+return rc;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..8029a39 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -693,4 +693,6 @@ libxl_event = Struct(event,[
libxl_psr_cmt_type = Enumeration(psr_cmt_type, [
(1, CACHE_OCCUPANCY),
+(2, TOTAL_MEM_BANDWIDTH),
+(3, LOCAL_MEM_BANDWIDTH),
])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f4534ec..e0435dd 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7867,6 +7867,16 @@ static void psr_cmt_print_domain_l3_info(libxl_dominfo
*dominfo,
socketid, data) )
printf(%13u KB, data);
break;
+case LIBXL_PSR_CMT_TYPE_TOTAL_MEM_BANDWIDTH:
+if ( !libxl_psr_cmt_get_total_mem_bandwidth(ctx, dominfo-domid,
Coding style.
+ socketid, data) )
+printf(%11u KB/s, data);
+break;
+case LIBXL_PSR_CMT_TYPE_LOCAL_MEM_BANDWIDTH:
+if ( !libxl_psr_cmt_get_local_mem_bandwidth(ctx, dominfo-domid,
Ditto.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 0/9] toolstack-based approach to pvhvm guest kexec
Olaf mentioned his concern about handling ballooned pages in 20141211153029.ga1...@aepfle.de. Is that point moot now? Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/5] vTPM: add vTPM device for HVM virtual machine
On Tue, Dec 30, 2014 at 11:45:31PM -0500, Quan Xu wrote:
Signed-off-by: Quan Xu quan...@intel.com
---
tools/libxl/libxl.c | 62
tools/libxl/libxl_create.c | 6 +
tools/libxl/libxl_dm.c | 16
tools/libxl/libxl_internal.h | 3 +++
4 files changed, 87 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 18561fb..656d4b0 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2015,6 +2015,10 @@ void libxl__device_vtpm_add(libxl__egc *egc, uint32_t
domid,
flexarray_append(front, handle);
flexarray_append(front, GCSPRINTF(%d, vtpm-devid));
+/*for para virtual machine*/
Space after /* and before */, and capitalise for.
Please also fix similar issues below.
+flexarray_append(front, domain-type);
+flexarray_append(front, GCSPRINTF(%d, LIBXL_DOMAIN_TYPE_PV));
+
What is this used for?
if (aodev-update_json) {
lock = libxl__lock_domain_userdata(gc, domid);
if (!lock) {
@@ -2073,6 +2077,64 @@ out:
return;
}
+void libxl__device_hvm_vtpm_add(libxl__gc *gc, uint32_t domid,
+libxl_device_vtpm *vtpm)
+{
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+unsigned int rc;
+
+rc = libxl__device_vtpm_setdefault(gc, vtpm);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 16, 1);
+
+if (vtpm-devid == -1) {
+if ((vtpm-devid = libxl__device_nextid(gc, domid, vtpm)) 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+GCNEW(device);
+rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
+if ( rc != 0 ) goto out;
Coding style.
+flexarray_append(back, frontend-id);
+flexarray_append(back, GCSPRINTF(%d, domid));
+flexarray_append(back, online);
+flexarray_append(back, 1);
+flexarray_append(back, state);
+flexarray_append(back, GCSPRINTF(%d, 1));
No need to use GCSPRINT.
+flexarray_append(back, handle);
+flexarray_append(back, GCSPRINTF(%d, vtpm-devid));
+
+flexarray_append(back, uuid);
+flexarray_append(back, GCSPRINTF(LIBXL_UUID_FMT,
LIBXL_UUID_BYTES(vtpm-uuid)));
Line too long.
+flexarray_append(back, resume);
+flexarray_append(back, False);
+
+flexarray_append(front, backend-id);
+flexarray_append(front, GCSPRINTF(%d, vtpm-backend_domid));
+flexarray_append(front, state);
+flexarray_append(front, GCSPRINTF(%d, 1));
+flexarray_append(front, handle);
+flexarray_append(front, GCSPRINTF(%d, vtpm-devid));
+
+flexarray_append(front, domain-type);
+flexarray_append(front, GCSPRINTF(%d, LIBXL_DOMAIN_TYPE_HVM));
+
+libxl__device_generic_add(gc, XBT_NULL, device,
+ libxl__xs_kvs_of_flexarray(gc, back,
back-count),
+ libxl__xs_kvs_of_flexarray(gc, front,
front-count),
+ NULL);
+
+rc = 0;
+out:
+return;
+}
+
There is one major issue with your implementation. You didn't handle
vtpm hot-plug and hot-unplug.
I think what you should do is to refactor libxl__device_vtpm_add to call
the right helpers (say libxl__device_vtpm_add_{pv,hvm}).
With this approach you don't need to worry about all the internal logic
of handling JSON template and locking etc. You might also be able to
nuke b_info-num_vtpms you added in previous patches.
Does this make sense?
libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid,
int *num)
{
GC_INIT(ctx);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c6f68fe..b2f61cb 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -901,6 +901,12 @@ static void initiate_domain_create(libxl__egc *egc,
d_config-nics[i].devid = ++last_devid;
}
+if (d_config-c_info.type == LIBXL_DOMAIN_TYPE_HVM
+d_config-num_vtpms 0) {
+ret = libxl__device_vtpm_setdefault(gc, d_config-vtpms);
+if (ret) goto error_out;
+}
+
if (restore_fd = 0) {
LOG(DEBUG, restoring, not running bootloader);
domcreate_bootloader_done(egc, dcs-bl, 0);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3e191c3..337ac64 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -414,6 +414,7 @@ static char **
libxl__build_device_model_args_new(libxl__gc *gc,
const libxl_device_nic *nics = guest_config-nics;
const int num_disks = guest_config-num_disks;
const int num_nics = guest_config-num_nics;
+const int num_vtpms = guest_config-num_vtpms;
const libxl_vnc_info *vnc = libxl__dm_vnc(guest_config);
const libxl_sdl_info *sdl = dm_sdl(guest_config);
const char *keymap = dm_keymap(guest_config);
@@ -747,6 +748,15 @@ static
Re: [Xen-devel] [PATCH] x86/xen: avoid freeing static 'name' when kasprintf() fails
On 05/01/15 13:06, Vitaly Kuznetsov wrote:
In case kasprintf() fails in xen_setup_timer() we assign name to the static
string timer kasprintf failed. We, however, don't check that fact before
issuing kfree() in xen_teardown_timer(), kernel is supposed to crash with
'kernel BUG at mm/slub.c:3341!'
Solve the issue by making name a fixed length string inside struct
xen_clock_event_device. 16 bytes should be enough.
The issue was discovered by Laszlo Ersek.
Add Reported-by: Laszlo ... tag perhaps?
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -391,7 +391,7 @@ static const struct clock_event_device *xen_clockevent =
struct xen_clock_event_device {
struct clock_event_device evt;
- char *name;
+ char name[16];
};
static DEFINE_PER_CPU(struct xen_clock_event_device, xen_clock_events) = {
.evt.irq = -1 };
@@ -420,14 +420,11 @@ void xen_teardown_timer(int cpu)
if (evt-irq = 0) {
unbind_from_irqhandler(evt-irq, NULL);
evt-irq = -1;
- kfree(per_cpu(xen_clock_events, cpu).name);
- per_cpu(xen_clock_events, cpu).name = NULL;
}
}
void xen_setup_timer(int cpu)
{
- char *name;
struct clock_event_device *evt;
struct xen_clock_event_device *xevt = ...;
int irq;
@@ -438,21 +435,19 @@ void xen_setup_timer(int cpu)
printk(KERN_INFO installing Xen timer for CPU %d\n, cpu);
- name = kasprintf(GFP_KERNEL, timer%d, cpu);
- if (!name)
- name = timer kasprintf failed;
+ snprintf(per_cpu(xen_clock_events, cpu).name, 16, timer%d, cpu);
Use sizeof(xevt-name) here.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine
On Mon, 2015-01-05 at 13:18 +, Wei Liu wrote: FWIW in the future please configure git to chain all your patches to one thread. :-) What I usually do is to git format-patch HEAD~NNN --cover --subject-prefix='PATCH vXX' ... edit -cover-letter.patch ... git send-email --to xen-devel@ --cc XXX All patches will be chained to 00/00 cover letter. FWIW I author 00/NN in my regular MUA then: git format-patch HEAD~NNN --in-reply-to='msg-id-of-00-NN' --subject-prefix='PATCH vXX' But the affect is the same I think. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
On Thu, Dec 18, 2014 at 4:55 AM, Hu, Robert robert...@intel.com wrote: For this specific problem though I think http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html We verified this on RC4, it works. Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with a running guest will not work properly. It looks like IanJ's patch (referenced above) has not been applied. It's clearly a bug fix, so it probably should be... -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dom0 as pvh boot problem
Jan Beulich wrote on 2015-01-05: Elena Ufimtseva ufimts...@gmail.com 01/02/15 7:32 PM The last successful command is the reading status register of second IOMMU unit: snip from iommu_enable_translation() in ./xen/drivers/passthrough/vtd/iommu.c 746:sts = dmar_readl(iommu-reg, DMAR_GSTS_REG); 747: dmar_writel(iommu-reg, DMAR_GCMD_REG, sts | DMA_GCMD_TE); /snip After dmar_writel for second iommu the machine hangs. That's rather odd - you say it doesn't even reach the IOMMU_WAIT_OP() right after that? That would suggest a fault or other abnormal condition raised by the translation enabling (i.e. some problem with the page tables, albeit that should then have been a problem for the first IOMMU already). Yet an eventual fault can't be delivered at that point due to interrupts being disabled. Perhaps the VT-d maintainers (now Cc-ed) have some suggestion as to what's going on or how to diagnose. I am curious why pv dom0 boot fine. Will pvh dom0 share EPT table with VT-d? Maybe try with disable sharing to see whether helps. Jan Best regards, Yang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 0/9] toolstack-based approach to pvhvm guest kexec
Wei Liu wei.l...@citrix.com writes: Olaf mentioned his concern about handling ballooned pages in 20141211153029.ga1...@aepfle.de. Is that point moot now? Well, the limitation is real and some guest-side handling will be required in case we want to support kexec with ballooning. But as David validly mentioned It's the responsibility of the guest to ensure it either doesn't kexec when it is ballooned or that the kexec kernel can handle this. Not sure if we can (and need to) do anything hypevisor- or toolstack-side. Anyway, I have to address Jan's comments to my v5 series and I wanted to play with ballooning a bit before sending v6. This work is pending. -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/xen: avoid freeing static 'name' when kasprintf() fails
In case kasprintf() fails in xen_setup_timer() we assign name to the static
string timer kasprintf failed. We, however, don't check that fact before
issuing kfree() in xen_teardown_timer(), kernel is supposed to crash with
'kernel BUG at mm/slub.c:3341!'
Solve the issue by making name a fixed length string inside struct
xen_clock_event_device. 16 bytes should be enough.
The issue was discovered by Laszlo Ersek.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
arch/x86/xen/time.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..221ebb6 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -391,7 +391,7 @@ static const struct clock_event_device *xen_clockevent =
struct xen_clock_event_device {
struct clock_event_device evt;
- char *name;
+ char name[16];
};
static DEFINE_PER_CPU(struct xen_clock_event_device, xen_clock_events) = {
.evt.irq = -1 };
@@ -420,14 +420,11 @@ void xen_teardown_timer(int cpu)
if (evt-irq = 0) {
unbind_from_irqhandler(evt-irq, NULL);
evt-irq = -1;
- kfree(per_cpu(xen_clock_events, cpu).name);
- per_cpu(xen_clock_events, cpu).name = NULL;
}
}
void xen_setup_timer(int cpu)
{
- char *name;
struct clock_event_device *evt;
int irq;
@@ -438,21 +435,19 @@ void xen_setup_timer(int cpu)
printk(KERN_INFO installing Xen timer for CPU %d\n, cpu);
- name = kasprintf(GFP_KERNEL, timer%d, cpu);
- if (!name)
- name = timer kasprintf failed;
+ snprintf(per_cpu(xen_clock_events, cpu).name, 16, timer%d, cpu);
irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt,
IRQF_PERCPU|IRQF_NOBALANCING|IRQF_TIMER|
IRQF_FORCE_RESUME|IRQF_EARLY_RESUME,
- name, NULL);
+ per_cpu(xen_clock_events, cpu).name,
+ NULL);
(void)xen_set_irq_priority(irq, XEN_IRQ_PRIORITY_MAX);
memcpy(evt, xen_clockevent, sizeof(*evt));
evt-cpumask = cpumask_of(cpu);
evt-irq = irq;
- per_cpu(xen_clock_events, cpu).name = name;
}
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine
On Tue, 2014-12-30 at 23:44 -0500, Quan Xu wrote: Please can you arrange for you patch submissions to be correctly threaded i.e. with all the mails containing a reference header either to the previous patch or to the 0/N introductory patch. Take a look at the --chainreplyto and --thread options to git send-email. If you use --dry-run then you should see each mail has a suitable References: header if you have got it right. Without this I end up with N+1 unrelated email in my INBOX which are very hard to keep straight as a series once people start commenting on a subset. Thanks, Ian. This patch series are only the Xen part to enable stubdom vTPM for HVM virtual machine. it will work w/ Qemu patch series and seaBios patch series. Change QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the Qemu/SeaBios patch series are merged. *INTRODUCTION* The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to interact with a TPM in a virtual machine the same way they interact with a TPM on the physical system. Each virtual machine gets its own unique, emulated, software TPM. Each major component of vTPM is implemented as a stubdom, providing secure separation guaranteed by the hypervisor. The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed from mini-os TPM backend driver. *ARCHITECTURE* The architecture of stubdom vTPM for HVM virtual machine: ++ | Windows/Linux DomU | ... || ^| |v || | Qemu tpm1.2 Tis | || ^| |v || | XenStubdoms backend| ++ | ^ v | ++ | XenDevOps | ++ | ^ v | ++ | mini-os/tpmback | || ^| |v || | vtpm-stubdom | ... || ^| |v || | mini-os/tpmfront | ++ | ^ v | ++ | mini-os/tpmback | || ^| |v || | vtpmmgr-stubdom | || ^| |v || | mini-os/tpm_tis | ++ | ^ v | ++ |Hardware TPM| ++ * Windows/Linux DomU: The HVM based guest that wants to use a vTPM. There may be more than one of these. * Qemu tpm1.2 Tis: Implementation of the tpm1.2 Tis interface for HVM virtual machines. It is Qemu emulation device. * vTPM xenstubdoms driver: Qemu vTPM driver. This driver provides vtpm initialization and sending data and commends to a para-virtualized vtpm stubdom. * XenDevOps: Register Xen stubdom vTPM frontend driver, and transfer any request/repond between TPM xenstubdoms driver and Xen vTPM stubdom. Facilitate communications between Xen vTPM stubdom and vTPM xenstubdoms driver. * mini-os/tpmback: Mini-os TPM backend driver. The Linux frontend driver connects to this backend driver to facilitate communications between the Linux DomU and its vTPM. This driver is also used by vtpmmgr stubdom to communicate with vtpm-stubdom. * vtpm-stubdom: A mini-os stub domain that implements a vTPM. There is a one to one mapping between running vtpm-stubdom instances and logical vtpms on the system. The vTPM Platform Configuration Registers (PCRs) are all initialized to zero. * mini-os/tpmfront: Mini-os TPM frontend driver. The vTPM mini-os domain vtpm stubdom uses this driver to communicate with vtpmmgr-stubdom. This driver could also be used separately to implement a mini-os domain that wishes to use a vTPM of its own. * vtpmmgr-stubdom: A mini-os domain that implements the vTPM manager. There is only one vTPM manager and it should be running during the entire lifetime of the machine. vtpmmgr domain securely stores encryption keys for each of the vtpms and accesses to the hardware TPM to get the root of trust for the entire system. *
[Xen-devel] [xen-unstable test] 33112: regressions - FAIL
flight 33112 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33112/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32877 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 32877 build-i386-libvirt5 libvirt-build fail REGR. vs. 32877 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33083 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 36174af3fbeb1b662c0eadbfa193e77f68cc955b baseline version: xen 36174af3fbeb1b662c0eadbfa193e77f68cc955b jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail
Re: [Xen-devel] [PATCH for-4.5] tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ssid_label
On Mon, Jan 05, 2015 at 02:19:58PM +, Andrew Cooper wrote:
libxl_dominfo contains a ssid_label pointer which will have memory allocated
for it in libxl_domain_info() if the hypervisor has CONFIG_XSM compiled.
However, the lack of appropriate use of libxl_dominfo_{init,dispose}() will
cause the label string to be leaked, even in success cases.
This was discovered by XenServers Coverity scanning, and are issues not
identified by upstream Coverity Scan.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
Reviewed-by : Wei Liu wei.l...@citrix.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Requesting a release-exception as suggested by IanJ. These are memory leaks
which accumulate via the successful completion of libxl library functions (if
XSM is enabled), which will undoubtedly cause issues for the likes of libvirt
and xenopsd-libxl which use libxl in daemon processes.
As we are very close to the release, I have opted for the more
obviously-correct code rather than the pragmatically better code, particularly
in two locations where libxl_domain_info() is called in a loop, and the
dispose()/init() pair is required to prevent leaking the allocation on each
iteration.
All of the uses of libxl_domain_info() patched here could better be an
xc_dominfo_getlist() which reduces the quantity of hypercalls made, and the
amount of data transformation done behind the scenes.
---
tools/libxl/libxl.c | 26 --
tools/libxl/libxl_dom.c | 14 ++
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 50a8928..372dd3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -364,6 +364,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
(This function is really convoluted. :-/)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5 v2] libxl: Initialise CTX-xce in domain suspend
On Mon, 2015-01-05 at 14:35 +, Ian Jackson wrote: Yang Hongyang writes ([PATCH] xl/libxl: fix migrate/Remus regression (core dumped)): When excuting xl migrate/Remus, the following error occurd: [root@master xen]# xl migrate 5 slaver migration target: Ready to receive domain. Saving to migration stream new xl format (info 0x1/0x0/1225) Loading new save file incoming migration stream (new xl fmt info 0x1/0x0/1225) Savefile contains xl domain config in JSON format Parsing config from saved Segmentation fault (core dumped) This is because CTX-xce is used without been initialized. The bug was introduced by commit 2ffeb5d7f5d8 libxl: events: Deregister evtchn fd when not needed which remove the initialization of xce from libxl__ctx_alloc. This patch initialze the CTX-xce before use it. Thanks. This patch goes in the right direction, but isn't quite correct because it doesn't check the return value from libxl__ctx_evtchn_init. Looking at this it is clear that following the on-demand initialisation of CTX-xce, it is normally necessary for any evtchn user in libxl to call libxl__ctx_evtchn_init, since they will need the xce for finding the right port number to pass to libxl__ev_evtchn_wait. Sorry for not noticing this when I made my earlier change. I have therefore: * In the patch below, added changes to the comments to document this. * Done git grep '\bxce\b' tools/libxl and checked the other uses. * Consequently, verified that the rest of the code in libxl_dom.c avoids using xce unless guest_evtchn.port=0, and properly initialises .port to -1, so that there is no need for further calls to libxl__ctx_evtchn_init. I have compiled but not executed this patch. Yang Hongyang: can you please test that it fixes the bug for you ? Konrad: this should go in 4.5 because it is a bugfix without which libxl may dereference NULL. (I have also somewhat improved the English grammar in the commit message.) Thanks, Ian. commit 9d1cb27f5e961fd9db1c7d8381af18e33510f924 Author: Ian Jackson ian.jack...@eu.citrix.com Date: Mon Jan 5 14:31:00 2015 + libxl: Initialise CTX-xce in domain suspend, as needed When excuting xl migrate/Remus, the following error can occur: [root@master xen]# xl migrate 5 slaver migration target: Ready to receive domain. Saving to migration stream new xl format (info 0x1/0x0/1225) Loading new save file incoming migration stream (new xl fmt info 0x1/0x0/12\ ) Savefile contains xl domain config in JSON format Parsing config from saved Segmentation fault (core dumped) This is because CTX-xce is used without been initialized. The bug was introduced by commit 2ffeb5d7f5d8 libxl: events: Deregister evtchn fd when not needed which removed the initialization of xce from libxl__ctx_alloc. In this patch we initialise the CTX-xce before using it. Also, we adjust the doc comment for libxl__ev_evtchn_* to mention the need to do so. Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2] ts-libvirt-build: use Osstest::BuildSupport::submodulefixup
Instead of cloning gnulib manually which can break if upstream gnulib
gets ahead of libvirt.git (which applies patches on the fly etc). By
using submodulefixup we automatically DTRT and use the version of
gnulib specified by the libvirt.git submodule metadata, but with a
runvar override if necessary.
This also removes a whole bunch of faffing in ap-*, cr-daily-branch
and mfi-common to get the version of gnulib to use, which was always a
bit of a wart (ungated for one thing...).
We continue to use --no-git and GNULIB_SRCDIR because otherwise
autogen.sh (via bootstrap) will force its own version, overwriting
what submodulefixup has done. For this we need a way to get the hash
representing the module, so introduce submodule_find (and rework
submodule_have in terms of it).
Tested in standalone mode with build-amd64-libvirt and
build-amd64-rumpuserxen (because I touched submodule_have, AFAICT the
bodges were not run). The libvirt build was tested both with the
automatic revisions and with:
revision_libvirt=2360fe5d24175835d3f5fd1c7e8e6e13addab629
revision_libvirt_gnulib=16518d9ed8f25d3e53931dd1aa343072933e4604
(used in successful libvirt flight 32648), in both cases confirming
that the build used the desired versions.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: Honour revision_libvirt_gnulib.
---
Osstest/BuildSupport.pm | 13 ++---
ap-common | 3 ---
ap-fetch-version| 4
ap-fetch-version-old| 4
ap-print-url| 3 ---
ap-push | 5 -
cr-daily-branch | 4
mfi-common | 1 -
ts-libvirt-build| 20 +++-
9 files changed, 21 insertions(+), 36 deletions(-)
diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index 874e27e..c323162 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -43,7 +43,7 @@ BEGIN {
xendist
$xendist
- submodulefixup submodule_have
+ submodulefixup submodule_have submodule_find
);
%EXPORT_TAGS = ( );
@@ -145,9 +145,16 @@ sub submodulefixup () {
return \@submodules;
}
-sub submodule_have ($$) {
+sub submodule_find ($$) {
my ($submodules, $ourname) = @_;
-return !!grep { $_-{OurName} eq $ourname } @$submodules;
+my @submods = grep { $_-{OurName} eq $ourname } @$submodules;
+return undef unless @submods;
+die more than one $ourname? if @submods ne 1;
+return $submods[0];
+}
+
+sub submodule_have ($$) {
+return defined(submodule_find);
}
1;
diff --git a/ap-common b/ap-common
index ff50754..96cbd14 100644
--- a/ap-common
+++ b/ap-common
@@ -37,8 +37,6 @@
: ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
: ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
-: ${TREE_GNULIB_LIBVIRT:=$(besteffort_repo git://git.sv.gnu.org/gnulib.git)}
-
: ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
: ${TREEVCS_RUMPUSERXEN:=git}
: ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
@@ -77,7 +75,6 @@ fi
: ${LOCALREV_XEN:=daily-cron.$branch}
: ${LOCALREV_LINUX:=daily-cron.$branch}
: ${LOCALREV_LIBVIRT:=daily-cron.$branch}
-: ${LOCALREV_GNULIB_LIBVIRT:=daily-cron.$branch}
: ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
: ${LOCALREV_SEABIOS:=daily-cron.$branch}
diff --git a/ap-fetch-version b/ap-fetch-version
index 9c189b4..f6c65d8 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -77,10 +77,6 @@ libvirt)
repo_tree_rev_fetch_git libvirt \
$TREE_LIBVIRT master $LOCALREV_LIBVIRT
;;
-gnulib-libvirt)
- repo_tree_rev_fetch_git gnulib-libvirt \
- $TREE_GNULIB_LIBVIRT master $LOCALREV_GNULIB_LIBVIRT
- ;;
rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index f3cf339..43c997c 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -88,10 +88,6 @@ rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$BASE_TREE_RUMPUSERXEN xen-tested-master
$BASE_LOCALREV_RUMPUSERXEN
;;
-gnulib-libvirt)
- # No push gate, same as ap-fetch-version
- ./ap-fetch-version $branch
- ;;
seabios)
repo_tree_rev_fetch_git seabios \
$BASE_TREE_SEABIOS xen-tested-master $BASE_LOCALREV_SEABIOS
diff --git a/ap-print-url b/ap-print-url
index a14d2a6..7b27e1e 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -52,9 +52,6 @@ linuxfirmware)
libvirt)
echo $TREE_LIBVIRT
;;
-gnulib-libvirt)
- echo $TREE_GNULIB_LIBVIRT
- ;;
rumpuserxen)
echo $TREE_RUMPUSERXEN
;;
diff --git a/ap-push b/ap-push
index 9df900a..a2aa747 100755
--- a/ap-push
+++ b/ap-push
@@ -88,11 +88,6 @@ rumpuserxen)
cd $repos/rumpuserxen
git push $TREE_RUMPUSERXEN
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On Mon, 2015-01-05 at 16:07 +, Andrew Cooper wrote: What usecase was supervisor_mode_kernel developed for? It seems counter-intuitive, but I can't find anything in the history explaining its use. It was a prototype from the pre-pvops days to see if it would be feasible to have a single kernel binary which ran either on Xen or on a stub hypervisor which ran it as native with little or no loss of performance^TM (e.g. for distro's convenience to avoid the multiple kernel issue). It never went beyond a prototype with Xen proper instead of the proposed stub hypervisor and then pvops came along and was a much more sensible idea... Considering the implications of running dom0 in ring0, pvops seems like a much more sensible idea. It wouldn't have been a dom0, it would have just been a native system which happened to use some Xen interfaces, the intention was never to be able to run guests or anything, just to allow distros to only support one binary. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in consider_modules
On Mon, Dec 22, 2014 at 11:54:01AM +0100, Julien Grall wrote: Hi Ian, On 21/12/2014 12:18, Ian Campbell wrote: By iterating up to = mi-nr_mods we are running off the end of the boot modules, but more importantly it causes us to then skip the first FDT reserved region, meaning we might clobber it. Oops. Good catch! OOI, how did you find it? Signed-off-by: Ian Campbell i...@hellion.org.uk Reviewed-by: Julien Grall julien.gr...@linaro.org --- For 4.5: I think this bug fix should go in, it fixes a real issue and is low risk. Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Agreed. I'll also add to my list of things to consider for backport to 4.4. Ditto. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5] libxl: Fix if{} nesting in do_pci_remove
On Mon, Jan 05, 2015 at 04:34:36PM +, Ian Jackson wrote:
From: Ian Jackson i...@mariner.uk.xensource.com
do_pci_remove contained this:
if (type == LIBXL_DOMAIN_TYPE_HVM) {
[stuff]
} else if (type != LIBXL_DOMAIN_TYPE_PV)
abort();
{
This is bizarre, and not correct. The effect is that HVM guests end
up running both the proper code and that intended for PV guests. This
causes (amongst other things) trouble when PCI devices are
hot-unplugged from HVM guests.
This bug was introduced in abfb006f tools/libxl: explicitly grant
access to needed I/O-memory ranges.
This is clear candidate for Xen 4.5, being a bugfix to an important
feature.
Reported-by: Boris Ostrovsky boris.ostrov...@oracle.com
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Tested-by: Robert Hu robert...@intel.com
CC: Konrad Wilk konrad.w...@oracle.com
RElease-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: Sander Eikelenboom li...@eikelenboom.it
CC: George Dunlap george.dun...@eu.citrix.com
---
tools/libxl/libxl_pci.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 316643c..9ae37fa 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1247,9 +1247,9 @@ static int do_pci_remove(libxl__gc *gc, uint32_t domid,
rc = ERROR_FAIL;
goto out_fail;
}
-} else if (type != LIBXL_DOMAIN_TYPE_PV)
-abort();
-{
+} else {
+assert(type == LIBXL_DOMAIN_TYPE_PV);
+
char *sysfs_path = libxl__sprintf(gc,
SYSFS_PCI_DEV/PCI_BDF/resource, pcidev-domain,
pcidev-bus, pcidev-dev,
pcidev-func);
FILE *f = fopen(sysfs_path, r);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
On Mon, Jan 05, 2015 at 04:28:02PM +, Dugger, Donald D wrote: Working to resolve this issue, I hope to have a definitive answer by the end of this week. OK, so past Xen 4.5 release. thanks! -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Monday, January 5, 2015 9:27 AM To: Jan Beulich Cc: xen-devel; Zhang, Yang Z; Tian, Kevin; Dugger, Donald D Subject: Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround On Fri, Dec 19, 2014 at 08:31:51AM +, Jan Beulich wrote: The endless story continues. Intel maintainers, are you folks OK with these patches? From my perspective: Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com 1: make XSA-59 workaround fully cover XeonE5/E7 v2 2: extend XSA-59 workaround to XeonE5 v3 (Haswell) Signed-off-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5] libxl: Fix if{} nesting in do_pci_remove [and 1 more messages]
Acked-by: Ian Campbell ian.campb...@citrix.com RElease-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Pushed, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
On Fri, Dec 19, 2014 at 08:31:51AM +, Jan Beulich wrote: The endless story continues. Intel maintainers, are you folks OK with these patches? From my perspective: Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com 1: make XSA-59 workaround fully cover XeonE5/E7 v2 2: extend XSA-59 workaround to XeonE5 v3 (Haswell) Signed-off-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
Working to resolve this issue, I hope to have a definitive answer by the end of this week. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Monday, January 5, 2015 9:27 AM To: Jan Beulich Cc: xen-devel; Zhang, Yang Z; Tian, Kevin; Dugger, Donald D Subject: Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround On Fri, Dec 19, 2014 at 08:31:51AM +, Jan Beulich wrote: The endless story continues. Intel maintainers, are you folks OK with these patches? From my perspective: Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com 1: make XSA-59 workaround fully cover XeonE5/E7 v2 2: extend XSA-59 workaround to XeonE5 v3 (Haswell) Signed-off-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5 v2] libxl: Initialise CTX-xce in domain suspend [and 2 more messages]
Ian Jackson writes (Re: [PATCH for-4.5 v2] libxl: Initialise CTX-xce in domain suspend): Konrad: this should go in 4.5 because it is a bugfix without which libxl may dereference NULL. ... Ian Campbell writes (Re: [PATCH for-4.5 v2] libxl: Initialise CTX-xce in domain suspend): Acked-by: Ian Campbell ian.campb...@citrix.com Konrad Rzeszutek Wilk writes (Re: [PATCH for-4.5 v2] libxl: Initialise CTX-xce in domain suspend): OK. Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Applied, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RMRR Fix Design for Xen
On Fri, Dec 19, 2014 at 1:21 AM, Tiejun Chen tiejun.c...@intel.com wrote: RMRR Fix Design for Xen This design is a goal to fix RMRR for Xen. It includes four sectors as follows: * Background * What is RMRR * Current RMRR Issues * Design Overview We hope this can help us to understand current problem then figure out a clean and better solution everyone can agree now to go forward. Background == We first identified this RMRR defect when trying to pass-through IGD device, which can be simply fixed by adding an identity mapping in case of shared EPT table. However along with the community discussion, it boiled down to a more general RMRR problem, i.e. the identity mapping is brute-added in hypervisor, w/o considering whether conflicting with an existing guest PFN ranges. As a general solution we need invent a new mechanism so reserved ranges allocated by hypervisor can be exported to the user space toolstack and hvmloader, so conflict can be detected when constructing guest PFN layout, with best-effort avoidance policies to further help. What is RMRR RMRR is a acronym for Reserved Memory Region Reporting. BIOS may report each such reserved memory region through the RMRR structures, along with the devices that requires access to the specified reserved memory region. Reserved memory ranges that are either not DMA targets, or memory ranges that may be target of BIOS initiated DMA only during pre-boot phase (such as from a boot disk drive) must not be included in the reserved memory region reporting. The base address of each RMRR region must be 4KB aligned and the size must be an integer multiple of 4KB. BIOS must report the RMRR reported memory addresses as reserved in the system memory map returned through methods suchas INT15, EFI GetMemoryMap etc. The reserved memory region reporting structures are optional. If there are no RMRR structures, the system software concludes that the platform does not have any reserved memory ranges that are DMA targets. The RMRR regions are expected to be used for legacy usages (such as USB, UMA Graphics, etc.) requiring reserved memory. Platform designers shouldavoid or limit use of reserved memory regions since these require system software to create holes in the DMA virtual address range available to system software and its drivers. The following is grabbed from my BDW: (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:679: RMRR region: base_addr ab80a000 end_address ab81dfff (XEN) [VT-D]dmar.c:834: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:679: RMRR region: base_addr ad00 end_address af7f Here USB occupies 0xab80a000:0xab81dfff, IGD owns 0xad00:0xaf7f. Note there are zero or more Reserved Memory Region Reporting (RMRR) in one given platform. And multiple devices may share one RMRR range. Additionally RMRR can go anyplace. Tiejun, Thanks for this document -- such a document is really helpful in figuring out the best way to architect the solution to a problem. I hope you don't mind me asking a few additional questions here. You've said that: * RMRR is a range used by devices (typically legacy devices such as USB, but apparently also newer devices like IGD) * RMRR ranges are reported by BIOSes * RMRR ranges should be avoided by the guest. I'm still missing a few things, however. * In the case of passing through a virtual device, how does the range apply wrt gpfn space and mfn space? I assume in example above, the range [ab80a000,ab81dfff] corresponds to an mfn range. When passing through this device to the guest, do pfns [ab80a000,ab81dfff] need to be mapped to the same mfn range (i.e., 1-1 mapping), or can they be mapped from somewhere else in pfn space? * You've described the range, but later on you talk about Xen creating RMRR mappings. What does this mean? Are there registers that need to be written? Do the ept / IOMMU tables need some kind of special flags? Thanks, -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Writable page tables questions
On 04/01/2015 17:17, Junji Zhi wrote: Hi, I'm Junji, a newbie in Xen and hoping I can contribute to the community one day. I have a few questions regarding the writable page tables, while reading The Definitive Guide to the Xen Hypervisor by David Chisnall: 1. Writable page tables is one Xen memory assist technique, applied to paravirtualized guests ONLY. HVM does not apply. Correct? 2. According to the book, when a guest wants to modify its page table, it triggers a trap into the hypervisor and it does a few steps: (1) it invalidates a PTE that points to the page containing the page table. Is my understanding correct? Q: What does invalidate really mean here? Does it mean simply flipping a bit in the PTE of the page table, or removing the PTE completely? Does it also need to invalidate the TLB entry? (2) then the control goes back to the guest and it can write/read the page table now. (3) The book's words pasted: When an address referenced by the newly invalidated page directory entry is referenced (read or write), a page fault occurs. Q: The description of step (3) is confusing. What does it mean by an address referenced by the newly invalidated page directory entry is referenced? Does it mean the case when the guest code is accessing an virtual address that needs to search the invalidated page table for translation? I do not have the Chisnall book to hand at the moment, so cannot comment as to the exact text in it. However, looking at the code as it exists today, XENFEAT_writable_page_tables (there is a typo in the ABI) is strictly only offered to HVM guests, and not to PV guests. PV guests must, under all circumstances, have their pagetables reachable from any cr3 read-only. Any ability to write to an active pagetable without an audit from Xen would be a security issue, as a guest could give itself access to frames which belonged to Xen or other guests. Updating an individual PTE can be done by either writing directly to it, in which case Xen will trap, emulate and audit the attempt, or use an appropriate hypercall, which will be more efficient as no emulation is required. A PV guest is required to perform its own TLB management when necessary (again, hypercall or trap and emulate). Updating pagetables in general can either be done by updating each PTE individually, or by constructing a new pagetable from scratch, pinning it (via hypercall), which performs all the auditing at once, then introducing it into the active set of pagetables. An example might be: 1) Write all 512 entries into a regular page 2) Unmap the page (taking its refcount to 0, to permit a typechange) 3) Pinning the page as a specific type of pagetable (each level of pagetables have a different type, for refcounting purposes) 4) PTE write or hypercall to introduce this new pagetable into the active set. The important points are that nothing can ever be changed in the active set of pagetables without an audit by Xen, but the cost of the audit can be amortised by constructing pagetables separately in a regular page first. I hope this helps to clarify the situation. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 04/23] x86/VPMU: Set MSR bitmaps only for HVM/PVH guests
In preparation for making VPMU code shared with PV make sure that we we update
MSR bitmaps only for HVM/PVH guests
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/svm/vpmu.c | 21 +
xen/arch/x86/hvm/vmx/vpmu_core2.c | 8 +---
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 4c448bb..19777e3 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -244,7 +244,8 @@ static int amd_vpmu_save(struct vcpu *v)
context_save(v);
-if ( !vpmu_is_set(vpmu, VPMU_RUNNING) ctx-msr_bitmap_set )
+if ( !vpmu_is_set(vpmu, VPMU_RUNNING)
+ has_hvm_container_vcpu(v) ctx-msr_bitmap_set )
amd_vpmu_unset_msr_bitmap(v);
return 1;
@@ -287,8 +288,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
ASSERT(!supported);
/* For all counters, enable guest only mode for HVM guest */
-if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL)
-!(is_guest_mode(msr_content)) )
+if ( has_hvm_container_vcpu(v)
+ (get_pmu_reg_type(msr) == MSR_TYPE_CTRL)
+ !is_guest_mode(msr_content) )
{
set_guest_mode(msr_content);
}
@@ -303,8 +305,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR;
-if ( !((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
-amd_vpmu_set_msr_bitmap(v);
+if ( has_hvm_container_vcpu(v)
+ !((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
+ amd_vpmu_set_msr_bitmap(v);
}
/* stop saving restore if guest stops first counter */
@@ -314,8 +317,9 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
vpmu_reset(vpmu, VPMU_RUNNING);
-if ( ((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
-amd_vpmu_unset_msr_bitmap(v);
+if ( has_hvm_container_vcpu(v)
+ ((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
+ amd_vpmu_unset_msr_bitmap(v);
release_pmu_ownship(PMU_OWNER_HVM);
}
@@ -403,7 +407,8 @@ static void amd_vpmu_destroy(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-if ( ((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
+if ( has_hvm_container_vcpu(v)
+ ((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
amd_vpmu_unset_msr_bitmap(v);
xfree(vpmu-context);
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 590c2a9..c9fb202 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -335,7 +335,8 @@ static int core2_vpmu_save(struct vcpu *v)
__core2_vpmu_save(v);
/* Unset PMU MSR bitmap to trap lazy load. */
-if ( !vpmu_is_set(vpmu, VPMU_RUNNING) cpu_has_vmx_msr_bitmap )
+if ( !vpmu_is_set(vpmu, VPMU_RUNNING)
+ has_hvm_container_vcpu(v) cpu_has_vmx_msr_bitmap )
core2_vpmu_unset_msr_bitmap(v-arch.hvm_vmx.msr_bitmap);
return 1;
@@ -448,7 +449,8 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int
*type, int *index)
{
__core2_vpmu_load(current);
vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
-if ( cpu_has_vmx_msr_bitmap )
+if ( has_hvm_container_vcpu(current)
+ cpu_has_vmx_msr_bitmap )
core2_vpmu_set_msr_bitmap(current-arch.hvm_vmx.msr_bitmap);
}
return 1;
@@ -820,7 +822,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
xfree(core2_vpmu_cxt-pmu_enable);
xfree(vpmu-context);
-if ( cpu_has_vmx_msr_bitmap )
+if ( has_hvm_container_vcpu(v) cpu_has_vmx_msr_bitmap )
core2_vpmu_unset_msr_bitmap(v-arch.hvm_vmx.msr_bitmap);
release_pmu_ownship(PMU_OWNER_HVM);
vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 19/23] x86/VPMU: Handle PMU interrupts for PV guests
Add support for handling PMU interrupts for PV guests.
VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hypervisor.
Since the interrupt handler may now force VPMU context save (i.e. set
VPMU_CONTEXT_SAVE flag) we need to make changes to amd_vpmu_save() which
until now expected this flag to be set only when the counters were stopped.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
Acked-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/svm/vpmu.c | 11 +-
xen/arch/x86/hvm/vpmu.c | 208 --
xen/include/public/arch-x86/pmu.h | 6 ++
xen/include/public/pmu.h | 2 +
xen/include/xsm/dummy.h | 4 +-
xen/xsm/flask/hooks.c | 2 +
6 files changed, 213 insertions(+), 20 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 27c8a9c..68113c7 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -225,17 +225,12 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
struct vcpu *v;
unsigned int i;
-/*
- * Stop the counters. If we came here via vpmu_save_force (i.e.
- * when VPMU_CONTEXT_SAVE is set) counters are already stopped.
- */
+for ( i = 0; i num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
{
vpmu_set(vpmu, VPMU_FROZEN);
-
-for ( i = 0; i num_counters; i++ )
-wrmsrl(ctrls[i], 0);
-
return 0;
}
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 800d98c..c57b250 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -80,27 +80,52 @@ static void __init parse_vpmu_param(char *s)
void vpmu_lvtpc_update(uint32_t val)
{
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
+struct vcpu *curr = current;
+struct vpmu_struct *vpmu = vcpu_vpmu(curr);
vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR | (val APIC_LVT_MASKED);
-apic_write(APIC_LVTPC, vpmu-hw_lapic_lvtpc);
+
+/* Postpone APIC updates for PV(H) guests if PMU interrupt is pending */
+if ( is_hvm_vcpu(curr) || !vpmu-xenpmu_data ||
+ !(vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
+apic_write(APIC_LVTPC, vpmu-hw_lapic_lvtpc);
}
int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
{
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
+struct vcpu *curr = current;
+struct vpmu_struct *vpmu;
if ( !(vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
return 0;
+vpmu = vcpu_vpmu(curr);
if ( vpmu-arch_vpmu_ops vpmu-arch_vpmu_ops-do_wrmsr )
-return vpmu-arch_vpmu_ops-do_wrmsr(msr, msr_content, supported);
+{
+int ret = vpmu-arch_vpmu_ops-do_wrmsr(msr, msr_content, supported);
+
+/*
+ * We may have received a PMU interrupt during WRMSR handling
+ * and since do_wrmsr may load VPMU context we should save
+ * (and unload) it again.
+ */
+if ( !is_hvm_vcpu(curr) vpmu-xenpmu_data
+ (vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
+{
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+vpmu-arch_vpmu_ops-arch_vpmu_save(vpmu);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+}
+return ret;
+}
+
return 0;
}
int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
{
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
+struct vcpu *curr = current;
+struct vpmu_struct *vpmu;
if ( !(vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
{
@@ -108,24 +133,161 @@ int vpmu_do_rdmsr(unsigned int msr, uint64_t
*msr_content)
return 0;
}
+vpmu = vcpu_vpmu(curr);
if ( vpmu-arch_vpmu_ops vpmu-arch_vpmu_ops-do_rdmsr )
-return vpmu-arch_vpmu_ops-do_rdmsr(msr, msr_content);
+{
+int ret = vpmu-arch_vpmu_ops-do_rdmsr(msr, msr_content);
+
+if ( !is_hvm_vcpu(curr) vpmu-xenpmu_data
+ (vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
+{
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+vpmu-arch_vpmu_ops-arch_vpmu_save(vpmu);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+}
+return ret;
+}
else
*msr_content = 0;
return 0;
}
+static struct vcpu *choose_hwdom_vcpu(void)
+{
+unsigned idx = smp_processor_id() % hardware_domain-max_vcpus;
+
+if ( hardware_domain-vcpu == NULL )
+return NULL;
+
+return hardware_domain-vcpu[idx];
+}
+
void vpmu_do_interrupt(struct cpu_user_regs *regs)
{
-struct vcpu *v
[Xen-devel] [PATCH v17 13/23] x86/VPMU: Interface for setting PMU mode and flags
Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF: PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
can profile itself and the hypervisor.
Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.
For feature flags only Intel's BTS is currently supported.
Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
tools/flask/policy/policy/modules/xen/xen.te | 3 +
xen/arch/x86/domain.c| 6 +-
xen/arch/x86/hvm/svm/vpmu.c | 25 +++-
xen/arch/x86/hvm/vmx/vmcs.c | 7 +-
xen/arch/x86/hvm/vmx/vpmu_core2.c| 27 +++-
xen/arch/x86/hvm/vpmu.c | 210 ++-
xen/arch/x86/oprofile/nmi_int.c | 3 +-
xen/arch/x86/x86_64/compat/entry.S | 4 +
xen/arch/x86/x86_64/entry.S | 4 +
xen/include/asm-x86/hvm/vmx/vmcs.h | 7 +-
xen/include/asm-x86/hvm/vpmu.h | 33 +++--
xen/include/public/pmu.h | 45 ++
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 4 +
xen/include/xlat.lst | 1 +
xen/include/xsm/dummy.h | 15 ++
xen/include/xsm/xsm.h| 6 +
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c| 18 +++
xen/xsm/flask/policy/access_vectors | 2 +
20 files changed, 390 insertions(+), 32 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te
b/tools/flask/policy/policy/modules/xen/xen.te
index c0128aa..870ff81 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -68,6 +68,9 @@ allow dom0_t xen_t:xen2 {
resource_op
psr_cmt_op
};
+allow dom0_t xen_t:xen2 {
+pmu_ctrl
+};
allow dom0_t xen_t:mmu memorymap;
# Allow dom0 to use these domctls on itself. For domctls acting on other
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 4e45fa8..d00622d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1544,7 +1544,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
if ( is_hvm_vcpu(prev) )
{
if (prev != next)
-vpmu_save(vcpu_vpmu(prev));
+vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
if ( !list_empty(prev-arch.hvm_vcpu.tm_list) )
pt_save_timer(prev);
@@ -1587,9 +1587,9 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
!is_hardware_domain(next-domain));
}
-if (is_hvm_vcpu(next) (prev != next) )
+if ( is_hvm_vcpu(next) (prev != next) )
/* Must be done with interrupts enabled */
-vpmu_load(vcpu_vpmu(next));
+vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
context_saved(prev);
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 72e2561..2cfdf08 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
return 1;
}
+static void amd_vpmu_unload(struct vpmu_struct *vpmu)
+{
+struct vcpu *v;
+
+if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_FROZEN) )
+{
+unsigned int i;
+
+for ( i = 0; i num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+context_save(vpmu);
+}
+
+v = vpmu_vcpu(vpmu);
+if ( has_hvm_container_vcpu(v) is_msr_bitmap_on(vpmu) )
+amd_vpmu_unset_msr_bitmap(v);
+
+vpmu_reset(vpmu, VPMU_FROZEN);
+}
+
static void context_update(unsigned int msr, u64 msr_content)
{
unsigned int i;
@@ -471,17 +491,18 @@ struct arch_vpmu_ops amd_vpmu_ops = {
.arch_vpmu_destroy = amd_vpmu_destroy,
.arch_vpmu_save = amd_vpmu_save,
.arch_vpmu_load = amd_vpmu_load,
+.arch_vpmu_unload = amd_vpmu_unload,
.arch_vpmu_dump = amd_vpmu_dump
};
-int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int svm_vpmu_initialise(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
uint8_t family = current_cpu_data.x86;
int ret = 0;
/* vpmu enabled? */
-if ( !vpmu_flags )
+if ( vpmu_mode == XENPMU_MODE_OFF )
return 0;
switch ( family )
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index b9e3ef8..f45ce93 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
[Xen-devel] [PATCH v17 05/23] x86/VPMU: Make vpmu macros a bit more efficient
Introduce vpmu_are_all_set that allows testing multiple bits at once. Convert
macros
into inlines for better compiler checking.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/vmx/vpmu_core2.c | 5 +
xen/arch/x86/hvm/vpmu.c | 3 +--
xen/include/asm-x86/hvm/vpmu.h| 25 +
3 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index c9fb202..951aece 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -326,10 +326,7 @@ static int core2_vpmu_save(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
-return 0;
-
-if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
+if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
return 0;
__core2_vpmu_save(v);
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index e17e194..63b2158 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -143,8 +143,7 @@ void vpmu_save(struct vcpu *v)
struct vpmu_struct *vpmu = vcpu_vpmu(v);
int pcpu = smp_processor_id();
-if ( !(vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED)
- vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)) )
+if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_ALLOCATED | VPMU_CONTEXT_LOADED)
)
return;
vpmu-last_pcpu = pcpu;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 1f28bd8..ddc2748 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -82,10 +82,27 @@ struct vpmu_struct {
#define VPMU_CPU_HAS_BTS0x200 /* Has Branch Trace Store */
-#define vpmu_set(_vpmu, _x)((_vpmu)-flags |= (_x))
-#define vpmu_reset(_vpmu, _x) ((_vpmu)-flags = ~(_x))
-#define vpmu_is_set(_vpmu, _x) ((_vpmu)-flags (_x))
-#define vpmu_clear(_vpmu) ((_vpmu)-flags = 0)
+static inline void vpmu_set(struct vpmu_struct *vpmu, const u32 mask)
+{
+vpmu-flags |= mask;
+}
+static inline void vpmu_reset(struct vpmu_struct *vpmu, const u32 mask)
+{
+vpmu-flags = ~mask;
+}
+static inline void vpmu_clear(struct vpmu_struct *vpmu)
+{
+vpmu-flags = 0;
+}
+static inline bool_t vpmu_is_set(const struct vpmu_struct *vpmu, const u32
mask)
+{
+return !!(vpmu-flags mask);
+}
+static inline bool_t vpmu_are_all_set(const struct vpmu_struct *vpmu,
+ const u32 mask)
+{
+return !!((vpmu-flags mask) == mask);
+}
int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 10/23] x86/VPMU: Add public xenpmu.h
Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.
Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets to them.
While making these updates, also:
* Remove unused vpmu_domain() macro from vpmu.h
* Convert msraddr_to_bitpos() into an inline and make it a little faster by
realizing that all Intel's PMU-related MSRs are in the lower MSR range.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Acked-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/svm/vpmu.c | 83 +++--
xen/arch/x86/hvm/vmx/vpmu_core2.c| 123 +--
xen/arch/x86/hvm/vpmu.c | 10 +++
xen/arch/x86/oprofile/op_model_ppro.c| 6 +-
xen/include/Makefile | 3 +-
xen/include/asm-x86/hvm/vmx/vpmu_core2.h | 32
xen/include/asm-x86/hvm/vpmu.h | 16 ++--
xen/include/public/arch-arm.h| 3 +
xen/include/public/arch-x86/pmu.h| 91 +++
xen/include/public/pmu.h | 38 ++
xen/include/xlat.lst | 4 +
11 files changed, 275 insertions(+), 134 deletions(-)
delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
create mode 100644 xen/include/public/arch-x86/pmu.h
create mode 100644 xen/include/public/pmu.h
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 64dc167..545962d 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -30,10 +30,7 @@
#include asm/apic.h
#include asm/hvm/vlapic.h
#include asm/hvm/vpmu.h
-
-#define F10H_NUM_COUNTERS 4
-#define F15H_NUM_COUNTERS 6
-#define MAX_NUM_COUNTERS F15H_NUM_COUNTERS
+#include public/pmu.h
#define MSR_F10H_EVNTSEL_GO_SHIFT 40
#define MSR_F10H_EVNTSEL_EN_SHIFT 22
@@ -49,6 +46,9 @@ static const u32 __read_mostly *counters;
static const u32 __read_mostly *ctrls;
static bool_t __read_mostly k7_counters_mirrored;
+#define F10H_NUM_COUNTERS 4
+#define F15H_NUM_COUNTERS 6
+
/* PMU Counter MSRs. */
static const u32 AMD_F10H_COUNTERS[] = {
MSR_K7_PERFCTR0,
@@ -83,12 +83,14 @@ static const u32 AMD_F15H_CTRLS[] = {
MSR_AMD_FAM15H_EVNTSEL5
};
-/* storage for context switching */
-struct amd_vpmu_context {
-u64 counters[MAX_NUM_COUNTERS];
-u64 ctrls[MAX_NUM_COUNTERS];
-bool_t msr_bitmap_set;
-};
+/* Use private context as a flag for MSR bitmap */
+#define msr_bitmap_on(vpmu)do {\
+ (vpmu)-priv_context = (void *)-1L; \
+ } while (0)
+#define msr_bitmap_off(vpmu) do {\
+ (vpmu)-priv_context = NULL;\
+ } while (0)
+#define is_msr_bitmap_on(vpmu) ((vpmu)-priv_context != NULL)
static inline int get_pmu_reg_type(u32 addr)
{
@@ -142,7 +144,6 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
{
unsigned int i;
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu-context;
for ( i = 0; i num_counters; i++ )
{
@@ -150,14 +151,13 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_WRITE);
}
-ctxt-msr_bitmap_set = 1;
+msr_bitmap_on(vpmu);
}
static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
{
unsigned int i;
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu-context;
for ( i = 0; i num_counters; i++ )
{
@@ -165,7 +165,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_RW);
}
-ctxt-msr_bitmap_set = 0;
+msr_bitmap_off(vpmu);
}
static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
@@ -177,19 +177,22 @@ static inline void context_load(struct vcpu *v)
{
unsigned int i;
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu-context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu-context;
+uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
for ( i = 0; i num_counters; i++ )
{
-wrmsrl(counters[i], ctxt-counters[i]);
-wrmsrl(ctrls[i], ctxt-ctrls[i]);
+wrmsrl(counters[i], counter_regs[i]);
+wrmsrl(ctrls[i], ctrl_regs[i]);
}
}
static void amd_vpmu_load(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu-context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu-context;
+uint64_t
[Xen-devel] [PATCH v17 14/23] x86/VPMU: Initialize VPMUs with __initcall
Move some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/svm/vpmu.c | 112
xen/arch/x86/hvm/vmx/vpmu_core2.c | 151 +++---
xen/arch/x86/hvm/vpmu.c | 36 +
xen/include/asm-x86/hvm/vpmu.h| 2 +
4 files changed, 161 insertions(+), 140 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 2cfdf08..03474a3 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -375,57 +375,6 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t
*msr_content)
return 1;
}
-static int amd_vpmu_initialise(struct vcpu *v)
-{
-struct xen_pmu_amd_ctxt *ctxt;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-
-if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
-return 0;
-
-if ( counters == NULL )
-{
- switch ( family )
-{
-case 0x15:
-num_counters = F15H_NUM_COUNTERS;
-counters = AMD_F15H_COUNTERS;
-ctrls = AMD_F15H_CTRLS;
-k7_counters_mirrored = 1;
-break;
-case 0x10:
-case 0x12:
-case 0x14:
-case 0x16:
-default:
-num_counters = F10H_NUM_COUNTERS;
-counters = AMD_F10H_COUNTERS;
-ctrls = AMD_F10H_CTRLS;
-k7_counters_mirrored = 0;
-break;
-}
-}
-
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
- 2 * sizeof(uint64_t) * num_counters);
-if ( !ctxt )
-{
-gdprintk(XENLOG_WARNING, Insufficient memory for PMU,
- PMU feature is unavailable on domain %d vcpu %d.\n,
-v-vcpu_id, v-domain-domain_id);
-return -ENOMEM;
-}
-
-ctxt-counters = sizeof(*ctxt);
-ctxt-ctrls = ctxt-counters + sizeof(uint64_t) * num_counters;
-
-vpmu-context = ctxt;
-vpmu-priv_context = NULL;
-vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
-return 0;
-}
-
static void amd_vpmu_destroy(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -497,30 +446,63 @@ struct arch_vpmu_ops amd_vpmu_ops = {
int svm_vpmu_initialise(struct vcpu *v)
{
+struct xen_pmu_amd_ctxt *ctxt;
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-int ret = 0;
-/* vpmu enabled? */
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
return 0;
-switch ( family )
+if ( !counters )
+return -EINVAL;
+
+ctxt = xzalloc_bytes(sizeof(*ctxt) +
+ 2 * sizeof(uint64_t) * num_counters);
+if ( !ctxt )
+{
+printk(XENLOG_G_WARNING Insufficient memory for PMU,
+PMU feature is unavailable on domain %d vcpu %d.\n,
+ v-vcpu_id, v-domain-domain_id);
+return -ENOMEM;
+}
+
+ctxt-counters = sizeof(*ctxt);
+ctxt-ctrls = ctxt-counters + sizeof(uint64_t) * num_counters;
+
+vpmu-context = ctxt;
+vpmu-priv_context = NULL;
+
+vpmu-arch_vpmu_ops = amd_vpmu_ops;
+
+vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
+switch ( current_cpu_data.x86 )
{
+case 0x15:
+num_counters = F15H_NUM_COUNTERS;
+counters = AMD_F15H_COUNTERS;
+ctrls = AMD_F15H_CTRLS;
+k7_counters_mirrored = 1;
+break;
case 0x10:
case 0x12:
case 0x14:
-case 0x15:
case 0x16:
-ret = amd_vpmu_initialise(v);
-if ( !ret )
-vpmu-arch_vpmu_ops = amd_vpmu_ops;
-return ret;
+num_counters = F10H_NUM_COUNTERS;
+counters = AMD_F10H_COUNTERS;
+ctrls = AMD_F10H_CTRLS;
+k7_counters_mirrored = 0;
+break;
+default:
+printk(XENLOG_WARNING VPMU: Unsupported CPU family %#x\n,
+ current_cpu_data.x86);
+return -EINVAL;
}
-printk(VPMU: Initialization failed.
- AMD processor family %d has not
- been supported\n, family);
-return -EINVAL;
+return 0;
}
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 4d08d1b..6c78323 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -724,62 +724,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs
*regs)
return 1;
}
-static int core2_vpmu_initialise(struct vcpu *v)
-{
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-u64 msr_content;
-static bool_t ds_warned;
-
-if ( !(vpmu_features XENPMU_FEATURE_INTEL_BTS) )
-goto func_out;
-/* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21]
[Xen-devel] [PATCH v17 11/23] x86/VPMU: Make vpmu not HVM-specific
vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Kevin Tian kevin.t...@intel.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/include/asm-x86/domain.h | 2 ++
xen/include/asm-x86/hvm/vcpu.h | 3 ---
xen/include/asm-x86/hvm/vpmu.h | 5 ++---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 6a77a93..be4d1dc 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -426,6 +426,8 @@ struct arch_vcpu
void (*ctxt_switch_from) (struct vcpu *);
void (*ctxt_switch_to) (struct vcpu *);
+struct vpmu_struct vpmu;
+
/* Virtual Machine Extensions */
union {
struct pv_vcpu pv_vcpu;
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 01e0665..71a5b15 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -151,9 +151,6 @@ struct hvm_vcpu {
u32 msr_tsc_aux;
u64 msr_tsc_adjust;
-/* VPMU */
-struct vpmu_struct vpmu;
-
union {
struct arch_vmx_struct vmx;
struct arch_svm_struct svm;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 83eea7e..82bfa0e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -31,9 +31,8 @@
#define VPMU_BOOT_ENABLED 0x1/* vpmu generally enabled. */
#define VPMU_BOOT_BTS 0x2/* Intel BTS feature wanted. */
-#define vcpu_vpmu(vcpu) (((vcpu)-arch.hvm_vcpu.vpmu))
-#define vpmu_vcpu(vpmu) (container_of((vpmu), struct vcpu, \
- arch.hvm_vcpu.vpmu))
+#define vcpu_vpmu(vcpu) ((vcpu)-arch.vpmu)
+#define vpmu_vcpu(vpmu) container_of((vpmu), struct vcpu, arch.vpmu)
#define MSR_TYPE_COUNTER0
#define MSR_TYPE_CTRL 1
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 07/23] vmx: Merge MSR management routines
vmx_add_host_load_msr() and vmx_add_guest_msr() share fair amount of code. Merge
them to simplify code maintenance.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/vmx/vmcs.c| 84 +++---
xen/include/asm-x86/hvm/vmx/vmcs.h | 16 +++-
2 files changed, 55 insertions(+), 45 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 9d8033e..b9e3ef8 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1201,64 +1201,62 @@ int vmx_write_guest_msr(u32 msr, u64 val)
return -ESRCH;
}
-int vmx_add_guest_msr(u32 msr)
+int vmx_add_msr(u32 msr, int type)
{
struct vcpu *curr = current;
-unsigned int i, msr_count = curr-arch.hvm_vmx.msr_count;
-struct vmx_msr_entry *msr_area = curr-arch.hvm_vmx.msr_area;
+unsigned int idx, *msr_count;
+struct vmx_msr_entry **msr_area, *msr_area_elem;
+
+if ( type == VMX_GUEST_MSR )
+{
+msr_count = curr-arch.hvm_vmx.msr_count;
+msr_area = curr-arch.hvm_vmx.msr_area;
+}
+else
+{
+ASSERT(type == VMX_HOST_MSR);
+msr_count = curr-arch.hvm_vmx.host_msr_count;
+msr_area = curr-arch.hvm_vmx.host_msr_area;
+}
-if ( msr_area == NULL )
+if ( *msr_area == NULL )
{
-if ( (msr_area = alloc_xenheap_page()) == NULL )
+if ( (*msr_area = alloc_xenheap_page()) == NULL )
return -ENOMEM;
-curr-arch.hvm_vmx.msr_area = msr_area;
-__vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(msr_area));
-__vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+
+if ( type == VMX_GUEST_MSR )
+{
+__vmwrite(VM_EXIT_MSR_STORE_ADDR, virt_to_maddr(*msr_area));
+__vmwrite(VM_ENTRY_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
+}
+else
+__vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(*msr_area));
}
-for ( i = 0; i msr_count; i++ )
-if ( msr_area[i].index == msr )
+for ( idx = 0; idx *msr_count; idx++ )
+if ( (*msr_area)[idx].index == msr )
return 0;
-if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
+if ( *msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
return -ENOSPC;
-msr_area[msr_count].index = msr;
-msr_area[msr_count].mbz = 0;
-msr_area[msr_count].data = 0;
-curr-arch.hvm_vmx.msr_count = ++msr_count;
-__vmwrite(VM_EXIT_MSR_STORE_COUNT, msr_count);
-__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, msr_count);
+msr_area_elem = *msr_area + *msr_count;
+msr_area_elem-index = msr;
+msr_area_elem-mbz = 0;
-return 0;
-}
+++*msr_count;
-int vmx_add_host_load_msr(u32 msr)
-{
-struct vcpu *curr = current;
-unsigned int i, msr_count = curr-arch.hvm_vmx.host_msr_count;
-struct vmx_msr_entry *msr_area = curr-arch.hvm_vmx.host_msr_area;
-
-if ( msr_area == NULL )
+if ( type == VMX_GUEST_MSR )
{
-if ( (msr_area = alloc_xenheap_page()) == NULL )
-return -ENOMEM;
-curr-arch.hvm_vmx.host_msr_area = msr_area;
-__vmwrite(VM_EXIT_MSR_LOAD_ADDR, virt_to_maddr(msr_area));
+msr_area_elem-data = 0;
+__vmwrite(VM_EXIT_MSR_STORE_COUNT, *msr_count);
+__vmwrite(VM_ENTRY_MSR_LOAD_COUNT, *msr_count);
+}
+else
+{
+rdmsrl(msr, msr_area_elem-data);
+__vmwrite(VM_EXIT_MSR_LOAD_COUNT, *msr_count);
}
-
-for ( i = 0; i msr_count; i++ )
-if ( msr_area[i].index == msr )
-return 0;
-
-if ( msr_count == (PAGE_SIZE / sizeof(struct vmx_msr_entry)) )
-return -ENOSPC;
-
-msr_area[msr_count].index = msr;
-msr_area[msr_count].mbz = 0;
-rdmsrl(msr, msr_area[msr_count].data);
-curr-arch.hvm_vmx.host_msr_count = ++msr_count;
-__vmwrite(VM_EXIT_MSR_LOAD_COUNT, msr_count);
return 0;
}
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 6a99dca..949884b 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -482,12 +482,15 @@ extern const unsigned int
vmx_introspection_force_enabled_msrs_size;
#define MSR_TYPE_R 1
#define MSR_TYPE_W 2
+
+#define VMX_GUEST_MSR 0
+#define VMX_HOST_MSR 1
+
void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
int vmx_read_guest_msr(u32 msr, u64 *val);
int vmx_write_guest_msr(u32 msr, u64 val);
-int vmx_add_guest_msr(u32 msr);
-int vmx_add_host_load_msr(u32 msr);
+int vmx_add_msr(u32 msr, int type);
void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
void vmx_set_eoi_exit_bitmap(struct vcpu *v,
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On 05/01/2015 19:56, Andy Lutomirski wrote: 1) State: all pvtis marked as PVCLOCK_TSC_STABLE_BIT. 1) Update request for all vcpus, for a TSC_STABLE_BIT - ~TSC_STABLE_BIT transition. 2) vCPU-1 updates its pvti with new values. 3) vCPU-0 still has not updated its pvti with new values. 4) vCPU-1 VM-enters, uses vCPU-0 values, even though it has been notified of a TSC_STABLE_BIT - ~TSC_STABLE_BIT transition. The update is not actually atomic across all vCPUs, its atomic in the sense of not allowing visibility of distinct system_timestamp/tsc_timestamp values. Hmm. In step 4, is there a guarantee that vCPU-0 won't VM-enter until it gets marked unstable? Otherwise the vdso could could just as easily be called from vCPU-1, migrated to vCPU-0, read the data complete with stale stable bit, and get migrated back to vCPU-1. But I thought that KVM currently froze all vCPUs when updating pvti for any of them. How can this happen? I admit I don't really understand the update request code. That was also my understanding. I thought this was the point of kvm_make_mclock_inprogress_request/KVM_REQ_MCLOCK_INPROGRESS. Disabling TSC_STABLE_BIT is triggered by pvclock_gtod_update_fn but it happens in kvm_gen_update_masterclock, and no guest entries will happen in the meanwhile. Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 22/23] x86/VPMU: NMI-based VPMU support
Add support for using NMIs as PMU interrupts to allow profiling hypervisor
when interrupts are disabled.
Most of processing is still performed by vpmu_do_interrupt(). However, since
certain operations are not NMI-safe we defer them to a softint that
vpmu_do_interrupt()
will schedule:
* For PV guests that would be send_guest_vcpu_virq()
* For HVM guests it's VLAPIC accesses and hvm_get_segment_register() (the later
can be called in privileged profiling mode when the interrupted guest is an HVM
one).
With send_guest_vcpu_virq() and hvm_get_segment_register() for PV(H) and vlapic
accesses for HVM moved to sofint, the only routines/macros that
vpmu_do_interrupt()
calls in NMI mode are:
* memcpy()
* querying domain type (is_XX_domain())
* guest_cpu_user_regs()
* XLAT_cpu_user_regs()
* raise_softirq()
* vcpu_vpmu()
* vpmu_ops-arch_vpmu_save()
* vpmu_ops-do_interrupt()
The latter two only access PMU MSRs with {rd,wr}msrl() (not the _safe versions
which would not be NMI-safe).
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
docs/misc/xen-command-line.markdown | 8 +-
xen/arch/x86/hvm/svm/vpmu.c | 3 +-
xen/arch/x86/hvm/vmx/vpmu_core2.c | 3 +-
xen/arch/x86/hvm/vpmu.c | 226
xen/include/asm-x86/hvm/vpmu.h | 4 +-
xen/include/asm-x86/softirq.h | 3 +-
6 files changed, 192 insertions(+), 55 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 152ae03..f3d64c7 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1314,11 +1314,11 @@ Use Virtual Processor ID support if available. This
prevents the need for TLB
flushes on VM entry and exit, increasing performance.
### vpmu
- `= ( bts )`
+ `= ( [nmi,][bts] )`
Default: `off`
-Switch on the virtualized performance monitoring unit for HVM guests.
+Switch on the virtualized performance monitoring unit.
If the current cpu isn't supported a message like
'VPMU: Initialization failed. ...'
@@ -1330,6 +1330,10 @@ wrong behaviour (see handle\_pmc\_quirk()).
If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
feature is switched on on Intel processors supporting this feature.
+If 'vpmu=nmi' is specified the PMU interrupt will cause an NMI instead of a
+regular vector interrupt (which is the default). This can be useful for
sampling
+hypervisor code that is executed with interrupts disabled.
+
*Warning:*
As the BTS virtualisation is not 100% safe and because of the nehalem quirk
don't use the vpmu flag on production systems with Intel cpus!
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 68113c7..7ddce33 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -168,7 +168,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
msr_bitmap_off(vpmu);
}
-static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int amd_vpmu_do_interrupt(const struct cpu_user_regs *regs)
{
return 1;
}
@@ -220,6 +220,7 @@ static inline void context_save(struct vpmu_struct *vpmu)
rdmsrl(counters[i], counter_regs[i]);
}
+/* Must be NMI-safe */
static int amd_vpmu_save(struct vpmu_struct *vpmu)
{
struct vcpu *v;
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 8067d83..0c7fd74 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -305,6 +305,7 @@ static inline void __core2_vpmu_save(struct vpmu_struct
*vpmu)
rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt-global_status);
}
+/* Must be NMI-safe */
static int core2_vpmu_save(struct vpmu_struct *vpmu)
{
struct vcpu *v = vpmu_vcpu(vpmu);
@@ -720,7 +721,7 @@ static void core2_vpmu_dump(const struct vcpu *v)
}
}
-static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
+static int core2_vpmu_do_interrupt(const struct cpu_user_regs *regs)
{
struct vcpu *v = current;
u64 msr_content;
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index ebab0f5..2ba0feb 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -34,6 +34,7 @@
#include asm/hvm/svm/svm.h
#include asm/hvm/svm/vmcb.h
#include asm/apic.h
+#include asm/nmi.h
#include public/pmu.h
#include xsm/xsm.h
@@ -54,36 +55,54 @@ unsigned int __read_mostly vpmu_features = 0;
static void parse_vpmu_param(char *s);
custom_param(vpmu, parse_vpmu_param);
+static void pmu_softnmi(void);
+
static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
+static DEFINE_PER_CPU(struct vcpu *, sampled_vcpu);
+
+static uint32_t __read_mostly vpmu_interrupt_type = PMU_APIC_VECTOR;
static void __init parse_vpmu_param(char *s)
{
-switch ( parse_bool(s) )
-{
-case 0:
-break;
-
[Xen-devel] [PATCH v17 01/23] common/symbols: Export hypervisor symbols to privileged guest
Export Xen's symbols as {addresstypename} triplet via new XENPF_get_symbol
hypercall
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/platform_hypercall.c | 28 +++
xen/common/symbols.c| 54 +
xen/include/public/platform.h | 19 +
xen/include/xen/symbols.h | 3 +++
xen/include/xlat.lst| 1 +
xen/xsm/flask/hooks.c | 4 +++
xen/xsm/flask/policy/access_vectors | 2 ++
7 files changed, 111 insertions(+)
diff --git a/xen/arch/x86/platform_hypercall.c
b/xen/arch/x86/platform_hypercall.c
index 32f39b2..7b37960 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -23,6 +23,7 @@
#include xen/cpu.h
#include xen/pmstat.h
#include xen/irq.h
+#include xen/symbols.h
#include asm/current.h
#include public/platform.h
#include acpi/cpufreq/processor_perf.h
@@ -760,6 +761,33 @@ ret_t
do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
}
break;
+case XENPF_get_symbol:
+{
+static char name[KSYM_NAME_LEN + 1]; /* protected by xenpf_lock */
+XEN_GUEST_HANDLE(char) nameh;
+uint32_t namelen, copylen;
+
+guest_from_compat_handle(nameh, op-u.symdata.name);
+
+ret = xensyms_read(op-u.symdata.symnum, op-u.symdata.type,
+ op-u.symdata.address, name);
+
+namelen = strlen(name) + 1;
+
+if ( namelen op-u.symdata.namelen )
+copylen = op-u.symdata.namelen;
+else
+copylen = namelen;
+
+op-u.symdata.namelen = namelen;
+
+if ( !ret copy_to_guest(nameh, name, copylen) )
+ret = -EFAULT;
+if ( !ret __copy_field_to_guest(u_xenpf_op, op, u.symdata) )
+ret = -EFAULT;
+}
+break;
+
default:
ret = -ENOSYS;
break;
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index bc2fde6..2c0942d 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,8 @@
#include xen/lib.h
#include xen/string.h
#include xen/spinlock.h
+#include public/platform.h
+#include xen/guest_access.h
#ifdef SYMBOLS_ORIGIN
extern const unsigned int symbols_offsets[1];
@@ -148,3 +150,55 @@ const char *symbols_lookup(unsigned long addr,
*offset = addr - symbols_address(low);
return namebuf;
}
+
+/*
+ * Get symbol type information. This is encoded as a single char at the
+ * beginning of the symbol name.
+ */
+static char symbols_get_symbol_type(unsigned int off)
+{
+/*
+ * Get just the first code, look it up in the token table,
+ * and return the first char from this token.
+ */
+return symbols_token_table[symbols_token_index[symbols_names[off + 1]]];
+}
+
+int xensyms_read(uint32_t *symnum, char *type,
+ uint64_t *address, char *name)
+{
+/*
+ * Symbols are most likely accessed sequentially so we remember position
+ * from previous read. This can help us avoid the extra call to
+ * get_symbol_offset().
+ */
+static uint64_t next_symbol, next_offset;
+static DEFINE_SPINLOCK(symbols_mutex);
+
+if ( *symnum symbols_num_syms )
+return -ERANGE;
+if ( *symnum == symbols_num_syms )
+{
+/* No more symbols */
+name[0] = '\0';
+return 0;
+}
+
+spin_lock(symbols_mutex);
+
+if ( *symnum == 0 )
+next_offset = next_symbol = 0;
+if ( next_symbol != *symnum )
+/* Non-sequential access */
+next_offset = get_symbol_offset(*symnum);
+
+*type = symbols_get_symbol_type(next_offset);
+next_offset = symbols_expand_symbol(next_offset, name);
+*address = symbols_offsets[*symnum] + SYMBOLS_ORIGIN;
+
+next_symbol = ++*symnum;
+
+spin_unlock(symbols_mutex);
+
+return 0;
+}
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 5c57615..6dd7732 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -560,6 +560,24 @@ struct xenpf_resource_op {
typedef struct xenpf_resource_op xenpf_resource_op_t;
DEFINE_XEN_GUEST_HANDLE(xenpf_resource_op_t);
+#define XENPF_get_symbol 62
+struct xenpf_symdata {
+/* IN/OUT variables */
+uint32_t namelen; /* IN: size of name buffer */
+ /* OUT: strlen(name) of hypervisor symbol (may be */
+ /* larger than what's been copied to guest) */
+uint32_t symnum; /* IN: Symbol to read*/
+ /* OUT: Next available symbol. If same as IN then */
+ /* we reached the end*/
+
+/* OUT variables */
+
[Xen-devel] [PATCH v17 00/23] x86/PMU: Xen PMU PV(H) support
Version 17 of PV(H) PMU patches. Changes in v17: * Disable VPMU when unknown CPU vendor is detected (patch #2) * Remove unnecessary vendor tests in vendor-specific init routines (patch #14) * Remember first CPU that starts mode change and use it to stop the cycle (patch #13) * If vpmu ops is not present, return 0 as value for VPMU MSR read (as opposed to returning an error as was the case in previous patch.) (patch #18) * Change slightly vpmu_do_msr() logic as result of this chage (patch #20) * stringify VPMU version (patch #14) * Use 'CS 1' to mark sample as PMU_SAMPLE_USER (patch #19) Changes in v16: * Many changes in VPMU mode patch (#13): * Replaced arguments to some vpmu routines (vcpu - vpmu). New patch (#12) * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear MSR bitmaps). This routine may be called in context switch (vpmu_switch_to()). * Added vmx_write_guest_msr_vcpu() interface to write MSRs of non-current VCPU * Use cpumask_cycle instead of cpumask_next * Dropped timeout error * Adjusted types of mode variables * Don't allow oprofile to allocate its context on MSR access if VPMU context has already been allocated (which may happen when VMPU mode was set to off while the guest was running) * vpmu_initialise() no longer turns off VPMU globally on failure. New patch (#2) * vpmu_do_msr() will return 1 (failure) if vpmu_ops are not set. This is done to prevent PV guests that are not VPMU-enabled from wrongly assuming that they have access to counters (Linux check_hw_exists() will make this assumption) (patch #18) * Add cpl field to shared structure that will be passed for HVM guests' samples (instead of PMU_SAMPLE_USER flag). Add PMU_SAMPLE_PV flag to mark whose sample is passed up. (Patches ## 10, 19, 22) Changes in v15: * Rewrote vpmu_force_context_switch() to use continue_hypercall_on_cpu() * Added vpmu_init initcall that will call vendor-specific init routines * Added a lock to vpmu_struct to serialize pmu_init()/pmu_finish() * Use SS instead of CS for DPL (instead of RPL) * Don't take lock for XENPMU_mode_get * Make vmpu_mode/features an unsigned int (from uint64_t) * Adjusted pvh_hypercall64_table[] order * Replaced address range check [XEN_VIRT_START..XEN_VIRT_END] with guest_mode() * A few style cleanups Changes in v14: * Moved struct xen_pmu_regs to pmu.h * Moved CHECK_pmu_* to an earlier patch (when structures are first introduced) * Added PMU_SAMPLE_REAL flag to indicate whether the sample was taken in real mode * Simplified slightly setting rules for xenpmu_data flags * Rewrote vpmu_force_context_switch() to again use continuations. (Returning EAGAIN to user would mean that VPMU mode may get into inconsistent state (across processors) and dealing with that is more compicated than I'd like). * Fixed msraddr_to_bitpos() and converted it into an inline * Replaced address range check in vmpu_do_interrupt() with guest_mode() * No error returns from __initcall * Rebased on top of recent VPMU changes * Various cleanups Changes in v13: * Rearranged data in xenpf_symdata to eliminate a hole (no change in structure size) * Removed unnecessary zeroing of last character in name string during symbol read hypercall * Updated comment in access_vectors for pmu_use operation * Compute AMD MSR bank size at runtime * Moved a couple of BUILD_BUG_ON later, to when the structures they are checking are first used * Added ss and eflags to xen_pmu_registers structure * vpmu_force_context_switch() uses per-cpu tasklet pointers. * Moved most of arch-specific VPMU initialization code into an __initcall() to avoid re-calculating/re-checking things more than once (new patch, #12) * Replaced is_*_domain() with is_*_vcpu() * choose_hwdom_vcpu() will now assume that hardware_domain-vcpu[idx] is always there (callers will still verify whether or not that's true) * Fixed a couple of sampled vs. sampling tests in vpmu_do_interrupt() * Pass CS to the guest unchanged, add pmu_flags's flag to indicate whether the sample was for a user or kernel space. Move pmu_flags from xen_pmu_data into xen_pmu_arch * Removed local msr_content variable from vpmu_do_wrmsr() * Re-arranged code in parse_vpmu_param() * Made vpmu_interrupt_type checks test for value, not individual bits * Moved PMU_SOFTIRQ definition into arch-specific header * Moved vpmu*.c files into xen/arch/x86/cpu/ instead of xen/arch/x86/ * For hypervisor samples, report DOMID_XEN to the guest * Changed logic to select which registers to report to the guest (include RIP check to see whether we are in the hypervisor) Changes in v12: * Added XSM support * Made a valifity check before writing MSR_CORE_PERF_GLOBAL_OVF_CTRL * Updated documentation for 'vpmu=nmi' option * Added more text to a bunch of commit messages (per Konrad's request) Changes in v11: * Replaced cpu_user_regs with new xen_pmu_regs (IP, SP, CS) in xen_pmu_arch. - as part of this re-work noticed that CS
[Xen-devel] [PATCH v17 06/23] intel/VPMU: Clean up Intel VPMU code
Remove struct pmumsr and core2_pmu_enable. Replace static MSR structures with
fields in core2_vpmu_context.
Call core2_get_pmc_count() once, during initialization.
Properly clean up when core2_vpmu_alloc_resource() fails.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/vmx/vpmu_core2.c| 380 ++-
xen/include/asm-x86/hvm/vmx/vpmu_core2.h | 19 --
2 files changed, 171 insertions(+), 228 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 951aece..9c4d00e 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -69,6 +69,27 @@
static bool_t __read_mostly full_width_write;
/*
+ * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
+ * counters. 4 bits for every counter.
+ */
+#define FIXED_CTR_CTRL_BITS 4
+#define FIXED_CTR_CTRL_MASK ((1 FIXED_CTR_CTRL_BITS) - 1)
+
+#define VPMU_CORE2_MAX_FIXED_PMCS 4
+struct core2_vpmu_context {
+u64 fixed_ctrl;
+u64 ds_area;
+u64 pebs_enable;
+u64 global_ovf_status;
+u64 enabled_cntrs; /* Follows PERF_GLOBAL_CTRL MSR format */
+u64 fix_counters[VPMU_CORE2_MAX_FIXED_PMCS];
+struct arch_msr_pair arch_msr_pair[1];
+};
+
+/* Number of general-purpose and fixed performance counters */
+static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
+
+/*
* QUIRK to workaround an issue on various family 6 cpus.
* The issue leads to endless PMC interrupt loops on the processor.
* If the interrupt handler is running and a pmc reaches the value 0, this
@@ -88,11 +109,8 @@ static void check_pmc_quirk(void)
is_pmc_quirk = 0;
}
-static int core2_get_pmc_count(void);
static void handle_pmc_quirk(u64 msr_content)
{
-int num_gen_pmc = core2_get_pmc_count();
-int num_fix_pmc = 3;
int i;
u64 val;
@@ -100,7 +118,7 @@ static void handle_pmc_quirk(u64 msr_content)
return;
val = msr_content;
-for ( i = 0; i num_gen_pmc; i++ )
+for ( i = 0; i arch_pmc_cnt; i++ )
{
if ( val 0x1 )
{
@@ -112,7 +130,7 @@ static void handle_pmc_quirk(u64 msr_content)
val = 1;
}
val = msr_content 32;
-for ( i = 0; i num_fix_pmc; i++ )
+for ( i = 0; i fixed_pmc_cnt; i++ )
{
if ( val 0x1 )
{
@@ -125,128 +143,91 @@ static void handle_pmc_quirk(u64 msr_content)
}
}
-static const u32 core2_fix_counters_msr[] = {
-MSR_CORE_PERF_FIXED_CTR0,
-MSR_CORE_PERF_FIXED_CTR1,
-MSR_CORE_PERF_FIXED_CTR2
-};
-
/*
- * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
- * counters. 4 bits for every counter.
+ * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
*/
-#define FIXED_CTR_CTRL_BITS 4
-#define FIXED_CTR_CTRL_MASK ((1 FIXED_CTR_CTRL_BITS) - 1)
-
-/* The index into the core2_ctrls_msr[] of this MSR used in core2_vpmu_dump()
*/
-#define MSR_CORE_PERF_FIXED_CTR_CTRL_IDX 0
-
-/* Core 2 Non-architectual Performance Control MSRs. */
-static const u32 core2_ctrls_msr[] = {
-MSR_CORE_PERF_FIXED_CTR_CTRL,
-MSR_IA32_PEBS_ENABLE,
-MSR_IA32_DS_AREA
-};
-
-struct pmumsr {
-unsigned int num;
-const u32 *msr;
-};
-
-static const struct pmumsr core2_fix_counters = {
-VPMU_CORE2_NUM_FIXED,
-core2_fix_counters_msr
-};
+static int core2_get_arch_pmc_count(void)
+{
+u32 eax;
-static const struct pmumsr core2_ctrls = {
-VPMU_CORE2_NUM_CTRLS,
-core2_ctrls_msr
-};
-static int arch_pmc_cnt;
+eax = cpuid_eax(0xa);
+return MASK_EXTR(eax, PMU_GENERAL_NR_MASK);
+}
/*
- * Read the number of general counters via CPUID.EAX[0xa].EAX[8..15]
+ * Read the number of fixed counters via CPUID.EDX[0xa].EDX[0..4]
*/
-static int core2_get_pmc_count(void)
+static int core2_get_fixed_pmc_count(void)
{
-u32 eax, ebx, ecx, edx;
+u32 eax;
-if ( arch_pmc_cnt == 0 )
-{
-cpuid(0xa, eax, ebx, ecx, edx);
-arch_pmc_cnt = (eax PMU_GENERAL_NR_MASK) PMU_GENERAL_NR_SHIFT;
-}
-
-return arch_pmc_cnt;
+eax = cpuid_eax(0xa);
+return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
}
static u64 core2_calc_intial_glb_ctrl_msr(void)
{
-int arch_pmc_bits = (1 core2_get_pmc_count()) - 1;
-u64 fix_pmc_bits = (1 3) - 1;
-return ((fix_pmc_bits 32) | arch_pmc_bits);
+int arch_pmc_bits = (1 arch_pmc_cnt) - 1;
+u64 fix_pmc_bits = (1 fixed_pmc_cnt) - 1;
+
+return (fix_pmc_bits 32) | arch_pmc_bits;
}
/* edx bits 5-12: Bit width of fixed-function performance counters */
static int core2_get_bitwidth_fix_count(void)
{
-u32 eax, ebx, ecx, edx;
+u32 edx;
-cpuid(0xa, eax, ebx, ecx, edx);
-return ((edx PMU_FIXED_WIDTH_MASK) PMU_FIXED_WIDTH_SHIFT);
+edx = cpuid_edx(0xa);
+return
[Xen-devel] [PATCH v17 12/23] x86/VPMU: Replace vcpu with vpmu as argument to some routines
A subsequent patch will add an inline routine to vpmu.h that will call
vpmu_load().
This inline will try to access vcpu-vpmu which is not possible since struct
vcpu may not be fully defined at that point. So we will have that inline pass
vpmu pointer to vpmu_load() instead.
This change slightly simplifies some of vpmu code.
For symmetry also modify vpmu_save() (and vpmu_save_force()) to use vpmu
instead of vcpu.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Jan Beulich jbeul...@suse.com
---
xen/arch/x86/domain.c | 4 ++--
xen/arch/x86/hvm/svm/vpmu.c | 23 +++
xen/arch/x86/hvm/vmx/vpmu_core2.c | 24
xen/arch/x86/hvm/vpmu.c | 31 +--
xen/include/asm-x86/hvm/vpmu.h| 26 +-
5 files changed, 51 insertions(+), 57 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 11c7d9f..4e45fa8 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1544,7 +1544,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
if ( is_hvm_vcpu(prev) )
{
if (prev != next)
-vpmu_save(prev);
+vpmu_save(vcpu_vpmu(prev));
if ( !list_empty(prev-arch.hvm_vcpu.tm_list) )
pt_save_timer(prev);
@@ -1589,7 +1589,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
if (is_hvm_vcpu(next) (prev != next) )
/* Must be done with interrupts enabled */
-vpmu_load(next);
+vpmu_load(vcpu_vpmu(next));
context_saved(prev);
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 545962d..72e2561 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -173,10 +173,9 @@ static int amd_vpmu_do_interrupt(struct cpu_user_regs
*regs)
return 1;
}
-static inline void context_load(struct vcpu *v)
+static inline void context_load(struct vpmu_struct *vpmu)
{
unsigned int i;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
struct xen_pmu_amd_ctxt *ctxt = vpmu-context;
uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
@@ -188,9 +187,8 @@ static inline void context_load(struct vcpu *v)
}
}
-static void amd_vpmu_load(struct vcpu *v)
+static void amd_vpmu_load(struct vpmu_struct *vpmu)
{
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
struct xen_pmu_amd_ctxt *ctxt = vpmu-context;
uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
@@ -208,13 +206,12 @@ static void amd_vpmu_load(struct vcpu *v)
vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
-context_load(v);
+context_load(vpmu);
}
-static inline void context_save(struct vcpu *v)
+static inline void context_save(struct vpmu_struct *vpmu)
{
unsigned int i;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
struct xen_pmu_amd_ctxt *ctxt = vpmu-context;
uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
@@ -223,9 +220,9 @@ static inline void context_save(struct vcpu *v)
rdmsrl(counters[i], counter_regs[i]);
}
-static int amd_vpmu_save(struct vcpu *v)
+static int amd_vpmu_save(struct vpmu_struct *vpmu)
{
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
+struct vcpu *v;
unsigned int i;
/*
@@ -245,7 +242,9 @@ static int amd_vpmu_save(struct vcpu *v)
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
return 0;
-context_save(v);
+context_save(vpmu);
+
+v = vpmu_vcpu(vpmu);
if ( !vpmu_is_set(vpmu, VPMU_RUNNING)
has_hvm_container_vcpu(v) is_msr_bitmap_on(vpmu) )
@@ -325,7 +324,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
|| vpmu_is_set(vpmu, VPMU_FROZEN) )
{
-context_load(v);
+context_load(vpmu);
vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
vpmu_reset(vpmu, VPMU_FROZEN);
}
@@ -346,7 +345,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t
*msr_content)
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED)
|| vpmu_is_set(vpmu, VPMU_FROZEN) )
{
-context_load(v);
+context_load(vpmu);
vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
vpmu_reset(vpmu, VPMU_FROZEN);
}
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index c2405bf..ad7c058 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -287,10 +287,10 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long
*msr_bitmap)
set_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
}
-static inline void __core2_vpmu_save(struct vcpu *v)
+static inline void __core2_vpmu_save(struct vpmu_struct *vpmu)
{
int i;
-struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)-context;
+struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vpmu-context;
uint64_t *fixed_counters =
[Xen-devel] [PATCH v17 21/23] x86/VPMU: Add privileged PMU mode
Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/vpmu.c | 40 ++--
xen/arch/x86/traps.c | 12
xen/include/public/pmu.h | 3 +++
3 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 79391b6..ebab0f5 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -99,7 +99,9 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
struct arch_vpmu_ops *ops;
int ret = 0;
-if ( !(vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode XENPMU_MODE_ALL)
+ !is_hardware_domain(current-domain)) )
goto nop;
curr = current;
@@ -151,8 +153,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
struct vcpu *sampled = current, *sampling;
struct vpmu_struct *vpmu;
-/* dom0 will handle interrupt for special domains (e.g. idle domain) */
-if ( sampled-domain-domain_id = DOMID_FIRST_RESERVED )
+/*
+ * dom0 will handle interrupt for special domains (e.g. idle domain) or,
+ * in XENPMU_MODE_ALL, for everyone.
+ */
+if ( (vpmu_mode XENPMU_MODE_ALL) ||
+ (sampled-domain-domain_id = DOMID_FIRST_RESERVED) )
{
sampling = choose_hwdom_vcpu();
if ( !sampling )
@@ -162,12 +168,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
sampling = sampled;
vpmu = vcpu_vpmu(sampling);
-if ( !is_hvm_vcpu(sampling) )
+if ( !is_hvm_vcpu(sampling) || (vpmu_mode XENPMU_MODE_ALL) )
{
/* PV(H) guest */
const struct cpu_user_regs *cur_regs;
uint64_t *flags = vpmu-xenpmu_data-pmu.pmu_flags;
-uint32_t domid = DOMID_SELF;
+uint32_t domid;
if ( !vpmu-xenpmu_data )
return;
@@ -176,6 +182,7 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
return;
if ( is_pvh_vcpu(sampling)
+ !(vpmu_mode XENPMU_MODE_ALL)
!vpmu-arch_vpmu_ops-do_interrupt(regs) )
return;
@@ -189,6 +196,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
else
*flags = PMU_SAMPLE_PV;
+if ( sampled == sampling )
+domid = DOMID_SELF;
+else
+domid = sampled-domain-domain_id;
+
/* Store appropriate registers in xenpmu_data */
/* FIXME: 32-bit PVH should go here as well */
if ( is_pv_32bit_vcpu(sampling) )
@@ -217,7 +229,8 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
if ( (vpmu_mode XENPMU_MODE_SELF) )
cur_regs = guest_cpu_user_regs();
-else if ( !guest_mode(regs)
is_hardware_domain(sampling-domain) )
+else if ( !guest_mode(regs)
+ is_hardware_domain(sampling-domain) )
{
cur_regs = regs;
domid = DOMID_XEN;
@@ -471,7 +484,8 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t
*params)
struct page_info *page;
uint64_t gfn = params-val;
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode XENPMU_MODE_ALL) !is_hardware_domain(d)) )
return -EINVAL;
if ( (params-vcpu = d-max_vcpus) || (d-vcpu == NULL) ||
@@ -551,6 +565,10 @@ void vpmu_dump(struct vcpu *v)
void vpmu_unload(struct vpmu_struct *vpmu)
{
+if ( (vpmu_mode XENPMU_MODE_ALL)
+ is_hardware_domain(vpmu_vcpu(vpmu)-domain) )
+return;
+
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
return;
@@ -663,11 +681,13 @@ long do_xenpmu_op(int op,
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
if ( copy_from_guest(pmu_params, arg, 1) )
return -EFAULT;
-if ( pmu_params.val ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+if ( pmu_params.val ~(XENPMU_MODE_SELF | XENPMU_MODE_HV |
+XENPMU_MODE_ALL) )
return -EINVAL;
/* 32-bit dom0 can only sample itself. */
-if ( is_pv_32bit_vcpu(current) (pmu_params.val XENPMU_MODE_HV) )
+if ( is_pv_32bit_vcpu(current)
+ (pmu_params.val (XENPMU_MODE_HV | XENPMU_MODE_ALL)) )
return -EINVAL;
/*
@@ -686,7 +706,7 @@ long do_xenpmu_op(int op,
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
old_mode = vpmu_mode;
vpmu_mode = pmu_params.val;
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if (
[Xen-devel] [PATCH v17 17/23] x86/VPMU: When handling MSR accesses, leave fault injection to callers
With this patch return value of 1 of vpmu_do_msr() will now indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register).
As part of this patch we also check for validity of certain MSR accesses right
when we determine which register is being written, as opposed to postponing this
until later.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/svm/svm.c| 6 ++-
xen/arch/x86/hvm/svm/vpmu.c | 6 +--
xen/arch/x86/hvm/vmx/vmx.c| 24 +---
xen/arch/x86/hvm/vmx/vpmu_core2.c | 82 ++-
4 files changed, 55 insertions(+), 63 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 59cca08..a8cb9ae 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1709,7 +1709,8 @@ static int svm_msr_read_intercept(unsigned int msr,
uint64_t *msr_content)
case MSR_AMD_FAM15H_EVNTSEL3:
case MSR_AMD_FAM15H_EVNTSEL4:
case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_rdmsr(msr, msr_content);
+if ( vpmu_do_rdmsr(msr, msr_content) )
+goto gpf;
break;
case MSR_AMD64_DR0_ADDRESS_MASK:
@@ -1860,7 +1861,8 @@ static int svm_msr_write_intercept(unsigned int msr,
uint64_t msr_content)
case MSR_AMD_FAM15H_EVNTSEL3:
case MSR_AMD_FAM15H_EVNTSEL4:
case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_wrmsr(msr, msr_content, 0);
+if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+goto gpf;
break;
case MSR_IA32_MCx_MISC(4): /* Threshold register */
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 7eeefa2..27c8a9c 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -324,7 +324,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
is_pmu_enabled(msr_content) !vpmu_is_set(vpmu, VPMU_RUNNING) )
{
if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-return 1;
+return 0;
vpmu_set(vpmu, VPMU_RUNNING);
if ( has_hvm_container_vcpu(v) is_msr_bitmap_on(vpmu) )
@@ -354,7 +354,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
/* Write to hw counters */
wrmsrl(msr, msr_content);
-return 1;
+return 0;
}
static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -372,7 +372,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t
*msr_content)
rdmsrl(msr, *msr_content);
-return 1;
+return 0;
}
static void amd_vpmu_destroy(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2b6981e..012bca4 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2112,12 +2112,17 @@ static int vmx_msr_read_intercept(unsigned int msr,
uint64_t *msr_content)
*msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
/* Perhaps vpmu will change some bits. */
+/* FALLTHROUGH */
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
if ( vpmu_do_rdmsr(msr, msr_content) )
-goto done;
+goto gp_fault;
break;
default:
-if ( vpmu_do_rdmsr(msr, msr_content) )
-break;
if ( passive_domain_do_rdmsr(msr, msr_content) )
goto done;
switch ( long_mode_do_msr_read(msr, msr_content) )
@@ -2293,7 +2298,7 @@ static int vmx_msr_write_intercept(unsigned int msr,
uint64_t msr_content)
if ( msr_content ~supported )
{
/* Perhaps some other bits are supported in vpmu. */
-if ( !vpmu_do_wrmsr(msr, msr_content, supported) )
+if ( vpmu_do_wrmsr(msr, msr_content, supported) )
break;
}
if ( msr_content IA32_DEBUGCTLMSR_LBR )
@@ -2321,9 +2326,16 @@ static int vmx_msr_write_intercept(unsigned int msr,
uint64_t msr_content)
if ( !nvmx_msr_write_intercept(msr, msr_content) )
goto gp_fault;
break;
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(7):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
+ if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+goto gp_fault;
+break;
default:
-if ( vpmu_do_wrmsr(msr, msr_content, 0) )
-return
[Xen-devel] [PATCH v17 03/23] x86/VPMU: Manage VPMU_CONTEXT_SAVE flag in vpmu_save_force()
There is a possibility that we set VPMU_CONTEXT_SAVE on VPMU context in
vpmu_load() and never clear it (because vpmu_save_force() will see
VPMU_CONTEXT_LOADED bit clear, which is possible on AMD processors)
The problem is that amd_vpmu_save() assumes that if VPMU_CONTEXT_SAVE is set
then (1) we need to save counters and (2) we don't need to stop control
registers since they must have been stopped earlier. The latter may cause all
sorts of problem (like counters still running in a wrong guest and hypervisor
sending to that guest unexpected PMU interrupts).
Since setting this flag is currently always done prior to calling
vpmu_save_force() let's both set and clear it there.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/vpmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index efb2279..e17e194 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -128,6 +128,8 @@ static void vpmu_save_force(void *arg)
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
return;
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+
if ( vpmu-arch_vpmu_ops )
(void)vpmu-arch_vpmu_ops-arch_vpmu_save(v);
@@ -176,7 +178,6 @@ void vpmu_load(struct vcpu *v)
*/
if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
on_selected_cpus(cpumask_of(vpmu-last_pcpu),
vpmu_save_force, (void *)v, 1);
vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
@@ -193,7 +194,6 @@ void vpmu_load(struct vcpu *v)
vpmu = vcpu_vpmu(prev);
/* Someone ran here before us */
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
vpmu_save_force(prev);
vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 02/23] x86/VPMU: Don't globally disable VPMU if initialization fails.
The failure to initialize VPMU may be temporary so we shouldn'd disable VMPU
forever.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Reported-by: Jan Beulich jbeul...@suse.com
---
xen/arch/x86/hvm/vpmu.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 37f0d9f..efb2279 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -218,6 +218,7 @@ void vpmu_initialise(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
uint8_t vendor = current_cpu_data.x86_vendor;
+int ret;
if ( is_pvh_vcpu(v) )
return;
@@ -230,21 +231,25 @@ void vpmu_initialise(struct vcpu *v)
switch ( vendor )
{
case X86_VENDOR_AMD:
-if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-opt_vpmu_enabled = 0;
+ret = svm_vpmu_initialise(v, opt_vpmu_enabled);
break;
case X86_VENDOR_INTEL:
-if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
-opt_vpmu_enabled = 0;
+ret = vmx_vpmu_initialise(v, opt_vpmu_enabled);
break;
default:
-printk(VPMU: Initialization failed.
- Unknown CPU vendor %d\n, vendor);
-opt_vpmu_enabled = 0;
-break;
+if ( opt_vpmu_enabled )
+{
+printk(XENLOG_G_WARNING VPMU: Unknown CPU vendor %d.
+ Disabling VPMU\n, vendor);
+opt_vpmu_enabled = 0;
+}
+return;
}
+
+if ( ret )
+printk(XENLOG_G_WARNING VPMU: Initialization failed for %pv\n, v);
}
static void vpmu_clear_last(void *arg)
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 09/23] intel/VPMU: MSR_CORE_PERF_GLOBAL_CTRL should be initialized to zero
MSR_CORE_PERF_GLOBAL_CTRL register should be set zero initially. It is up to
the guest to set it so that counters are enabled.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/vmx/vpmu_core2.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 8b84079..7793145 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -165,14 +165,6 @@ static int core2_get_fixed_pmc_count(void)
return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
}
-static u64 core2_calc_intial_glb_ctrl_msr(void)
-{
-int arch_pmc_bits = (1 arch_pmc_cnt) - 1;
-u64 fix_pmc_bits = (1 fixed_pmc_cnt) - 1;
-
-return (fix_pmc_bits 32) | arch_pmc_bits;
-}
-
/* edx bits 5-12: Bit width of fixed-function performance counters */
static int core2_get_bitwidth_fix_count(void)
{
@@ -373,8 +365,7 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
goto out_err;
-vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
- core2_calc_intial_glb_ctrl_msr());
+vmx_write_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, 0);
core2_vpmu_cxt = xzalloc_bytes(sizeof(struct core2_vpmu_context) +
(arch_pmc_cnt-1)*sizeof(struct arch_msr_pair));
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure TSC
implementation.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 82
--
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/arch/x86/vdso/vclock_gettime.c
b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info
*get_pvti(int cpu)
static notrace cycle_t vread_pvclock(int *mode)
{
- const struct pvclock_vsyscall_time_info *pvti;
+ const struct pvclock_vcpu_time_info *pvti = get_pvti(0)-pvti;
cycle_t ret;
- u64 last;
- u32 version;
- u8 flags;
- unsigned cpu, cpu1;
-
+ u64 tsc, pvti_tsc;
+ u64 last, delta, pvti_system_time;
+ u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
/*
- * Note: hypervisor must guarantee that:
- * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
- * 2. that per-CPU pvclock time info is updated if the
- *underlying CPU changes.
- * 3. that version is increased whenever underlying CPU
- *changes.
+ * Note: The kernel and hypervisor must guarantee that cpu ID
+ * number maps 1:1 to per-CPU pvclock time info.
+ *
+ * Because the hypervisor is entirely unaware of guest userspace
+ * preemption, it cannot guarantee that per-CPU pvclock time
+ * info is updated if the underlying CPU changes or that that
+ * version is increased whenever underlying CPU changes.
+ *
+ * On KVM, we are guaranteed that pvti updates for any vCPU are
+ * atomic as seen by *all* vCPUs. This is an even stronger
+ * guarantee than we get with a normal seqlock.
*
+ * On Xen, we don't appear to have that guarantee, but Xen still
+ * supplies a valid seqlock using the version field.
+
+ * We only do pvclock vdso timing at all if
+ * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+ * mean that all vCPUs have matching pvti and that the TSC is
+ * synced, so we can just look at vCPU 0's pvti.
*/
Can Xen guarantee that ?
I think so, vacuously. Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
at all. I have no idea going forward, though.
Xen people?
- do {
- cpu = __getcpu() VGETCPU_CPU_MASK;
- /* TODO: We can put vcpu id into higher bits of pvti.version.
- * This will save a couple of cycles by getting rid of
- * __getcpu() calls (Gleb).
- */
-
- pvti = get_pvti(cpu);
-
- version = __pvclock_read_cycles(pvti-pvti, ret, flags);
-
- /*
- * Test we're still on the cpu as well as the version.
- * We could have been migrated just after the first
- * vgetcpu but before fetching the version, so we
- * wouldn't notice a version change.
- */
- cpu1 = __getcpu() VGETCPU_CPU_MASK;
- } while (unlikely(cpu != cpu1 ||
- (pvti-pvti.version 1) ||
- pvti-pvti.version != version));
-
- if (unlikely(!(flags PVCLOCK_TSC_STABLE_BIT)))
+
+ if (unlikely(!(pvti-flags PVCLOCK_TSC_STABLE_BIT))) {
*mode = VCLOCK_NONE;
+ return 0;
+ }
This check must be performed after reading a stable pvti.
We can even read it in the middle, guarded by the version checks.
I'll do that for v2.
+
+ do {
+ version = pvti-version;
+
+ /* This is also a read barrier, so we'll read version first.
*/
+ rdtsc_barrier();
+ tsc = __native_read_tsc();
+
+ pvti_tsc_to_system_mul = pvti-tsc_to_system_mul;
+ pvti_tsc_shift = pvti-tsc_shift;
+ pvti_system_time = pvti-system_time;
+ pvti_tsc = pvti-tsc_timestamp;
+
+ /* Make sure that the version double-check is last. */
+ smp_rmb();
+ } while (unlikely((version 1) || version != pvti-version));
+
+ delta = tsc - pvti_tsc;
+ ret =
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure TSC
implementation.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 82
--
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/arch/x86/vdso/vclock_gettime.c
b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct
pvclock_vsyscall_time_info *get_pvti(int cpu)
static notrace cycle_t vread_pvclock(int *mode)
{
- const struct pvclock_vsyscall_time_info *pvti;
+ const struct pvclock_vcpu_time_info *pvti = get_pvti(0)-pvti;
cycle_t ret;
- u64 last;
- u32 version;
- u8 flags;
- unsigned cpu, cpu1;
-
+ u64 tsc, pvti_tsc;
+ u64 last, delta, pvti_system_time;
+ u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
/*
- * Note: hypervisor must guarantee that:
- * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
- * 2. that per-CPU pvclock time info is updated if the
- *underlying CPU changes.
- * 3. that version is increased whenever underlying CPU
- *changes.
+ * Note: The kernel and hypervisor must guarantee that cpu ID
+ * number maps 1:1 to per-CPU pvclock time info.
+ *
+ * Because the hypervisor is entirely unaware of guest userspace
+ * preemption, it cannot guarantee that per-CPU pvclock time
+ * info is updated if the underlying CPU changes or that that
+ * version is increased whenever underlying CPU changes.
+ *
+ * On KVM, we are guaranteed that pvti updates for any vCPU are
+ * atomic as seen by *all* vCPUs. This is an even stronger
+ * guarantee than we get with a normal seqlock.
*
+ * On Xen, we don't appear to have that guarantee, but Xen still
+ * supplies a valid seqlock using the version field.
+
+ * We only do pvclock vdso timing at all if
+ * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+ * mean that all vCPUs have matching pvti and that the TSC is
+ * synced, so we can just look at vCPU 0's pvti.
*/
Can Xen guarantee that ?
I think so, vacuously. Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
at all. I have no idea going forward, though.
Xen people?
- do {
- cpu = __getcpu() VGETCPU_CPU_MASK;
- /* TODO: We can put vcpu id into higher bits of
pvti.version.
- * This will save a couple of cycles by getting rid of
- * __getcpu() calls (Gleb).
- */
-
- pvti = get_pvti(cpu);
-
- version = __pvclock_read_cycles(pvti-pvti, ret, flags);
-
- /*
- * Test we're still on the cpu as well as the version.
- * We could have been migrated just after the first
- * vgetcpu but before fetching the version, so we
- * wouldn't notice a version change.
- */
- cpu1 = __getcpu() VGETCPU_CPU_MASK;
- } while (unlikely(cpu != cpu1 ||
- (pvti-pvti.version 1) ||
- pvti-pvti.version != version));
-
- if (unlikely(!(flags PVCLOCK_TSC_STABLE_BIT)))
+
+ if (unlikely(!(pvti-flags PVCLOCK_TSC_STABLE_BIT))) {
*mode = VCLOCK_NONE;
+ return 0;
+ }
This check must be performed after reading a stable pvti.
We can even read it in the middle, guarded by the version checks.
I'll do that for v2.
+
+ do {
+ version = pvti-version;
+
+ /* This is also a read barrier, so we'll read version
first. */
+ rdtsc_barrier();
+ tsc = __native_read_tsc();
+
+ pvti_tsc_to_system_mul = pvti-tsc_to_system_mul;
+ pvti_tsc_shift = pvti-tsc_shift;
+ pvti_system_time = pvti-system_time;
+ pvti_tsc = pvti-tsc_timestamp;
+
+ /* Make sure that the version double-check is last. */
+ smp_rmb();
+ } while (unlikely((version 1) || version
[Xen-devel] [PATCH v17 08/23] x86/VPMU: Handle APIC_LVTPC accesses
Don't have the hypervisor update APIC_LVTPC when _it_ thinks the vector should
be updated. Instead, handle guest's APIC_LVTPC accesses and write what the guest
explicitly wanted.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Acked-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/hvm/svm/vpmu.c | 4
xen/arch/x86/hvm/vlapic.c | 3 +++
xen/arch/x86/hvm/vmx/vpmu_core2.c | 17 -
xen/arch/x86/hvm/vpmu.c | 8
xen/include/asm-x86/hvm/vpmu.h| 1 +
5 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 19777e3..64dc167 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -302,8 +302,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
return 1;
vpmu_set(vpmu, VPMU_RUNNING);
-apic_write(APIC_LVTPC, PMU_APIC_VECTOR);
-vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR;
if ( has_hvm_container_vcpu(v)
!((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
@@ -314,8 +312,6 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL)
(is_pmu_enabled(msr_content) == 0) vpmu_is_set(vpmu, VPMU_RUNNING) )
{
-apic_write(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
vpmu_reset(vpmu, VPMU_RUNNING);
if ( has_hvm_container_vcpu(v)
((struct amd_vpmu_context *)vpmu-context)-msr_bitmap_set )
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 72b6509..56b9d23 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,6 +38,7 @@
#include asm/hvm/support.h
#include asm/hvm/vmx/vmx.h
#include asm/hvm/nestedhvm.h
+#include asm/hvm/vpmu.h
#include public/hvm/ioreq.h
#include public/hvm/params.h
@@ -789,6 +790,8 @@ static int vlapic_reg_write(struct vcpu *v,
}
if ( (offset == APIC_LVTT) !(val APIC_LVT_MASKED) )
pt_may_unmask_irq(NULL, vlapic-pt);
+if ( offset == APIC_LVTPC )
+vpmu_lvtpc_update(val);
break;
case APIC_TMICT:
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 9c4d00e..8b84079 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -528,19 +528,6 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
else
vpmu_reset(vpmu, VPMU_RUNNING);
-/* Setup LVTPC in local apic */
-if ( vpmu_is_set(vpmu, VPMU_RUNNING)
- is_vlapic_lvtpc_enabled(vcpu_vlapic(v)) )
-{
-apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR);
-vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR;
-}
-else
-{
-apic_write_around(APIC_LVTPC, PMU_APIC_VECTOR | APIC_LVT_MASKED);
-vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR | APIC_LVT_MASKED;
-}
-
if ( type != MSR_TYPE_GLOBAL )
{
u64 mask;
@@ -706,10 +693,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs
*regs)
return 0;
}
-/* HW sets the MASK bit when performance counter interrupt occurs*/
-vpmu-hw_lapic_lvtpc = apic_read(APIC_LVTPC) ~APIC_LVT_MASKED;
-apic_write_around(APIC_LVTPC, vpmu-hw_lapic_lvtpc);
-
return 1;
}
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 63b2158..d94b63c 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -64,6 +64,14 @@ static void __init parse_vpmu_param(char *s)
}
}
+void vpmu_lvtpc_update(uint32_t val)
+{
+struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+vpmu-hw_lapic_lvtpc = PMU_APIC_VECTOR | (val APIC_LVT_MASKED);
+apic_write(APIC_LVTPC, vpmu-hw_lapic_lvtpc);
+}
+
int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
{
struct vpmu_struct *vpmu = vcpu_vpmu(current);
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ddc2748..9c4e65a 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -104,6 +104,7 @@ static inline bool_t vpmu_are_all_set(const struct
vpmu_struct *vpmu,
return !!((vpmu-flags mask) == mask);
}
+void vpmu_lvtpc_update(uint32_t val);
int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
void vpmu_do_interrupt(struct cpu_user_regs *regs);
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 20/23] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr
The two routines share most of their logic.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
xen/arch/x86/hvm/vpmu.c| 77 --
xen/include/asm-x86/hvm/vpmu.h | 14 ++--
2 files changed, 42 insertions(+), 49 deletions(-)
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index c57b250..79391b6 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -91,65 +91,48 @@ void vpmu_lvtpc_update(uint32_t val)
apic_write(APIC_LVTPC, vpmu-hw_lapic_lvtpc);
}
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write)
{
-struct vcpu *curr = current;
+struct vcpu *curr;
struct vpmu_struct *vpmu;
+struct arch_vpmu_ops *ops;
+int ret = 0;
if ( !(vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
-return 0;
+goto nop;
+curr = current;
vpmu = vcpu_vpmu(curr);
-if ( vpmu-arch_vpmu_ops vpmu-arch_vpmu_ops-do_wrmsr )
-{
-int ret = vpmu-arch_vpmu_ops-do_wrmsr(msr, msr_content, supported);
-
-/*
- * We may have received a PMU interrupt during WRMSR handling
- * and since do_wrmsr may load VPMU context we should save
- * (and unload) it again.
- */
-if ( !is_hvm_vcpu(curr) vpmu-xenpmu_data
- (vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu-arch_vpmu_ops-arch_vpmu_save(vpmu);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-
-return 0;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-struct vcpu *curr = current;
-struct vpmu_struct *vpmu;
+ops = vpmu-arch_vpmu_ops;
+if ( !ops )
+goto nop;
+
+if ( is_write ops-do_wrmsr )
+ret = ops-do_wrmsr(msr, *msr_content, supported);
+else if ( !is_write ops-do_rdmsr )
+ret = ops-do_rdmsr(msr, msr_content);
+else
+goto nop;
-if ( !(vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+/*
+ * We may have received a PMU interrupt while handling MSR access
+ * and since do_wr/rdmsr may load VPMU context we should save
+ * (and unload) it again.
+ */
+if ( !is_hvm_vcpu(curr)
+ vpmu-xenpmu_data (vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
{
-*msr_content = 0;
-return 0;
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+ops-arch_vpmu_save(vpmu);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
}
-vpmu = vcpu_vpmu(curr);
-if ( vpmu-arch_vpmu_ops vpmu-arch_vpmu_ops-do_rdmsr )
-{
-int ret = vpmu-arch_vpmu_ops-do_rdmsr(msr, msr_content);
+return ret;
-if ( !is_hvm_vcpu(curr) vpmu-xenpmu_data
- (vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu-arch_vpmu_ops-arch_vpmu_save(vpmu);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-else
+ nop:
+if ( !is_write )
*msr_content = 0;
-
return 0;
}
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 42a09f9..2c888cc 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -100,8 +100,8 @@ static inline bool_t vpmu_are_all_set(const struct
vpmu_struct *vpmu,
}
void vpmu_lvtpc_update(uint32_t val);
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write);
void vpmu_do_interrupt(struct cpu_user_regs *regs);
void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
@@ -112,6 +112,16 @@ void vpmu_load(struct vpmu_struct *vpmu);
void vpmu_unload(struct vpmu_struct *vpmu);
void vpmu_dump(struct vcpu *v);
+static inline int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
+uint64_t supported)
+{
+return vpmu_do_msr(msr, msr_content, supported, 1);
+}
+static inline int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
+{
+return vpmu_do_msr(msr, msr_content, 0, 0);
+}
+
extern int acquire_pmu_ownership(int pmu_ownership);
extern void release_pmu_ownership(int pmu_ownership);
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v17 16/23] x86/VPMU: Save VPMU state for PV guests during context switch
Save VPMU state during context switch for both HVM and PV(H) guests.
A subsequent patch (x86/VPMU: NMI-based VPMU support) will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()-vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call
context_saved()
before vpmu_switch_to() is executed. (Note that while this change could have
been dalayed until that later patch, the changes are harmless to existing code
and so we do it here)
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com
---
xen/arch/x86/domain.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a29db67..7d5d46b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1541,17 +1541,14 @@ void context_switch(struct vcpu *prev, struct vcpu
*next)
}
if ( prev != next )
-_update_runstate_area(prev);
-
-if ( is_hvm_vcpu(prev) )
{
-if (prev != next)
-vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
-
-if ( !list_empty(prev-arch.hvm_vcpu.tm_list) )
-pt_save_timer(prev);
+_update_runstate_area(prev);
+vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
}
+if ( is_hvm_vcpu(prev) !list_empty(prev-arch.hvm_vcpu.tm_list) )
+pt_save_timer(prev);
+
local_irq_disable();
set_current(next);
@@ -1589,15 +1586,16 @@ void context_switch(struct vcpu *prev, struct vcpu
*next)
!is_hardware_domain(next-domain));
}
-if ( is_hvm_vcpu(next) (prev != next) )
-/* Must be done with interrupts enabled */
-vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
-
context_saved(prev);
if ( prev != next )
+{
_update_runstate_area(next);
+/* Must be done with interrupts enabled */
+vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
+}
+
/* Ensure that the vcpu has an up-to-date time base. */
update_vcpu_system_time(next);
--
1.8.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Mon, Jan 5, 2015 at 2:48 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 02:38:46PM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure
TSC
implementation.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 82
--
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/arch/x86/vdso/vclock_gettime.c
b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct
pvclock_vsyscall_time_info *get_pvti(int cpu)
static notrace cycle_t vread_pvclock(int *mode)
{
- const struct pvclock_vsyscall_time_info *pvti;
+ const struct pvclock_vcpu_time_info *pvti = get_pvti(0)-pvti;
cycle_t ret;
- u64 last;
- u32 version;
- u8 flags;
- unsigned cpu, cpu1;
-
+ u64 tsc, pvti_tsc;
+ u64 last, delta, pvti_system_time;
+ u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
/*
- * Note: hypervisor must guarantee that:
- * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
- * 2. that per-CPU pvclock time info is updated if the
- *underlying CPU changes.
- * 3. that version is increased whenever underlying CPU
- *changes.
+ * Note: The kernel and hypervisor must guarantee that cpu ID
+ * number maps 1:1 to per-CPU pvclock time info.
+ *
+ * Because the hypervisor is entirely unaware of guest userspace
+ * preemption, it cannot guarantee that per-CPU pvclock time
+ * info is updated if the underlying CPU changes or that that
+ * version is increased whenever underlying CPU changes.
+ *
+ * On KVM, we are guaranteed that pvti updates for any vCPU are
+ * atomic as seen by *all* vCPUs. This is an even stronger
+ * guarantee than we get with a normal seqlock.
*
+ * On Xen, we don't appear to have that guarantee, but Xen still
+ * supplies a valid seqlock using the version field.
+
+ * We only do pvclock vdso timing at all if
+ * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+ * mean that all vCPUs have matching pvti and that the TSC is
+ * synced, so we can just look at vCPU 0's pvti.
*/
Can Xen guarantee that ?
I think so, vacuously. Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
at all. I have no idea going forward, though.
Xen people?
- do {
- cpu = __getcpu() VGETCPU_CPU_MASK;
- /* TODO: We can put vcpu id into higher bits of
pvti.version.
- * This will save a couple of cycles by getting rid of
- * __getcpu() calls (Gleb).
- */
-
- pvti = get_pvti(cpu);
-
- version = __pvclock_read_cycles(pvti-pvti, ret,
flags);
-
- /*
- * Test we're still on the cpu as well as the version.
- * We could have been migrated just after the first
- * vgetcpu but before fetching the version, so we
- * wouldn't notice a version change.
- */
- cpu1 = __getcpu() VGETCPU_CPU_MASK;
- } while (unlikely(cpu != cpu1 ||
- (pvti-pvti.version 1) ||
- pvti-pvti.version != version));
-
- if (unlikely(!(flags PVCLOCK_TSC_STABLE_BIT)))
+
+ if (unlikely(!(pvti-flags PVCLOCK_TSC_STABLE_BIT))) {
*mode = VCLOCK_NONE;
+ return 0;
+ }
This check must be performed after reading a stable pvti.
We can even read it in the middle, guarded by the version checks.
I'll do that for v2.
+
+ do {
+ version = pvti-version;
+
+ /* This is also a read barrier, so we'll read version
first. */
+ rdtsc_barrier();
+ tsc = __native_read_tsc();
+
+ pvti_tsc_to_system_mul = pvti-tsc_to_system_mul;
+
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Mon, Jan 05, 2015 at 02:38:46PM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 11:17 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure TSC
implementation.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 82
--
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/arch/x86/vdso/vclock_gettime.c
b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct
pvclock_vsyscall_time_info *get_pvti(int cpu)
static notrace cycle_t vread_pvclock(int *mode)
{
- const struct pvclock_vsyscall_time_info *pvti;
+ const struct pvclock_vcpu_time_info *pvti = get_pvti(0)-pvti;
cycle_t ret;
- u64 last;
- u32 version;
- u8 flags;
- unsigned cpu, cpu1;
-
+ u64 tsc, pvti_tsc;
+ u64 last, delta, pvti_system_time;
+ u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
/*
- * Note: hypervisor must guarantee that:
- * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
- * 2. that per-CPU pvclock time info is updated if the
- *underlying CPU changes.
- * 3. that version is increased whenever underlying CPU
- *changes.
+ * Note: The kernel and hypervisor must guarantee that cpu ID
+ * number maps 1:1 to per-CPU pvclock time info.
+ *
+ * Because the hypervisor is entirely unaware of guest userspace
+ * preemption, it cannot guarantee that per-CPU pvclock time
+ * info is updated if the underlying CPU changes or that that
+ * version is increased whenever underlying CPU changes.
+ *
+ * On KVM, we are guaranteed that pvti updates for any vCPU are
+ * atomic as seen by *all* vCPUs. This is an even stronger
+ * guarantee than we get with a normal seqlock.
*
+ * On Xen, we don't appear to have that guarantee, but Xen still
+ * supplies a valid seqlock using the version field.
+
+ * We only do pvclock vdso timing at all if
+ * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+ * mean that all vCPUs have matching pvti and that the TSC is
+ * synced, so we can just look at vCPU 0's pvti.
*/
Can Xen guarantee that ?
I think so, vacuously. Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
at all. I have no idea going forward, though.
Xen people?
- do {
- cpu = __getcpu() VGETCPU_CPU_MASK;
- /* TODO: We can put vcpu id into higher bits of
pvti.version.
- * This will save a couple of cycles by getting rid of
- * __getcpu() calls (Gleb).
- */
-
- pvti = get_pvti(cpu);
-
- version = __pvclock_read_cycles(pvti-pvti, ret,
flags);
-
- /*
- * Test we're still on the cpu as well as the version.
- * We could have been migrated just after the first
- * vgetcpu but before fetching the version, so we
- * wouldn't notice a version change.
- */
- cpu1 = __getcpu() VGETCPU_CPU_MASK;
- } while (unlikely(cpu != cpu1 ||
- (pvti-pvti.version 1) ||
- pvti-pvti.version != version));
-
- if (unlikely(!(flags PVCLOCK_TSC_STABLE_BIT)))
+
+ if (unlikely(!(pvti-flags PVCLOCK_TSC_STABLE_BIT))) {
*mode = VCLOCK_NONE;
+ return 0;
+ }
This check must be performed after reading a stable pvti.
We can even read it in the middle, guarded by the version checks.
I'll do that for v2.
+
+ do {
+ version = pvti-version;
+
+ /* This is also a read barrier, so we'll read version
first. */
+ rdtsc_barrier();
+ tsc = __native_read_tsc();
+
+ pvti_tsc_to_system_mul = pvti-tsc_to_system_mul;
+ pvti_tsc_shift = pvti-tsc_shift;
+ pvti_system_time = pvti-system_time;
Re: [Xen-devel] [Qemu-devel] bind interdomain ioctl error xen-kvm.c
On 01/05/15 14:10, Rishi Ranjan wrote:
Hi Stefano,
Please find my answers inline.
However Anthony (CC'ed) should have some patches for it.
Anthony, can you please share any patch that can help me with this?
Can you post the full output of the logs?
I have attached the output of sudo xl -v create /etc/xen/qemu-pv.cfg
as xl_create.txt. I have also enabled DEBUG_XEN_HVM in xen-hvm.c and
pasted output of sudo ./x86_64-softmmu/qemu-system-x86_64 -machine
q35,accel=xen -cpu qemu64 -xen-domid 13 below:
The output of sudo xl -vvv create /etc/xen/qemu-pv.cfg will help
since it includes how xen invokes qemu.
xen: shared page at pfn feffd
xen: buffered io page at pfn feffb
bind interdomain ioctl error 22
xen hardware virtual machine initialisation failed
This says that where you are reporting the error is not
correct.
The message buffered io page at pfn feffb is output
after the code that contains shared_vmport_page.
Also posting the data in /var/log/xen/qemu-dm-qemu-hvm.log
will help.
It looks like you are re-starting QEMU on a domain. This is not
supported as far as I know (and not clear that you are starting the same
version that xen tried).
What is the Xen version that you are running?
I am using XEN 4.4.1 as this is the default on Ubuntu 14.04. I have
attached the output of xl info command as xl_info.txt.
You are running QEMU 2.2.0 or later based on having
shared_vmport_page in the code.
Did you execute the xencommons init script at boot time?
On Ubuntu I don't see /etc/init.d/xencommon but there is a
/etc/init.d/xen script which starts xenstored and xenconsoled. I did
confirm from ps aufx that both the daemons are running. I have attched
log for ps aufx as ps_aufx_grep_xen.txt .
On Mon, Jan 5, 2015 at 4:48 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com
mailto:stefano.stabell...@eu.citrix.com wrote:
On Tue, 30 Dec 2014, Rishi Ranjan wrote:
I am trying to use Xen as accelerator for my Qemu machine. I have
created a guest domain with following xl config:
builder = hvm
name = qemu-hvm
memory = 512
vcpus = 1
vif = ['']
vnc = 1
boot=c
When I try to run with following parameters:
-machine q35,accel=xen -cpu qemu64 -bios ./pc-bios/bios-256k.bin
-xen-domid Domain id of guest
You should know that q35 emulation is not fully working on Xen yet.
However Anthony (CC'ed) should have some patches for it.
That said, it does not look like this error has something to do with
q35.
I am getting follwing error from xen-hvm.c:
bind interdomain ioctl error in xen_hvm_init while calling
state-shared_vmport_page =
xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
PROT_READ|PROT_WRITE, ioreq_pfn);
To get here, xen_get_vmport_regs_pfn() needs to return 0.
In include/hw/xen/xen_common.h:
#ifdef HVM_PARAM_VMPORT_REGS_PFN
static inline int xen_get_vmport_regs_pfn(XenXC xc, domid_t dom,
unsigned long *vmport_regs_pfn)
{
return xc_get_hvm_param(xc, dom, HVM_PARAM_VMPORT_REGS_PFN,
vmport_regs_pfn);
}
#else
static inline int xen_get_vmport_regs_pfn(XenXC xc, domid_t dom,
unsigned long *vmport_regs_pfn)
{
return -ENOSYS;
}
#endif
requires HVM_PARAM_VMPORT_REGS_PFN to be defined before it will return
0.
I am sure that xen 4.4.1 does not define this (patch that does is
waiting for xen 4.6 to open up).
-Don Slutz
Can someone help me get this working?
Can you post the full output of the logs?
What is the Xen version that you are running?
Did you execute the xencommons init script at boot time?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/4] sysctl: Add sysctl interface for querying PCI topology
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
xen/common/sysctl.c | 60 +++
xen/include/public/sysctl.h | 35 -
2 files changed, 94 insertions(+), 1 deletions(-)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 1254a24..f09d377 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -365,6 +365,66 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
}
break;
+case XEN_SYSCTL_pcitopoinfo:
+{
+xen_sysctl_pcitopoinfo_t *ti = op-u.pcitopoinfo;
+
+if ( guest_handle_is_null(ti-pcitopo) ||
+ (ti-first_dev = ti-num_devs) )
+{
+ret = -EINVAL;
+break;
+}
+
+for ( ; ti-first_dev ti-num_devs; ti-first_dev++ )
+{
+xen_sysctl_pcitopo_t pcitopo;
+struct pci_dev *pdev;
+
+if ( copy_from_guest_offset(pcitopo, ti-pcitopo,
+ti-first_dev, 1) )
+{
+ret = -EFAULT;
+break;
+}
+
+spin_lock(pcidevs_lock);
+pdev = pci_get_pdev(pcitopo.pcidev.seg, pcitopo.pcidev.bus,
+pcitopo.pcidev.devfn);
+if ( !pdev || (pdev-node == NUMA_NO_NODE) )
+pcitopo.node = INVALID_TOPOLOGY_ID;
+else
+pcitopo.node = pdev-node;
+spin_unlock(pcidevs_lock);
+
+if ( copy_to_guest_offset(ti-pcitopo, ti-first_dev,
+ pcitopo, 1) )
+{
+ret = -EFAULT;
+break;
+}
+
+if ( hypercall_preempt_check() )
+break;
+}
+
+if ( !ret )
+{
+if ( __copy_field_to_guest(u_sysctl, op,
+ u.pcitopoinfo.first_dev) )
+{
+ret = -EFAULT;
+break;
+}
+
+if ( ti-first_dev ti-num_devs )
+ret = hypercall_create_continuation(__HYPERVISOR_sysctl,
+ h, u_sysctl);
+
+}
+}
+break;
+
#ifdef TEST_COVERAGE
case XEN_SYSCTL_coverage_op:
ret = sysctl_coverage_op(op-u.coverage_op);
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 512ad74..628ed6a 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -33,6 +33,7 @@
#include xen.h
#include domctl.h
+#include physdev.h
#define XEN_SYSCTL_INTERFACE_VERSION 0x000C
@@ -463,7 +464,7 @@ typedef struct xen_sysctl_lockprof_op
xen_sysctl_lockprof_op_t;
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_lockprof_op_t);
/* XEN_SYSCTL_cputopoinfo */
-#define INVALID_TOPOLOGY_ID (~0U)
+#define INVALID_TOPOLOGY_ID (~0U) /* Also used by pcitopo */
struct xen_sysctl_cputopo {
uint32_t core;
@@ -492,6 +493,36 @@ struct xen_sysctl_cputopoinfo {
typedef struct xen_sysctl_cputopoinfo xen_sysctl_cputopoinfo_t;
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopoinfo_t);
+/* XEN_SYSCTL_pcitopoinfo */
+struct xen_sysctl_pcitopo {
+struct physdev_pci_device pcidev;
+uint32_t node;
+};
+typedef struct xen_sysctl_pcitopo xen_sysctl_pcitopo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopo_t);
+
+struct xen_sysctl_pcitopoinfo {
+/* IN: Size of pcitopo array */
+uint32_t num_devs;
+
+/*
+ * IN/OUT: First element of pcitopo array that needs to be processed by
+ * hypervisor.
+ * This is used primarily by hypercall continuations and callers will
+ * typically set it to zero
+ */
+uint32_t first_dev;
+
+/*
+ * If not NULL, filled with node identifier for each pcidev
+ * If information for a particular device is not avalable then node is set
+ * to INVALID_TOPOLOGY_ID.
+ */
+XEN_GUEST_HANDLE_64(xen_sysctl_pcitopo_t) pcitopo;
+};
+typedef struct xen_sysctl_pcitopoinfo xen_sysctl_pcitopoinfo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t);
+
/* XEN_SYSCTL_numainfo */
#define INVALID_NUMAINFO_ID (~0U)
struct xen_sysctl_numainfo {
@@ -681,12 +712,14 @@ struct xen_sysctl {
#define XEN_SYSCTL_scheduler_op 19
#define XEN_SYSCTL_coverage_op 20
#define XEN_SYSCTL_psr_cmt_op21
+#define XEN_SYSCTL_pcitopoinfo 22
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
struct xen_sysctl_readconsole readconsole;
struct xen_sysctl_tbuf_op tbuf_op;
struct xen_sysctl_physinfo physinfo;
struct xen_sysctl_cputopoinfo cputopoinfo;
+struct xen_sysctl_pcitopoinfo pcitopoinfo;
struct xen_sysctl_numainfo numainfo;
struct xen_sysctl_sched_id sched_id;
struct xen_sysctl_perfc_op perfc_op;
--
1.7.1
[Xen-devel] [PATCH v2 1/4] pci: Do not ignore device's PXM information
If ACPI provides PXM data for IO devices then dom0 will pass it to
hypervisor during PHYSDEVOP_pci_device_add call. This information,
however, is currently ignored.
We will store this information (in the form of nodeID) in pci_dev
structure so that we can provide it, for example, to the toolstack
when it adds support (in the following patches) for querying the
hypervisor about device topology
We will also print it when user requests device information dump.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
xen/arch/x86/physdev.c| 23 ---
xen/drivers/passthrough/pci.c | 13 +
xen/include/public/physdev.h |6 ++
xen/include/xen/pci.h |5 -
4 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 6b3201b..62e768e 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -565,7 +565,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
arg)
if ( copy_from_guest(manage_pci, arg, 1) != 0 )
break;
-ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn, NULL);
+ret = pci_add_device(0, manage_pci.bus, manage_pci.devfn,
+ NULL, NUMA_NO_NODE);
break;
}
@@ -597,13 +598,14 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
arg)
pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
ret = pci_add_device(0, manage_pci_ext.bus,
manage_pci_ext.devfn,
- pdev_info);
+ pdev_info, NUMA_NO_NODE);
break;
}
case PHYSDEVOP_pci_device_add: {
struct physdev_pci_device_add add;
struct pci_dev_info pdev_info;
+int node;
ret = -EFAULT;
if ( copy_from_guest(add, arg, 1) != 0 )
@@ -618,7 +620,22 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
arg)
}
else
pdev_info.is_virtfn = 0;
-ret = pci_add_device(add.seg, add.bus, add.devfn, pdev_info);
+
+if ( add.flags XEN_PCI_DEV_PXM )
+{
+uint32_t pxm;
+int optarr_off = offsetof(struct physdev_pci_device_add, optarr) /
+ sizeof(add.optarr[0]);
+
+if ( copy_from_guest_offset(pxm, arg, optarr_off, 1) )
+break;
+
+node = pxm_to_node(pxm);
+}
+else
+node = NUMA_NO_NODE;
+
+ret = pci_add_device(add.seg, add.bus, add.devfn, pdev_info, node);
break;
}
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 78c6977..3002129 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -568,7 +568,8 @@ static void pci_enable_acs(struct pci_dev *pdev)
pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
}
-int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *info)
+int pci_add_device(u16 seg, u8 bus, u8 devfn,
+ const struct pci_dev_info *info, int node)
{
struct pci_seg *pseg;
struct pci_dev *pdev;
@@ -586,7 +587,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct
pci_dev_info *info)
pdev = pci_get_pdev(seg, info-physfn.bus, info-physfn.devfn);
spin_unlock(pcidevs_lock);
if ( !pdev )
-pci_add_device(seg, info-physfn.bus, info-physfn.devfn, NULL);
+pci_add_device(seg, info-physfn.bus, info-physfn.devfn,
+ NULL, node);
pdev_type = virtual function;
}
else
@@ -609,6 +611,8 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct
pci_dev_info *info)
if ( !pdev )
goto out;
+pdev-node = node;
+
if ( info )
pdev-info = *info;
else if ( !pdev-vf_rlen[0] )
@@ -1191,10 +1195,11 @@ static int _dump_pci_devices(struct pci_seg *pseg, void
*arg)
list_for_each_entry ( pdev, pseg-alldevs_list, alldevs_list )
{
-printk(%04x:%02x:%02x.%u - dom %-3d - MSIs ,
+printk(%04x:%02x:%02x.%u - dom %-3d - node %-3d - MSIs ,
pseg-nr, pdev-bus,
PCI_SLOT(pdev-devfn), PCI_FUNC(pdev-devfn),
- pdev-domain ? pdev-domain-domain_id : -1);
+ pdev-domain ? pdev-domain-domain_id : -1,
+ (pdev-node != NUMA_NO_NODE) ? pdev-node : -1);
list_for_each_entry ( msi, pdev-msi_list, list )
printk(%d , msi-irq);
printk(\n);
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index d547928..309346b 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -293,6 +293,12 @@ struct physdev_pci_device_add {
uint8_t bus;
uint8_t devfn;
} physfn;
+
+/*
+ * Optional parameters array.
+ * First element ([0]) is PXM domain associated with the device
[Xen-devel] [PATCH v2 0/4] Display IO topology when PXM data is available
Changes in v2: * Split topology sysctls into two --- one for CPU topology and the other for devices * Avoid long loops in the hypervisor by using continuations. (I am not particularly happy about using first_dev in the interface, suggestions for a better interface would be appreciated) * Use proper libxl conventions for interfaces * Avoid hypervisor stack corruption when copying PXM data from guest 4 patches that add interface for querying hypervisor about device topology and allow 'xl info -n' display this information if PXM object is provided by ACPI. The patches are: * Store PXM data (nodeID) in pci_dev during PHYSDEVOP_pci_device_add hypercall * Modify XEN_SYSCTL_topologyinfo interface to make it a little more efficient. (This patch is not necessary for IO topology handling) * Add XEN_SYSCTL_pcitopoinfo sysctl for querying hypervisor about device topology * Make use of the above sysctl in libxl. Boris Ostrovsky (4): pci: Do not ignore device's PXM information sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient sysctl: Add sysctl interface for querying PCI topology libxl: Add interface for querying hypervisor about PCI topology tools/libxc/include/xenctrl.h |6 +- tools/libxc/xc_misc.c | 28 -- tools/libxl/libxl.c | 110 ++--- tools/libxl/libxl.h |4 + tools/libxl/libxl_freebsd.c | 12 tools/libxl/libxl_internal.h |5 ++ tools/libxl/libxl_linux.c | 71 tools/libxl/libxl_netbsd.c| 12 tools/libxl/libxl_types.idl |7 ++ tools/libxl/libxl_utils.c |8 +++ tools/libxl/xl_cmdimpl.c | 39 +++-- tools/misc/xenpm.c| 69 +-- tools/python/xen/lowlevel/xc/xc.c | 40 +- xen/arch/x86/physdev.c| 23 +++- xen/common/sysctl.c | 103 +-- xen/drivers/passthrough/pci.c | 13 +++- xen/include/public/physdev.h |6 ++ xen/include/public/sysctl.h | 75 +++-- xen/include/xen/pci.h |5 +- 19 files changed, 477 insertions(+), 159 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.
There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient
Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the fact
that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
tools/libxc/include/xenctrl.h |4 +-
tools/libxc/xc_misc.c | 10 +++---
tools/libxl/libxl.c | 52 ++-
tools/misc/xenpm.c| 69 ++--
tools/python/xen/lowlevel/xc/xc.c | 40 +++--
xen/common/sysctl.c | 47 +++--
xen/include/public/sysctl.h | 40 --
7 files changed, 117 insertions(+), 145 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0ad8b8d..0cb6743 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1226,7 +1226,7 @@ int xc_readconsolering(xc_interface *xch,
int xc_send_debug_keys(xc_interface *xch, char *keys);
typedef xen_sysctl_physinfo_t xc_physinfo_t;
-typedef xen_sysctl_topologyinfo_t xc_topologyinfo_t;
+typedef xen_sysctl_cputopoinfo_t xc_cputopoinfo_t;
typedef xen_sysctl_numainfo_t xc_numainfo_t;
typedef uint32_t xc_cpu_to_node_t;
@@ -1237,7 +1237,7 @@ typedef uint64_t xc_node_to_memfree_t;
typedef uint32_t xc_node_to_node_dist_t;
int xc_physinfo(xc_interface *xch, xc_physinfo_t *info);
-int xc_topologyinfo(xc_interface *xch, xc_topologyinfo_t *info);
+int xc_cputopoinfo(xc_interface *xch, xc_cputopoinfo_t *info);
int xc_numainfo(xc_interface *xch, xc_numainfo_t *info);
int xc_sched_id(xc_interface *xch,
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index e253a58..be68291 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -177,20 +177,20 @@ int xc_physinfo(xc_interface *xch,
return 0;
}
-int xc_topologyinfo(xc_interface *xch,
-xc_topologyinfo_t *put_info)
+int xc_cputopoinfo(xc_interface *xch,
+ xc_cputopoinfo_t *put_info)
{
int ret;
DECLARE_SYSCTL;
-sysctl.cmd = XEN_SYSCTL_topologyinfo;
+sysctl.cmd = XEN_SYSCTL_cputopoinfo;
-memcpy(sysctl.u.topologyinfo, put_info, sizeof(*put_info));
+memcpy(sysctl.u.cputopoinfo, put_info, sizeof(*put_info));
if ( (ret = do_sysctl(xch, sysctl)) != 0 )
return ret;
-memcpy(put_info, sysctl.u.topologyinfo, sizeof(*put_info));
+memcpy(put_info, sysctl.u.cputopoinfo, sizeof(*put_info));
return 0;
}
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 50a8928..cd87614 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5072,10 +5072,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo
*physinfo)
libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out)
{
GC_INIT(ctx);
-xc_topologyinfo_t tinfo;
-DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
-DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
-DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
+xc_cputopoinfo_t tinfo;
+DECLARE_HYPERCALL_BUFFER(xen_sysctl_cputopo_t, cputopo);
libxl_cputopology *ret = NULL;
int i;
int max_cpus;
@@ -5088,48 +5086,36 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx
*ctx, int *nb_cpu_out)
goto out;
}
-coremap = xc_hypercall_buffer_alloc
-(ctx-xch, coremap, sizeof(*coremap) * max_cpus);
-socketmap = xc_hypercall_buffer_alloc
-(ctx-xch, socketmap, sizeof(*socketmap) * max_cpus);
-nodemap = xc_hypercall_buffer_alloc
-(ctx-xch, nodemap, sizeof(*nodemap) * max_cpus);
-if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+cputopo = xc_hypercall_buffer_alloc(ctx-xch, cputopo,
+sizeof(*cputopo) * max_cpus);
+if (cputopo == NULL) {
LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
Unable to allocate hypercall arguments);
goto fail;
}
-
-set_xen_guest_handle(tinfo.cpu_to_core, coremap);
-set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
-set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
+set_xen_guest_handle(tinfo.cputopo, cputopo);
tinfo.max_cpu_index = max_cpus - 1;
-if (xc_topologyinfo(ctx-xch, tinfo) != 0) {
-LIBXL__LOG_ERRNO(ctx, XTL_ERROR, Topology info hypercall failed);
+
+if (xc_cputopoinfo(ctx-xch, tinfo) != 0) {
+LIBXL__LOG_ERRNO(ctx, XTL_ERROR, CPU topology info hypercall failed);
goto fail;
}
-if (tinfo.max_cpu_index max_cpus - 1)
-max_cpus = tinfo.max_cpu_index + 1;
+*nb_cpu_out = tinfo.max_cpu_index + 1;
+ret = libxl__zalloc(NOGC,
Re: [Xen-devel] [Testday]Xen 4.5 RC4
On Fri, 2015-01-02 at 16:47 +, Jan Beulich wrote: Boris Ostrovsky boris.ostrov...@oracle.com 12/26/14 9:12 PM On Thu, Dec 25, 2014 at 02:58:06AM +, Hu, Robert wrote: Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail. http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html This is regression introduced by abfb006f. And the referenced mail even contains a proposed fix - Robert, did you give this a try? Yes, we have verified it. It did fixed the issue. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para virtual machine
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Monday, January 05, 2015 8:53 PM
To: Xu, Quan
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
wei.l...@citrix.com
Subject: Re: [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para
virtual machine
On Tue, Dec 30, 2014 at 11:45:02PM -0500, Quan Xu wrote:
Signed-off-by: Quan Xu quan...@intel.com
---
tools/libxl/libxl_create.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..0a09925 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1358,8 +1358,9 @@ static void domcreate_attach_vtpms(libxl__egc
*egc,
goto error_out;
}
-/* Plug vtpm devices */
- if (d_config-num_vtpms 0) {
+ /* Plug vtpm devices for para virtual domain*/
+ if (d_config-num_vtpms 0
+ d_config-b_info.type == LIBXL_DOMAIN_TYPE_PV) {
It's unclear to me why you stub out HVM domain. You need to state your
reasoning in comment and commit log. :-/
In brief, it is different to plug vtpm device for HVM/PV domain. I will try to
describe more detailed in next v3. Thanks Wei.
Thanks
Quan Xu
Wei.
/* Attach vtpms */
libxl__multidev_begin(ao, dcs-multidev);
dcs-multidev.callback = domcreate_attach_pci;
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Parallel make supported?
root[xen-4.5.0-rc4]# ls -l tools/xenstore/libxenstore* -rw-r--r-- 1 root root 98580 Dec 19 22:02 tools/xenstore/libxenstore.a -rwxr-xr-x 1 root root 82624 Dec 19 22:02 tools/xenstore/libxenstore.so.3.0.3 Please see output of make -d -C tools/xenstore init-xenstore-domain attached - it's quite long uncompressed PK On 5 January 2015 at 16:01, Ian Campbell ian.campb...@citrix.com wrote: On Mon, 2014-12-29 at 13:01 +, Wei Liu wrote: Please don't top post. On Fri, Dec 19, 2014 at 10:09:31PM +, Peter Kay wrote: Thanks, see attached : This is on Salix 14.1 running the 3.17.4 kernel. That's not particularly relevant though, as I had exactly the same error on Debian using other kernel versions. Looking at your build log gcc -pthread -Wl,-soname -Wl,libxenstore.so.3.0 -shared -o libxenstore.so.3.0.3 xs.opic xs_lib.opic ar rcs libxenstore.a xs.o xs_lib.o gcc xs_tdb_dump.o utils.o tdb.o talloc.o -o xs_tdb_dump gcc xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_posix.o /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so -o xenstored gcc init-xenstore-domain.o libxenstore.so /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenctrl.so /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/libxc/libxenguest.so /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so -o init-xenstore-domain gcc: error: libxenstore.so: No such file or directory gcc: error: /home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore/../../tools/xenstore/libxenstore.so: No such file or directory make[4]: *** [init-xenstore-domain] Error 1 make[4]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools/xenstore' make[3]: *** [subdir-install-xenstore] Error 2 make[3]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools' make[2]: *** [subdirs-install] Error 2 make[2]: Leaving directory `/home/peter/Downloads/xen-4.5.0-rc4/tools' make[1]: *** [install-tools] Error 2 make[1]: *** Waiting for unfinished jobs libxenstore.so is missing. However Makefile dependency ensures the compilation of init-xenstore-domain does not proceed unless libxenstore.so exists. Right. Specifically (quoting a select few lines from tools/xenstore/Makefile): LIBXENSTORE := libxenstore.so init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE) libxenstore.so: libxenstore.so.$(MAJOR) libxenstore.so.$(MAJOR): libxenstore.so.$(MAJOR).$(MINOR) libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic So it would be a make bug if init-xenstore-domain were linked without having created libxenstore.so first, but that (such an obvious bug in make) doesn't seem very likely. Peter, what does ls -l tools/xenstore/libxenstore* show? Also make -d -C tools/xenstore init-xenstore-domain might give a clue as to why make thinks it doesn't need to rebuild those objects. If $(LIBXENSTORE) were unset then that might explain things, but I can't see how that could happen, it must always be either libxenstore.so or libxenstore.a. Changing the init-xenstore-domain rule to: init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE) @echo init-xenstore-domain using $(LIBXENSTORE) $(CC) $^ $(LDFLAGS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS) would confirm or deny that theory (nb before @echo needs to be a hard tab). Ian. xsdm.gz Description: GNU Zip compressed data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt bisection] complete build-amd64-libvirt
branch xen-unstable xen branch xen-unstable job build-amd64-libvirt test libvirt-build Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] Tree: libvirt git://libvirt.org/libvirt.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] Bug introduced: b9bfe78424b871f5b92e5ee9e7d21ef951a6801d Bug not present: bd86632bd0a614a4195e38ae376893432fcaec3b commit b9bfe78424b871f5b92e5ee9e7d21ef951a6801d Author: Paul Eggert egg...@cs.ucla.edu Date: Thu Jan 1 01:38:23 2015 + version-etc: new year * doc/gnulib.texi: * lib/version-etc.c (COPYRIGHT_YEAR): Update copyright date. * all files: Run 'make update-copyright'. For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.libvirt.build-amd64-libvirt.libvirt-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 33117 fail [host=rice-weevil] / 32648 [host=field-cricket] 32617 [host=field-cricket] 32596 [host=scape-moth] 32576 [host=bush-cricket] 32555 [host=field-cricket] 32534 [host=scape-moth] 32508 [host=scape-moth] 32471 [host=scape-moth] 32433 [host=scape-moth] 32414 [host=bush-cricket] 32351 [host=field-cricket] 32330 [host=field-cricket] 32308 [host=moss-bug] 32272 [host=grain-weevil] 32217 [host=worm-moth] 32137 [host=field-cricket] 32005 [host=bush-cricket] 31928 [host=bush-cricket] 31860 [host=scape-moth] 31852 [host=field-cricket] 31839 ok. Failure / basis pass flights: 33117 / 31839 (tree with no url: seabios) Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] Tree: libvirt git://libvirt.org/libvirt.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest 498a1b6bc7d70f944ca0f939e1bc470889fdce76 262d913ffc6a20ceafbf4ba2f174854a0a583805 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b Basis pass 624ea2886cc570788cb01c4fd59315de301b0cd6 1fd83607514eda8e7331cba39f83d51fb9e565c9 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51 6913fa31fa898f45ecc3b00e2397b8ebc75c8df4 Generating revisions with ./adhoc-revtuple-generator git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#624ea2886cc570788cb01c4fd59315de301b0cd6-498a1b6bc7d70f944ca0f939e1bc470889fdce76 git://libvirt.org/libvirt.git#1fd83607514eda8e7331cba39f83d51fb9e565c9-262d913ffc6a20ceafbf4ba2f174854a0a583805 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#0c94ca5ffeb6d314404ecbc231bef28fe8d3fc51-1ebb75b1fee779621b63e84fefa7b07354c43a99 git://xenbits.xen.org/xen.git#6913fa31fa898f45ecc3b00e2397b8ebc75c8df4-36174af3fbeb1b662c0eadbfa193e77f68cc955b + exec + sh -xe + cd /export/home/osstest/repos/gnulib + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/libvirt + git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/qemu-upstream-unstable + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/xen + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/gnulib + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/libvirt + git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/qemu-upstream-unstable + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/staging/qemu-upstream-unstable.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On Mon, 5 Jan 2015 15:35:27 + Andrew Cooper andrew.coop...@citrix.com wrote: On 05/01/15 15:16, Ian Campbell wrote: On Fri, 2015-01-02 at 19:12 +, Andrew Cooper wrote: supervisor_mode_kernel was an x86_32-only feature which permitted a PV dom0 to run in ring 0, but at the expense of not being able to start any domUs. As the x86_32 Xen build has been removed from tree, removing the remaining supervisor_mode_kernel code. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Ian Campbell ian.campb...@citrix.com CC: Stefano Stabellini stefano.stabell...@citrix.com CC: Tim Deegan t...@xen.org --- One complication is that PVH has reused XENFEAT_supervisor_mode_kernel with a modified meaning, and the Linux PVH code actively uses the flag as to indicate running as a PVH guest. What is the modification? Doesn't a PVH kernel just use it to indicate that it should (or wants) run in ring0 instead of ring1/ring3? That was the original intention IIRC. That flag has confused me too, and it was added later to pvh. Since, PVH guest is able to run in ring 0 ir-respective of the flag, imho, XENFEAT_supervisor_mode_kernel can be just removed. The important ones are really: XENFEAT_auto_translated_physmap XENFEAT_hvm_callback_vector thanks Mukesh ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine
-Original Message- From: Wei Liu [mailto:wei.l...@citrix.com] Sent: Monday, January 05, 2015 9:19 PM To: Xu, Quan Cc: xen-devel@lists.xen.org; dgde...@tycho.nsa.gov; samuel.thiba...@ens-lyon.org; ian.jack...@eu.citrix.com; stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com; wei.l...@citrix.com Subject: Re: [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine FWIW in the future please configure git to chain all your patches to one thread. :-) What I usually do is to git format-patch HEAD~NNN --cover --subject-prefix='PATCH vXX' ... edit -cover-letter.patch ... git send-email --to xen-devel@ --cc XXX All patches will be chained to 00/00 cover letter. Thanks. I tried for a lot of times, I will ask some opensource veteran to help me. I hope I can do right in next v3. Quan Thanks Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine
-Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: Monday, January 05, 2015 9:21 PM To: Xu, Quan Cc: xen-devel@lists.xen.org; dgde...@tycho.nsa.gov; samuel.thiba...@ens-lyon.org; ian.jack...@eu.citrix.com; stefano.stabell...@eu.citrix.com; wei.l...@citrix.com Subject: Re: [PATCH v2 0/5] vTPM: Xen stubdom vTPM for HVM virtual machine On Tue, 2014-12-30 at 23:44 -0500, Quan Xu wrote: Please can you arrange for you patch submissions to be correctly threaded i.e. with all the mails containing a reference header either to the previous patch or to the 0/N introductory patch. Take a look at the --chainreplyto and --thread options to git send-email. If you use --dry-run then you should see each mail has a suitable References: header if you have got it right. Without this I end up with N+1 unrelated email in my INBOX which are very hard to keep straight as a series once people start commenting on a subset. Thanks, Ian. Thanks. I tried for a lot of times, I will ask some opensource veteran to help me. I really didn't understand it before you tell me. Thanks Quan Xu This patch series are only the Xen part to enable stubdom vTPM for HVM virtual machine. it will work w/ Qemu patch series and seaBios patch series. Change QEMU_STUBDOM_VTPM compile option from 'n' to 'y', when the Qemu/SeaBios patch series are merged. *INTRODUCTION* The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This allows programs to interact with a TPM in a virtual machine the same way they interact with a TPM on the physical system. Each virtual machine gets its own unique, emulated, software TPM. Each major component of vTPM is implemented as a stubdom, providing secure separation guaranteed by the hypervisor. The vTPM stubdom is a Xen mini-OS domain that emulates a TPM for the virtual machine to use. It is a small wrapper around the Berlios TPM emulator. TPM commands are passed from mini-os TPM backend driver. *ARCHITECTURE* The architecture of stubdom vTPM for HVM virtual machine: ++ | Windows/Linux DomU | ... || ^| |v || | Qemu tpm1.2 Tis | || ^| |v || | XenStubdoms backend| ++ | ^ v | ++ | XenDevOps | ++ | ^ v | ++ | mini-os/tpmback | || ^| |v || | vtpm-stubdom | ... || ^| |v || | mini-os/tpmfront | ++ | ^ v | ++ | mini-os/tpmback | || ^| |v || | vtpmmgr-stubdom | || ^| |v || | mini-os/tpm_tis | ++ | ^ v | ++ |Hardware TPM| ++ * Windows/Linux DomU: The HVM based guest that wants to use a vTPM. There may be more than one of these. * Qemu tpm1.2 Tis: Implementation of the tpm1.2 Tis interface for HVM virtual machines. It is Qemu emulation device. * vTPM xenstubdoms driver: Qemu vTPM driver. This driver provides vtpm initialization and sending data and commends to a para-virtualized vtpm stubdom. * XenDevOps: Register Xen stubdom vTPM frontend driver, and transfer any request/repond between TPM xenstubdoms driver and Xen vTPM stubdom. Facilitate communications between Xen vTPM stubdom and vTPM xenstubdoms driver. * mini-os/tpmback: Mini-os TPM backend driver. The Linux frontend driver connects to this backend driver to facilitate communications between the Linux DomU and its vTPM. This driver is also used by vtpmmgr stubdom to communicate with vtpm-stubdom. * vtpm-stubdom: A mini-os stub domain that implements a vTPM. There is a one to one mapping between running vtpm-stubdom instances and logical vtpms on the system. The vTPM Platform Configuration Registers (PCRs) are all initialized to zero. *
[Xen-devel] [linux-3.10 test] 33120: regressions - FAIL
flight 33120 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33120/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 26303 build-i386-libvirt5 libvirt-build fail REGR. vs. 26303 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 26303 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: linuxa472efc75989c7092187fe00f0400e02c495c436 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 816 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64
Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Thursday, December 11, 2014 7:44 PM
To: Pang, LongtaoX
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di
Subject: Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
From: longtao.pang longtaox.p...@intel.com
This patch is used for installing L2 guest VM inside L1 guest VM.
---
sg-run-job|2 +
ts-debian-install | 166
+
2 files changed, 132 insertions(+), 36 deletions(-)
diff --git a/sg-run-job b/sg-run-job
index e513bd1..85f7b22 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -292,6 +292,8 @@ proc need-hosts/test-nested {} {return host} proc
run-job/test-nested {} {
run-ts . = ts-debian-hvm-install + host + nested + nested_L1
run-ts . = ts-xen-install + host + nested + nested_build
+run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
+run-ts . = ts-guest-destroy + host nested
It would also be possible to run ts-debian-hvm-install as L2. That would suite
this test case better -- it's testing nested HVM.
There's no need to remove the PV test case though.
[Pang, LongtaoX]
[Pang, LongtaoX] Thanks for checking. We used ts-debian-hvm-install for
installing L1 HVM guest via ISO Image,
because we will build XEN, XEN-Tools and dom0 kernel inside it, and then we
will install L2 guest inside L1.
But, L2 guest is just a native OS, so we think use ts-debian-install is enough
for installing L2 and will make it easy to control.
}
proc test-guest-migr {g} {
diff --git a/ts-debian-install b/ts-debian-install index
58ea743..2ca54e8 100755
--- a/ts-debian-install
+++ b/ts-debian-install
@@ -22,41 +22,61 @@ use Osstest::TestSupport;
tsreadconfig();
-our ($whhost,$gn) = @ARGV;
-$whhost ||= 'host';
-$gn ||= 'debian';
+our ($whhost,$gn,$arch,$nested_L2) = @ARGV;
+$nested_L2 ||= '';
-our $ho= selecthost($whhost);
+if($nested_L2 eq 'nested_L2') {
+my $L1_IP = get_VM_IP($r{'nested_ether'});
+$whhost = host=$L1_IP;
+$gn ||= 'nested';
+$arch ||= 'amd64';
+} else {
+$whhost ||= 'host';
+$gn ||= 'debian';
+}
+our $ho= selecthost($whhost);
our $ram_mb=512;
our $swap_mb= 1000;
our $disk_mb= 1;
-
Stray blank line.
our $guesthost= $gn.guest.osstest;
our $gho;
+our $L2_MAC = select_ether($ho,L2_ether);
sub prep () {
target_install_packages_norec($ho, qw(lvm2 xen-tools));
-
-$gho= prepareguest($ho, $gn, $guesthost, 22,
- $swap_mb + $disk_mb + 2,
- 40);
-target_cmd_root($ho, umount $gho-{Lvdev} ||:);
+unless($nested_L2 eq 'nested_L2') {
+ $gho= prepareguest($ho, $gn, $guesthost, 22,
+ $swap_mb + $disk_mb + 2,
+ 40);
+ target_cmd_root($ho, umount $gho-{Lvdev} ||:);
+}
}
sub ginstall () {
-my $arch= $r{$gho-{Guest}_arch};
+my $gsuite;
+my $kernpath;
+my $initrd;
+my $kernver;
+if($nested_L2 eq 'nested_L2'){
+my $suite= $c{DebianSuite};
+$gsuite= defined($suite) ? --dist=$suite : '';
+$kernver ||= target_cmd_output_root($ho, 'uname -r');
+$kernpath = /boot/vmlinuz-$kernver;
+$initrd ||= /boot/initrd.img-$kernver;
+} else {
+my $arch= $r{$gho-{Guest}_arch};
+$gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
+$kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
+$initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
+if (!$kernpath) {
+ $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
+$kernver ||= target_cmd_output($ho, 'uname -r');
+ $kernpath = /boot/vmlinuz-$kernver;
+ $initrd ||= /boot/initrd.img-$kernver;
+}
+}
To be honest, this looks convoluted. Special casing needs better explanation.
[Pang, LongtaoX] Thanks for checking, I will try to adjust it.
my $archarg= defined($arch) ? --arch $arch : '';
-my $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
-
-my $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
-my $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
-if (!$kernpath) {
- my $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
- $kernver ||= target_cmd_output($ho, 'uname -r');
- $kernpath = /boot/vmlinuz-$kernver;
- $initrd ||= /boot/initrd.img-$kernver;
-}
if (!$initrd) {
$initrd = $kernpath;
$initrd =~ s,/vmlinuz-,/initrd.img-, or die $initrd ?; @@ -76,23
+96,97 @@ sub ginstall () {
fi
END
}
-target_cmd_root($ho,
Re: [Xen-devel] [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Thursday, December 11, 2014 7:46 PM
To: Pang, LongtaoX
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di
Subject: Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
On Wed, Dec 10, 2014 at 04:07:40PM +0800, longtao.pang wrote:
From: longtao.pang longtaox.p...@intel.com
This patch is used for inserting nested test job name and runvars into
standalone.db database after execute command './standalone-reset'.
---
make-flight | 19 +++
mfi-common |8
2 files changed, 27 insertions(+)
diff --git a/make-flight b/make-flight index 9963a46..fe64237 100755
--- a/make-flight
+++ b/make-flight
@@ -197,6 +197,24 @@ do_hvm_win7_x64_tests () {
all_hostflags=$most_hostflags,hvm }
+do_hvm_debian_nested_tests () {
+ if [ $xenarch != amd64 ]; then
+return
+ fi
+ if [ $dom0arch != amd64 ]; then
+return
+ fi
+
+ job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
+ $xenarch $dom0arch \
+nested_image=debian-7.6.0-amd64-DVD-1.iso \
+ bios=seabios \
+ kernbuildjob=build-amd64-hvm \
+ kernkind=hvm \
+ device_model_version=qemu-xen \
+all_hostflags=$most_hostflags,hvm }
+
do_hvm_debian_test_one () {
testname=$1
bios=$2
@@ -364,6 +382,7 @@ test_matrix_do_one () {
fi
+ do_hvm_debian_nested_tests
do_passthrough_tests
}
diff --git a/mfi-common b/mfi-common
index 5c4f5d5..b65f0b5 100644
--- a/mfi-common
+++ b/mfi-common
@@ -166,6 +166,14 @@ create_build_jobs () {
revision_qemu=$REVISION_QEMU
\
revision_qemuu=$REVISION_QEMU_UPSTREAM
fi
+./cs-job-create $flight build-$arch-hvm build-kern
\
+arch=$arch kconfighow=xen-enable-xen-config
\
+$RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS
$arch_runvars \
+$suite_runvars
\
+host_hostflags=$build_hostflags
\
+revision_linux=v3.16
\
+
tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
\
Please don't hard code tree and revision.
You can specify tree and revision in you test configuration.
Wei.
[Pang, LongtaoX] Thanks for checking, I will try to modify it.
+${TREEVCS_LINUX:+treevcs_linux=}${TREEVCS_LINUX}
./cs-job-create $flight build-$arch-pvops build-kern
\
arch=$arch kconfighow=xen-enable-xen-config
\
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64
branch xen-unstable xen branch xen-unstable job test-amd64-i386-xl-qemuu-ovmf-amd64 test debian-hvm-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://git.qemu.org/qemu.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 Bug not present: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 Author: Marcel Apfelbaum marce...@redhat.com Date: Tue Dec 16 16:58:05 2014 + machine: remove qemu_machine_opts global list QEMU has support for options per machine, keeping a global list of options is no longer necessary. Signed-off-by: Marcel Apfelbaum marce...@redhat.com Reviewed-by: Alexander Graf ag...@suse.de Reviewed-by: Greg Bellows greg.bell...@linaro.org Message-id: 1418217570-15517-2-git-send-email-marce...@redhat.com Signed-off-by: Peter Maydell peter.mayd...@linaro.org For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.qemu-mainline.test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 33111 fail [host=grain-weevil] / 32598 [host=potato-beetle] 32585 [host=scape-moth] 32571 [host=leaf-beetle] 32561 [host=leaf-beetle] 32542 [host=rice-weevil] 32517 [host=bush-cricket] 32459 [host=moss-bug] 32429 [host=lace-bug] 32418 [host=itch-mite] 32294 ok. Failure / basis pass flights: 33111 / 32294 (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://git.qemu.org/qemu.git Tree: xen git://xenbits.xen.org/xen.git Latest 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ab0302ee764fd702465aef6d88612cdff4302809 36174af3fbeb1b662c0eadbfa193e77f68cc955b Basis pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b141290478f847ecaa25561f3b31fbf1ddde95e6 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#356a3e1fde11190febb8ace3cdab8694848ed220-83a926f7a4e39fb6be0576024e67fe161593defa git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://git.qemu.org/qemu.git#b141290478f847ecaa25561f3b31fbf1ddde95e6-ab0302ee764fd702465aef6d88612cdff4302809 git://xenbits.xen.org/xen.git#2a549b9c8aa48dc39d7c97e5a93978b781b3a1db-36174af3fbeb1b662c0eadbfa193e77f68cc955b + exec + sh -xe + cd /export/home/osstest/repos/linux-pvops + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/qemu + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/xen + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/linux-pvops + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/qemu + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.qemu.org/qemu.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/xen + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* Loaded 11036 nodes in revision graph Searching for test results: 32294 pass 356a3e1fde11190febb8ace3cdab8694848ed220 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 b141290478f847ecaa25561f3b31fbf1ddde95e6 2a549b9c8aa48dc39d7c97e5a93978b781b3a1db 32377 [] 32418 [host=itch-mite] 32429 [host=lace-bug] 32517 [host=bush-cricket] 32459 [host=moss-bug] 32542 [host=rice-weevil] 32572 [host=leaf-beetle] 32583 [host=leaf-beetle] 32571 [host=leaf-beetle] 32561
[Xen-devel] [linux-linus test] 33115: regressions - FAIL
flight 33115 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33115/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 32879 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 32879 build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32879 Regressions which are regarded as allowable (not blocking): test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 32879 test-amd64-i386-freebsd10-amd64 7 freebsd-install fail like 32879 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 32879 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 32879 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass version targeted for testing: linux693a30b8f19a964087a3762d09fb2e1cbad6b0d4 baseline version: linux9bb29b6b927bcd79cf185ee67bcebfe630f0dea1 People who touched revisions under test: Alan Stern st...@rowland.harvard.edu Andrew Jackson andrew.jack...@arm.com Anil Chintalapati (achintal) achin...@cisco.com Anil Chintalapati achin...@cisco.com Christoph Hellwig h...@lst.de Daniel Borkmann dbork...@redhat.com Daniel Walter d.wal...@0x90.at Fang, Yang A yang.a.f...@intel.com Hannes Reinecke h...@suse.de Herbert Xu herb...@gondor.apana.org.au Hiral Shah his...@cisco.com James Bottomley jbottom...@parallels.com Jarkko Nikula jarkko.nik...@linux.intel.com Jianqun Xu jay...@rock-chips.com Jie Yang yang@intel.com Lars-Peter Clausen l...@metafoo.de Ley Foon Tan lf...@altera.com Linus Torvalds torva...@linux-foundation.org Mark Brown broo...@kernel.org Martin K. Petersen martin.peter...@oracle.com Michael S. Tsirkin m...@redhat.com Ming Lei ming@canonical.com Paolo Bonzini pbonz...@redhat.com Paul Moore pmo...@redhat.com Pavel Machek pa...@ucw.cz Rabin Vincent rabin.vinc...@axis.com Randy Dunlap rdun...@infradead.org Richard Weinberger rich...@nod.at Russell King rmk+ker...@arm.linux.org.uk Rusty Russell ru...@rustcorp.com.au Sesidhar Baddela sebad...@cisco.com Takashi Iwai ti...@suse.de Tobias Klauser tklau...@distanz.ch Walter Goossens waltergooss...@home.nl ÐндÑей ÐладÑев aladjev.and...@gmail.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl
[Xen-devel] Xen 4.5 Development Update (GA slip by a week)
Xen 4.5-rc4 was out on Monday (Dec 15th). The GA General Release is on Jan 7th^H^H^14th! There are some outstanding patches on which we need to figure out whether we will commit them in or not. When we commit a patch in, the OSSTest takes a day or so to push it to 'master' - and if it fails during that time patches that are later in the sequence are not applied. Hence if everything works out great - we get the patches to show up next day - however if something breaks - we are stalled. Ian(s) has pointed to me that the OSSTest is sometimes on the fritz and that it might take more than one day to push patches through which means we won't make it by Wednesday. As such, moving it the release by a week to give us ample room to get through those changes. These are the patches that need to be investigated whether they should go in or not: VT-d: don't crash when PTE bits 52 and up are non-zero VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell) VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2 x86/VPMU: Clear last_vcpu when destroying VPMU tools/hotplug: add wrapper to start xenstored tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service tools/hotplug: xendomains.service depends on network tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service tools/hotplug: remove SELinux options from var-lib-xenstored.mount tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ss xen: arm: correct off-by-one error in consider_module = Timeline = Xen 4.5 is a 10 month release. The dates are: * Feature Freeze: 24th September 2014 * First RC: 24th October [Friday!] * RC2: Nov 11th * RC2 Test-day: Nov 13th * RC3: Dec 3rd. * RC3 Test-day: Dec 4th * RC4: Dec 15th * RC4 Test-day: Dec 17th WE ARE HERE === Release Date: Jan 14th. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v16 15/23] x86/VPMU: Initialize PMU for PV(H) guests
On 12/17/2014 10:38 AM, Boris Ostrovsky wrote: Code for initializing/tearing down PMU for PV guests Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Acked-by: Kevin Tian kevin.t...@intel.com Acked-by: Jan Beulich jbeul...@suse.com Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Reviewed-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure TSC
implementation.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 82
--
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info
*get_pvti(int cpu)
static notrace cycle_t vread_pvclock(int *mode)
{
- const struct pvclock_vsyscall_time_info *pvti;
+ const struct pvclock_vcpu_time_info *pvti = get_pvti(0)-pvti;
cycle_t ret;
- u64 last;
- u32 version;
- u8 flags;
- unsigned cpu, cpu1;
-
+ u64 tsc, pvti_tsc;
+ u64 last, delta, pvti_system_time;
+ u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
/*
- * Note: hypervisor must guarantee that:
- * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
- * 2. that per-CPU pvclock time info is updated if the
- *underlying CPU changes.
- * 3. that version is increased whenever underlying CPU
- *changes.
+ * Note: The kernel and hypervisor must guarantee that cpu ID
+ * number maps 1:1 to per-CPU pvclock time info.
+ *
+ * Because the hypervisor is entirely unaware of guest userspace
+ * preemption, it cannot guarantee that per-CPU pvclock time
+ * info is updated if the underlying CPU changes or that that
+ * version is increased whenever underlying CPU changes.
+ *
+ * On KVM, we are guaranteed that pvti updates for any vCPU are
+ * atomic as seen by *all* vCPUs. This is an even stronger
+ * guarantee than we get with a normal seqlock.
*
+ * On Xen, we don't appear to have that guarantee, but Xen still
+ * supplies a valid seqlock using the version field.
+
+ * We only do pvclock vdso timing at all if
+ * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+ * mean that all vCPUs have matching pvti and that the TSC is
+ * synced, so we can just look at vCPU 0's pvti.
*/
Can Xen guarantee that ?
I think so, vacuously. Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
at all. I have no idea going forward, though.
Xen people?
- do {
- cpu = __getcpu() VGETCPU_CPU_MASK;
- /* TODO: We can put vcpu id into higher bits of pvti.version.
- * This will save a couple of cycles by getting rid of
- * __getcpu() calls (Gleb).
- */
-
- pvti = get_pvti(cpu);
-
- version = __pvclock_read_cycles(pvti-pvti, ret, flags);
-
- /*
- * Test we're still on the cpu as well as the version.
- * We could have been migrated just after the first
- * vgetcpu but before fetching the version, so we
- * wouldn't notice a version change.
- */
- cpu1 = __getcpu() VGETCPU_CPU_MASK;
- } while (unlikely(cpu != cpu1 ||
- (pvti-pvti.version 1) ||
- pvti-pvti.version != version));
-
- if (unlikely(!(flags PVCLOCK_TSC_STABLE_BIT)))
+
+ if (unlikely(!(pvti-flags PVCLOCK_TSC_STABLE_BIT))) {
*mode = VCLOCK_NONE;
+ return 0;
+ }
This check must be performed after reading a stable pvti.
We can even read it in the middle, guarded by the version checks.
I'll do that for v2.
+
+ do {
+ version = pvti-version;
+
+ /* This is also a read barrier, so we'll read version first. */
+ rdtsc_barrier();
+ tsc = __native_read_tsc();
+
+ pvti_tsc_to_system_mul = pvti-tsc_to_system_mul;
+ pvti_tsc_shift = pvti-tsc_shift;
+ pvti_system_time = pvti-system_time;
+ pvti_tsc = pvti-tsc_timestamp;
+
+ /* Make sure that the version double-check is last. */
+ smp_rmb();
+ } while (unlikely((version 1) || version != pvti-version));
+
+ delta = tsc - pvti_tsc;
+ ret = pvti_system_time +
+ pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
+ pvti_tsc_shift);
The following is possible:
1) State: all pvtis marked as
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On Fri, 2015-01-02 at 19:12 +, Andrew Cooper wrote: supervisor_mode_kernel was an x86_32-only feature which permitted a PV dom0 to run in ring 0, but at the expense of not being able to start any domUs. As the x86_32 Xen build has been removed from tree, removing the remaining supervisor_mode_kernel code. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Ian Campbell ian.campb...@citrix.com CC: Stefano Stabellini stefano.stabell...@citrix.com CC: Tim Deegan t...@xen.org --- One complication is that PVH has reused XENFEAT_supervisor_mode_kernel with a modified meaning, and the Linux PVH code actively uses the flag as to indicate running as a PVH guest. What is the modification? Doesn't a PVH kernel just use it to indicate that it should (or wants) run in ring0 instead of ring1/ring3? That was the original intention IIRC. Regardless, supervisor_mode_kernel was never anything more than a prototype, I'm pretty certain there can be no kernels out there relying on it, so rather than breaking pvh dom0 as you seem to do here I think it would be better to retcon the meaning of the flag as needed. This causes an discontinuity between PVH and HVM guests, both of which run their kernels with the PVH-taken meaning of XENFEAT_supervisor_mode_kernel. It also means that a dom0 kernel is unable to express PVH-only by requiring this feature, as a 64bit Xen will validly reject an attempt to require a 32bit-only Xen feature. I wouldn't describe XENFEAT_supervisor_mode_kernel as a 32-bit only Xen feature. It was only ever implemented for 32-bit, but conceptually it isn't specific to 32-bit but to any setup where PV requires you to run the kernel at a lower then normal privilege level. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] patch ping
On Fri, Dec 19, 2014 at 01:13:41PM -0500, Konrad Rzeszutek Wilk wrote: On Fri, Dec 19, 2014 at 01:48:18PM +, Jan Beulich wrote: Konrad, any word on http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01253.html Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01370.html Shouldn't that have Reported-by: Sander..? Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01485.html Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com sent several days ago (there were more earlier today) for 4.5? Thanks, Jan Pushed to staging with the Release, Reviewed, Acked, etc tags applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86/xen: avoid freeing static 'name' when kasprintf() fails
In case kasprintf() fails in xen_setup_timer() we assign name to the static
string timer kasprintf failed. We, however, don't check that fact before
issuing kfree() in xen_teardown_timer(), kernel is supposed to crash with
'kernel BUG at mm/slub.c:3341!'
Solve the issue by making name a fixed length string inside struct
xen_clock_event_device. 16 bytes should be enough.
Suggested-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes from v1 (David Vrabel):
- add 'struct xen_clock_event_device *xevt' for covenience
- sizeof(xevt-name) in snprintf() call
- Suggested-by: Laszlo Ersek
---
arch/x86/xen/time.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index f473d26..9f743f4 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -391,7 +391,7 @@ static const struct clock_event_device *xen_clockevent =
struct xen_clock_event_device {
struct clock_event_device evt;
- char *name;
+ char name[16];
};
static DEFINE_PER_CPU(struct xen_clock_event_device, xen_clock_events) = {
.evt.irq = -1 };
@@ -420,39 +420,33 @@ void xen_teardown_timer(int cpu)
if (evt-irq = 0) {
unbind_from_irqhandler(evt-irq, NULL);
evt-irq = -1;
- kfree(per_cpu(xen_clock_events, cpu).name);
- per_cpu(xen_clock_events, cpu).name = NULL;
}
}
void xen_setup_timer(int cpu)
{
- char *name;
- struct clock_event_device *evt;
+ struct xen_clock_event_device *xevt = per_cpu(xen_clock_events, cpu);
+ struct clock_event_device *evt = xevt-evt;
int irq;
- evt = per_cpu(xen_clock_events, cpu).evt;
WARN(evt-irq = 0, IRQ%d for CPU%d is already allocated\n, evt-irq,
cpu);
if (evt-irq = 0)
xen_teardown_timer(cpu);
printk(KERN_INFO installing Xen timer for CPU %d\n, cpu);
- name = kasprintf(GFP_KERNEL, timer%d, cpu);
- if (!name)
- name = timer kasprintf failed;
+ snprintf(xevt-name, sizeof(xevt-name), timer%d, cpu);
irq = bind_virq_to_irqhandler(VIRQ_TIMER, cpu, xen_timer_interrupt,
IRQF_PERCPU|IRQF_NOBALANCING|IRQF_TIMER|
IRQF_FORCE_RESUME|IRQF_EARLY_RESUME,
- name, NULL);
+ xevt-name, NULL);
(void)xen_set_irq_priority(irq, XEN_IRQ_PRIORITY_MAX);
memcpy(evt, xen_clockevent, sizeof(*evt));
evt-cpumask = cpumask_of(cpu);
evt-irq = irq;
- per_cpu(xen_clock_events, cpu).name = name;
}
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5] tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ssid_label
On Mon, Jan 05, 2015 at 02:19:58PM +, Andrew Cooper wrote:
libxl_dominfo contains a ssid_label pointer which will have memory allocated
for it in libxl_domain_info() if the hypervisor has CONFIG_XSM compiled.
However, the lack of appropriate use of libxl_dominfo_{init,dispose}() will
cause the label string to be leaked, even in success cases.
This was discovered by XenServers Coverity scanning, and are issues not
identified by upstream Coverity Scan.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Requesting a release-exception as suggested by IanJ. These are memory leaks
which accumulate via the successful completion of libxl library functions (if
XSM is enabled), which will undoubtedly cause issues for the likes of libvirt
and xenopsd-libxl which use libxl in daemon processes.
Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
As we are very close to the release, I have opted for the more
obviously-correct code rather than the pragmatically better code, particularly
in two locations where libxl_domain_info() is called in a loop, and the
dispose()/init() pair is required to prevent leaking the allocation on each
iteration.
All of the uses of libxl_domain_info() patched here could better be an
xc_dominfo_getlist() which reduces the quantity of hypercalls made, and the
amount of data transformation done behind the scenes.
---
tools/libxl/libxl.c | 26 --
tools/libxl/libxl_dom.c | 14 ++
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 50a8928..372dd3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -364,6 +364,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
char *uuid;
const char *vm_name_path;
+libxl_dominfo_init(info);
+
dom_path = libxl__xs_get_dompath(gc, domid);
if (!dom_path) goto x_nomem;
@@ -481,6 +483,7 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
rc = 0;
x_rc:
if (our_trans) xs_transaction_end(ctx-xsh, our_trans, 1);
+libxl_dominfo_dispose(info);
return rc;
x_fail: rc = ERROR_FAIL; goto x_rc;
@@ -4594,6 +4597,8 @@ static int libxl__fill_dom0_memory_info(libxl__gc *gc,
uint32_t *target_memkb,
libxl_ctx *ctx = libxl__gc_owner(gc);
uint32_t free_mem_slack_kb = 0;
+libxl_dominfo_init(info);
+
retry_transaction:
t = xs_transaction_start(ctx-xsh);
@@ -4626,6 +4631,8 @@ retry_transaction:
}
}
+libxl_dominfo_dispose(info);
+libxl_dominfo_init(info);
rc = libxl_domain_info(ctx, info, 0);
if (rc 0)
goto out;
@@ -4664,7 +4671,7 @@ out:
rc = ERROR_FAIL;
}
-
+libxl_dominfo_dispose(info);
return rc;
}
@@ -4999,6 +5006,8 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx,
uint32_t domid, int wait_secs)
uint32_t target_memkb = 0;
libxl_dominfo info;
+libxl_dominfo_init(info);
+
do {
wait_secs--;
sleep(1);
@@ -5007,9 +5016,11 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx,
uint32_t domid, int wait_secs)
if (rc 0)
goto out;
+libxl_dominfo_dispose(info);
+libxl_dominfo_init(info);
rc = libxl_domain_info(ctx, info, domid);
if (rc 0)
-return rc;
+goto out;
} while (wait_secs 0 (info.current_memkb + info.outstanding_memkb)
target_memkb);
if ((info.current_memkb + info.outstanding_memkb) = target_memkb)
@@ -5018,6 +5029,7 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx,
uint32_t domid, int wait_secs)
rc = ERROR_FAIL;
out:
+libxl_dominfo_dispose(info);
return rc;
}
@@ -5435,6 +5447,8 @@ static int libxl__set_vcpuonline_xenstore(libxl__gc
*gc, uint32_t domid,
xs_transaction_t t;
int i, rc = ERROR_FAIL;
+libxl_dominfo_init(info);
+
if (libxl_domain_info(CTX, info, domid) 0) {
LOGE(ERROR, getting domain info list);
goto out;
@@ -5454,6 +5468,7 @@ retry_transaction:
} else
rc = 0;
out:
+libxl_dominfo_dispose(info);
return rc;
}
@@ -5463,8 +5478,11 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc,
uint32_t domid,
libxl_dominfo info;
int i;
+libxl_dominfo_init(info);
+
if (libxl_domain_info(CTX, info, domid) 0) {
LOGE(ERROR, getting domain info list);
+libxl_dominfo_dispose(info);
return ERROR_FAIL;
}
for (i = 0; i = info.vcpu_max_id; i++) {
@@ -5477,6 +5495,7 @@ static int libxl__set_vcpuonline_qmp(libxl__gc *gc,
uint32_t domid,
libxl__qmp_cpu_add(gc, domid, i);
Re: [Xen-devel] [PATCH OSSTEST v3] ts-libvirt-build: use Osstest::BuildSupport::submodulefixup
On Mon, 2015-01-05 at 15:36 +, Ian Campbell wrote:
Instead of cloning gnulib manually which can break if upstream gnulib
gets ahead of libvirt.git (which applies patches on the fly etc). By
using submodulefixup we automatically DTRT and use the version of
gnulib specified by the libvirt.git submodule metadata, but with a
runvar override if necessary.
This also removes a whole bunch of faffing in ap-*, cr-daily-branch
and mfi-common to get the version of gnulib to use, which was always a
bit of a wart (ungated for one thing...).
We continue to use --no-git and GNULIB_SRCDIR because otherwise
autogen.sh (via bootstrap) will force its own version, overwriting
what submodulefixup has done. For this we need a way to get the hash
representing the module, so introduce submodule_find (and rework
submodule_have in terms of it).
Tested in standalone mode with build-amd64-libvirt and
build-amd64-rumpuserxen (because I touched submodule_have, AFAICT the
bodges were not run). The libvirt build was tested both with the
automatic revisions and with:
revision_libvirt=2360fe5d24175835d3f5fd1c7e8e6e13addab629
revision_libvirt_gnulib=16518d9ed8f25d3e53931dd1aa343072933e4604
(used in successful libvirt flight 32648), in both cases confirming
that the build used the desired versions.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Ian J acked on IRC so I have pushed to osstests' pretest branch.
Ian.
---
v2: Honour revision_libvirt_gnulib.
v3: Fix submodule_have, defined(sub) is always true because defined
is special wrt sub.
---
Osstest/BuildSupport.pm | 13 ++---
ap-common | 3 ---
ap-fetch-version| 4
ap-fetch-version-old| 4
ap-print-url| 3 ---
ap-push | 5 -
cr-daily-branch | 4
mfi-common | 1 -
ts-libvirt-build| 20 +++-
9 files changed, 21 insertions(+), 36 deletions(-)
diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index 874e27e..933f6e1 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -43,7 +43,7 @@ BEGIN {
xendist
$xendist
- submodulefixup submodule_have
+ submodulefixup submodule_have submodule_find
);
%EXPORT_TAGS = ( );
@@ -145,9 +145,16 @@ sub submodulefixup () {
return \@submodules;
}
-sub submodule_have ($$) {
+sub submodule_find ($$) {
my ($submodules, $ourname) = @_;
-return !!grep { $_-{OurName} eq $ourname } @$submodules;
+my @submods = grep { $_-{OurName} eq $ourname } @$submodules;
+return undef unless @submods;
+die more than one $ourname? if @submods ne 1;
+return $submods[0];
+}
+
+sub submodule_have ($$) {
+return !!submodule_find;
}
1;
diff --git a/ap-common b/ap-common
index ff50754..96cbd14 100644
--- a/ap-common
+++ b/ap-common
@@ -37,8 +37,6 @@
: ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
: ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
-: ${TREE_GNULIB_LIBVIRT:=$(besteffort_repo git://git.sv.gnu.org/gnulib.git)}
-
: ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
: ${TREEVCS_RUMPUSERXEN:=git}
: ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
@@ -77,7 +75,6 @@ fi
: ${LOCALREV_XEN:=daily-cron.$branch}
: ${LOCALREV_LINUX:=daily-cron.$branch}
: ${LOCALREV_LIBVIRT:=daily-cron.$branch}
-: ${LOCALREV_GNULIB_LIBVIRT:=daily-cron.$branch}
: ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
: ${LOCALREV_SEABIOS:=daily-cron.$branch}
diff --git a/ap-fetch-version b/ap-fetch-version
index 9c189b4..f6c65d8 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -77,10 +77,6 @@ libvirt)
repo_tree_rev_fetch_git libvirt \
$TREE_LIBVIRT master $LOCALREV_LIBVIRT
;;
-gnulib-libvirt)
- repo_tree_rev_fetch_git gnulib-libvirt \
- $TREE_GNULIB_LIBVIRT master $LOCALREV_GNULIB_LIBVIRT
- ;;
rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index f3cf339..43c997c 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -88,10 +88,6 @@ rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$BASE_TREE_RUMPUSERXEN xen-tested-master
$BASE_LOCALREV_RUMPUSERXEN
;;
-gnulib-libvirt)
- # No push gate, same as ap-fetch-version
- ./ap-fetch-version $branch
- ;;
seabios)
repo_tree_rev_fetch_git seabios \
$BASE_TREE_SEABIOS xen-tested-master $BASE_LOCALREV_SEABIOS
diff --git a/ap-print-url b/ap-print-url
index a14d2a6..7b27e1e 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -52,9 +52,6 @@ linuxfirmware)
libvirt)
echo $TREE_LIBVIRT
;;
Re: [Xen-devel] [v3 1/5] Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options
On 12/30/2014 04:02 PM, Quan Xu wrote: Signed-off-by: Quan Xu quan...@intel.com This message was missing an In-Reply-To header tying it to the 0/5 cover letter, making it show up as an independent thread. Please see if you can fix that for the next submission. --- configure| 14 ++ hmp.c| 7 +++ qapi-schema.json | 19 --- qemu-options.hx | 13 +++-- tpm.c| 7 ++- 5 files changed, 54 insertions(+), 6 deletions(-) +++ b/qapi-schema.json @@ -2854,9 +2854,10 @@ # # @passthrough: TPM passthrough type # -# Since: 1.5 +# @xenstubdoms: TPM xenstubdoms type (since 2.3)## Since 1.5 Missing newlines. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH xen-4.6] xen: Remove CONFIG_X86_SUPERVISOR_MODE_KERNEL as x86_32 builds are unsupported
On 05/01/15 15:16, Ian Campbell wrote: On Fri, 2015-01-02 at 19:12 +, Andrew Cooper wrote: supervisor_mode_kernel was an x86_32-only feature which permitted a PV dom0 to run in ring 0, but at the expense of not being able to start any domUs. As the x86_32 Xen build has been removed from tree, removing the remaining supervisor_mode_kernel code. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Ian Campbell ian.campb...@citrix.com CC: Stefano Stabellini stefano.stabell...@citrix.com CC: Tim Deegan t...@xen.org --- One complication is that PVH has reused XENFEAT_supervisor_mode_kernel with a modified meaning, and the Linux PVH code actively uses the flag as to indicate running as a PVH guest. What is the modification? Doesn't a PVH kernel just use it to indicate that it should (or wants) run in ring0 instead of ring1/ring3? That was the original intention IIRC. Regardless, supervisor_mode_kernel was never anything more than a prototype, I'm pretty certain there can be no kernels out there relying on it, so rather than breaking pvh dom0 as you seem to do here I think it would be better to retcon the meaning of the flag as needed. This causes an discontinuity between PVH and HVM guests, both of which run their kernels with the PVH-taken meaning of XENFEAT_supervisor_mode_kernel. It also means that a dom0 kernel is unable to express PVH-only by requiring this feature, as a 64bit Xen will validly reject an attempt to require a 32bit-only Xen feature. I wouldn't describe XENFEAT_supervisor_mode_kernel as a 32-bit only Xen feature. It was only ever implemented for 32-bit, but conceptually it isn't specific to 32-bit but to any setup where PV requires you to run the kernel at a lower then normal privilege level. Answering out-of-order This patch has no functional change WRT PVH. The hunk commented on is simply changed via indentation due to the removal of the conditional it is in. It was never been possible for a PVH kernel boot with !XENFEAT_supervisor_mode_kernel in its feature string. If retcon'ing this feature flag is acceptable then the problem goes away, as can the commented hunk. However, given the meaning of the flag, it really should be advertised to plain HVM guests as well, because their kernel does run in ring0. At that point, it becomes more of a general running in an hvm container flag. What usecase was supervisor_mode_kernel developed for? It seems counter-intuitive, but I can't find anything in the history explaining its use. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Crash on efi_reset_machine on Lenovo ThinkCentre m93 (Haswell)
The BIOS on the machine is: DMI: LENOVO 10A6S09R01/SHARKBAY, BIOS FBKTA4AUS 12/11/2014 (just flashed it today - earlier versions had the same issue) And with both Xen 4.4 and Xen 4.5 when rebooting from EFI I get: [ 35.278564] reboot: Restarting system (XEN) Domain 0 shutdown: rebooting machine. (XEN) [ Xen-4.4.1 x86_64 debug=n Not tainted ] (XEN) CPU:0 (XEN) RIP:e008:[d5fd8412] d5fd8412 (XEN) RFLAGS: 00010202 CONTEXT: hypervisor (XEN) rax: 0046 rbx: rcx: (XEN) rdx: d5fd89b0 rsi: rdi: (XEN) rbp: rsp: 82d0802dfac8 r8: 82d0802dfb08 (XEN) r9: 82d0802dfaf8 r10: r11: 0022ebb099f2 (XEN) r12: r13: 0061 r14: (XEN) r15: 82d0802dfd7c cr0: 80050033 cr4: 001526f0 (XEN) cr3: 0004134cf000 cr2: 8800092472b0 (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=82d0802dfac8: (XEN)0001 0010 82d080178660 (XEN)82d0802dfb00 0004f0f8 82d0802dfd7c (XEN)0046 d5fe32f6 (XEN) c1e87000 fffe (XEN)82d0802d8000 82d080233a1d c1e87000 (XEN)001526f0 82d0802339fd 0061 (XEN)fffe 82d0801958dd 82d0802d8000 (XEN)82d0802f7800 82d0802dfdc8 82d0802f7800 (XEN) 82d080195a1b 0067 82d080128f94 (XEN)0008 82d0802dfc78 82d080289780 82d08017f329 (XEN)00fc083c3a60 82d0802dfdc8 00fb8000 (XEN)0008 0046 0008 82d080301040 (XEN)82d080289780 82d0802dfdc8 82d0802f7800 (XEN)82d0802dfd7c 82d0801772f7 82d0802dfd7c (XEN)82d0802f7800 82d0802dfdc8 82d080289780 82d080301040 (XEN)0022ebb099f2 82d080322ab0 0002 00082b337202 (XEN)00c1 0002 03fa 0002 (XEN)82d080301040 00fb 82d08013fa0f e008 (XEN)0206 82d0802dfd20 82d08013fba1 (XEN)0004 82d08012b96e 82d0802dfdc8 82d080301080 (XEN) Xen call trace: (XEN)[d5fd8412] d5fd8412 (XEN)[82d080178660] io_apic_write+0/0x70 (XEN)[82d080233a1d] efi_reset_system+0x2d/0x60 (XEN)[82d0802339fd] efi_reset_system+0xd/0x60 (XEN)[82d0801958dd] machine_restart+0xbd/0x1f0 (XEN)[82d080195a1b] __machine_restart+0xb/0x10 (XEN)[82d080128f94] smp_call_function_interrupt+0x64/0xa0 (XEN)[82d08017f329] do_IRQ+0x279/0x6b0 (XEN)[82d0801772f7] common_interrupt+0x57/0x60 (XEN)[82d08013fa0f] ns_read_reg+0x4f/0x50 (XEN)[82d08013fba1] ns16550_interrupt+0x31/0x80 (XEN)[82d08012b96e] add_entry+0x4e/0xb0 (XEN)[82d08017f3e7] do_IRQ+0x337/0x6b0 (XEN)[82d0801772f7] common_interrupt+0x57/0x60 (XEN)[82d0801ba7f2] mwait_idle+0x222/0x370 (XEN)[82d08016fe76] idle_loop+0x26/0x60 (XEN) (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) GENERAL PROTECTION FAULT (XEN) [error_code=] (XEN) (XEN) (XEN) ... or (Xen 4.5): (XEN) Domain 0 shutdown: rebooting machine. (XEN) [ Xen-4.5.0-rc-lK x86_64 debug=y Tainted:C ] (XEN) CPU:0 (XEN) RIP:e008:[d5fd83d0] d5fd83d0 (XEN) RFLAGS: 00010246 CONTEXT: hypervisor (XEN) rax: c2e1a990 rbx: rcx: 0002 (XEN) rdx: d5fd89b0 rsi: rdi: (XEN) rbp: rsp: 82d080457aa8 r8: (XEN) r9: 82d080457ad8 r10: 82d0802a1270 r11: 002580dbb411 (XEN) r12: r13: 00fb r14: 0061 (XEN) r15: cr0: 80050033 cr4: 001526f0 (XEN) cr3: 000413479000 cr2: 8803e800e4f0 (XEN) ds: 002b es: 002b fs: gs: ss: e010 cs: e008 (XEN) Xen stack trace from rsp=82d080457aa8: (XEN)82d080457ab8 82d08017c007 82d080457ae8 82d08017d1ef (XEN)82d080457ae0 0092 0286 (XEN)82d080457b18 0206 d5fe32f6 (XEN) 82d080457b48 82d08024582c (XEN) 82d080245ad4 c1eb4000 82d080457b68 (XEN)
Re: [Xen-devel] [PATCH for-4.5 v2] libxl: Initialise CTX-xce in domain suspend
On Mon, Jan 05, 2015 at 02:35:37PM +, Ian Jackson wrote:
Yang Hongyang writes ([PATCH] xl/libxl: fix migrate/Remus regression (core
dumped)):
When excuting xl migrate/Remus, the following error occurd:
[root@master xen]# xl migrate 5 slaver
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x1/0x0/1225)
Loading new save file incoming migration stream (new xl fmt info
0x1/0x0/1225)
Savefile contains xl domain config in JSON format
Parsing config from saved
Segmentation fault (core dumped)
This is because CTX-xce is used without been initialized.
The bug was introduced by commit 2ffeb5d7f5d8
libxl: events: Deregister evtchn fd when not needed
which remove the initialization of xce from libxl__ctx_alloc.
This patch initialze the CTX-xce before use it.
Thanks. This patch goes in the right direction, but isn't quite
correct because it doesn't check the return value from
libxl__ctx_evtchn_init.
Looking at this it is clear that following the on-demand
initialisation of CTX-xce, it is normally necessary for any evtchn
user in libxl to call libxl__ctx_evtchn_init, since they will need the
xce for finding the right port number to pass to
libxl__ev_evtchn_wait.
Sorry for not noticing this when I made my earlier change.
I have therefore:
* In the patch below, added changes to the comments to document this.
* Done git grep '\bxce\b' tools/libxl and checked the other uses.
* Consequently, verified that the rest of the code in libxl_dom.c
avoids using xce unless guest_evtchn.port=0, and properly
initialises .port to -1, so that there is no need for further calls
to libxl__ctx_evtchn_init.
I have compiled but not executed this patch. Yang Hongyang: can you
please test that it fixes the bug for you ?
Konrad: this should go in 4.5 because it is a bugfix without which
libxl may dereference NULL.
OK. Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
(I have also somewhat improved the English grammar in the commit
message.)
Thanks,
Ian.
commit 9d1cb27f5e961fd9db1c7d8381af18e33510f924
Author: Ian Jackson ian.jack...@eu.citrix.com
Date: Mon Jan 5 14:31:00 2015 +
libxl: Initialise CTX-xce in domain suspend, as needed
When excuting xl migrate/Remus, the following error can occur:
[root@master xen]# xl migrate 5 slaver
migration target: Ready to receive domain.
Saving to migration stream new xl format (info 0x1/0x0/1225)
Loading new save file incoming migration stream (new xl fmt info
0x1/0x0/12\
)
Savefile contains xl domain config in JSON format
Parsing config from saved
Segmentation fault (core dumped)
This is because CTX-xce is used without been initialized.
The bug was introduced by commit 2ffeb5d7f5d8
libxl: events: Deregister evtchn fd when not needed
which removed the initialization of xce from libxl__ctx_alloc.
In this patch we initialise the CTX-xce before using it. Also, we
adjust the doc comment for libxl__ev_evtchn_* to mention the need to
do so.
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Wei Liu wei.l...@citrix.com
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..94ae818 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1824,6 +1824,9 @@ void libxl__domain_suspend(libxl__egc *egc,
libxl__domain_suspend_state *dss)
port = xs_suspend_evtchn_port(dss-domid);
if (port = 0) {
+rc = libxl__ctx_evtchn_init(gc);
+if (rc) goto out;
+
dss-guest_evtchn.port =
xc_suspend_evtchn_init_exclusive(CTX-xch, CTX-xce,
dss-domid, port,
dss-guest_evtchn_lockfd);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9695f18..6dac0f8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -800,8 +800,10 @@ static inline int libxl__ev_xswatch_isregistered(const
libxl__ev_xswatch *xw)
/*
* The evtchn facility is one-shot per call to libxl__ev_evtchn_wait.
- * You should call some suitable xc bind function on (or to obtain)
- * the port, then libxl__ev_evtchn_wait.
+ * You should:
+ * Use libxl__ctx_evtchn_init to make sure CTX-xce is valid;
+ * Call some suitable xc bind function on (or to obtain) the port;
+ * Then call libxl__ev_evtchn_wait.
*
* When the event is signaled then the callback will be made, once.
* Then you must call libxl__ev_evtchn_wait again, if desired.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
On Mon, Jan 05, 2015 at 12:48:16PM +, George Dunlap wrote: On Thu, Dec 18, 2014 at 4:55 AM, Hu, Robert robert...@intel.com wrote: For this specific problem though I think http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html We verified this on RC4, it works. Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with a running guest will not work properly. It looks like IanJ's patch (referenced above) has not been applied. It's clearly a bug fix, so it probably should be... nods Ian, were you waiting on Boris to repost the patches? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
On 01/05/2015 10:27 AM, Konrad Rzeszutek Wilk wrote: On Mon, Jan 05, 2015 at 12:48:16PM +, George Dunlap wrote: On Thu, Dec 18, 2014 at 4:55 AM, Hu, Robert robert...@intel.com wrote: For this specific problem though I think http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html We verified this on RC4, it works. Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with a running guest will not work properly. It looks like IanJ's patch (referenced above) has not been applied. It's clearly a bug fix, so it probably should be... nods Ian, were you waiting on Boris to repost the patches? I wasn't planning on resending them. They (or, more likely, it) need to be reworked to use async notifications and I haven't done this. Ian's fix is independent of what I need to do. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
Boris Ostrovsky writes (Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1): On 01/05/2015 10:27 AM, Konrad Rzeszutek Wilk wrote: Ian, were you waiting on Boris to repost the patches? Yes. I wasn't planning on resending them. They (or, more likely, it) need to be reworked to use async notifications and I haven't done this. Oh. In the meantime we should apply my fix, but it doesn't have a proper commit message yet. I will write one and a release ack request. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
