Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0
It seems that tpm_tis_request_locality did not manage to wait enough for locality change. I suspect that if timeout_a does not have correct value it will not wait enough in that loop and it will exit too soon. Can you do this test again replacing timeout_a value from tpm_tis_request_locality =>(stop = NOW() + tpm->timeout_a;) with something much bigger? I sent a patch that was committed this week, that fixes timeout problems that could appear and resets them to the standard value if they are incorrect. At least it seems that the locality 2 on your chip is enabled since you got here. Thanks. Emil Condrea On Sun, Nov 16, 2014 at 9:15 AM, Xu, Quan wrote: > Emil / Graaf, > I have verified it, it is still not working when tboot is enabled. > The attach file is txt-stat log. > [...] > > *** > TXT measured launch: TRUE > secrets flag set: TRUE > *** > [...] > > > Below is error when I boot vtpmmgr: > > > ** > [...] > IOMEM Machine Base Address: FED4 > Enabled Localities: 2 > REQ LOCALITY FAILURE > Unable to request locality 2?? > Shutting down tpm_tis device > Page fault at linear address 0xfed40008, rip 0x2f918, regs 0x10fc78, sp > 0x10fd20, our_sp 0x10fc40, code 2 > Thread: main > RIP: e030:[<0002f918>] > RSP: e02b:0010fd20 EFLAGS: 00010202 > RAX: RBX: 002000804c60 RCX: 072c > RDX: 001e RSI: 7fff RDI: fed40008 > RBP: 0010fd20 R08: 000a R09: 000af000 > R10: 070e R11: 06d8 R12: 002000804c60 > R13: fed42000 R14: R15: 0002 > base is 0x10fd20 caller is 0x24977 > base is 0x10fd40 caller is 0x24e32 > base is 0x10fd80 caller is 0x5b4b > base is 0x10ff30 caller is 0x3510 > base is 0x10ff50 caller is 0x287a2 > base is 0x10ffe0 caller is 0x343b > > 10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00 > 10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00 > 10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00 > 10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00 > > 10fd10: 20 fd 10 00 00 00 00 00 2b e0 00 00 00 00 00 00 > 10fd20: 40 fd 10 00 00 00 00 00 77 49 02 00 00 00 00 00 > 10fd30: 60 4c 80 00 20 00 00 00 02 00 00 00 00 00 00 00 > 10fd40: 80 fd 10 00 00 00 00 00 32 4e 02 00 00 00 00 00 > > 2f900: 5d c3 55 48 89 e5 40 88 37 5d c3 55 48 89 e5 66 > 2f910: 89 37 5d c3 55 48 89 e5 89 37 5d c3 55 48 89 e5 > 2f920: 48 89 37 5d c3 55 48 89 e5 0f b6 07 5d c3 55 48 > 2f930: 89 e5 0f b7 07 5d c3 55 48 89 e5 8b 07 5d c3 55 > Pagetable walk from virt fed40008, base b: > L4 = 000127033067 (0xb1000) [offset = 0] > L3 = (0xf000) [offset = 3] > Page fault in pagetable walk (access to invalid memory?). > > > > Thanks > Quan Xu > > > > -Original Message- > > From: xen-devel-boun...@lists.xen.org > > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Xu, Quan > > Sent: Sunday, November 09, 2014 4:30 PM > > To: Emil Condrea > > Cc: Daniel De Graaf; Ian Campbell; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0 > > > > Okay, I will test it in next week. > > > > Thanks > > Quan Xu > > > > > > From: xen-devel-boun...@lists.xen.org > > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Emil Condrea > > Sent: Friday, November 07, 2014 6:42 PM > > To: Xu, Quan > > Cc: Daniel De Graaf; Ian Campbell; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0 > > > > Xu, my system does not support DRTM launch so if you can test it next > week > > it would be great. > > Thanks > > > > On Fri, Nov 7, 2014 at 3:46 AM, Xu, Quan wrote: > > > > > > > -Original Message- > > > From: xen-devel-boun...@lists.xen.org > > > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Daniel De Graaf > > > Sent: Friday, November 07, 2014 5:55 AM > > > To: Emil Condrea > > > Cc: Ian Campbell; xen-devel@lists.xen.org > > > Subject: Re: [Xen-devel] vtpmmgr bug: fails to start if locality!=0 > > > > > > On 11/05/2014 05:00 AM, Ian Campbell wrote: > > > > CCing Daniel. > > > > > > > > On Fri, 2014-10-31 at 17:37 +0200, Emil Condrea wrote: > > > >> > > > >> I am wondering if this is known issue that when I set locality!=0 to > > > >> vtpmmgr it does not start. It is a bit strange that every call to > > > >> tpm_tis_status returns 255 and device-id is also : > > > >> 1.2 TPM (device-id=0x vendor-id = rev-id = FF). > > > >> TPM interface capabilities (0x): > > > >> > > > >> I am configuring vtpmmgr using: > > > >> > > > >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz" > > > >> memory=8 > > > >> disk=["file:/var/vtpmmgr-stubdom.img,hda,w"] > > > >> name="vtpmmgr" > > > >>
[Xen-devel] [qemu-mainline test] 31599: regressions - FAIL
flight 31599 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31599/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 guest-start fail REGR. vs. 30603 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30603 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 7 debian-installfail REGR. vs. 30603 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail 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-i386-xl-win7-amd64 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-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-i386-xl-qemuu-win7-amd64 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 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-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: qemuu4e70f9271dabc58fbf14680843bfac510c193152 baseline version: qemuub00a0ddb31a393b8386d30a9bef4d9bbb249e7ec People who touched revisions under test: Adam Crume Alex Bennée Alex Williamson Alexander Graf Alexey Kardashevskiy Amit Shah Amos Kong Andreas Färber Andrew Jones Ard Biesheuvel Aurelien Jarno Bastian Koppelmann Bharata B Rao Bin Wu Chao Peng Chen Fan Chen Gang Chenliang Chris Johns Chris Spiegel Christian Borntraeger Claudio Fontana Cole Robinson Corey Minyard Cornelia Huck David Gibson David Hildenbrand Denis V. Lunev Don Slutz Dongxue Zhang Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Eduardo Otubo Fabian Aggeler Fam Zheng Frank Blaschka Gal Hammer Gerd Hoffmann Gonglei Greg Bellows Gu Zheng Hannes Reinecke Heinz Graalfs Igor Mammedov James Harper James Harper Jan Kiszka Jan Vesely Jens Freimann Joel Schopp John Snow Jonas Gorski Jonas Maebe Juan Quintela Juan Quintela Jun Li Kevin Wolf KONRAD Frederic Laszlo Ersek Leon Alrae Li Liang Li Liu Luiz Capitulino Maciej W. Rozycki Magnus Reftel Marc-André Lureau Marcel Apfelbaum Mark Cave-Ayland Markus Armbruster Martin Decky Martin Simmons Max Filippov Max Reitz Michael Ellerman Michael Roth Michael S. Tsirkin Michael Tokarev Michael Walle (for lm32) Michal Privoznik Mikhail Ilyin Ming Lei Nikita Belov Nikunj A Dadhania Paolo Bonzini Paul Moore Pavel Dovgalyuk Peter Crosthwaite Peter Lieven Peter Maydell Peter Wu Petr Matousek Philipp Gesang Pierre Mallard Ray Strode Richard Jones Richard W.M. Jones Riku Voipio Rob Herring Roger Pau Monne Roger Pau Monné Sebastian Krahmer SeokYeon Hwang Sergey Fedorov Stefan Berger Stefan Hajnoczi Stefano Stabellini Thomas Huth Ting Wang Tom Musta Tony Breeds Wei Huang Willem Pinckaers Yongbok Kim Zhang Haoyu zhanghailiang Zhu Guihua jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-am
Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
* Juergen Gross wrote: > arch/x86/include/asm/cacheflush.h | 38 --- FYI, this series breaks the UML build: In file included from /home/mingo/tip/include/linux/highmem.h:11:0, from /home/mingo/tip/include/linux/pagemap.h:10, from /home/mingo/tip/include/linux/mempolicy.h:14, from /home/mingo/tip/include/linux/shmem_fs.h:6, from /home/mingo/tip/init/do_mounts.c:30: /home/mingo/tip/arch/x86/include/asm/cacheflush.h:67:36: error: return type is an incomplete type static inline enum page_cache_mode get_page_memtype(struct page *pg) ^ /home/mingo/tip/arch/x86/include/asm/cacheflush.h: In function ‘get_page_memtype’: /home/mingo/tip/arch/x86/include/asm/cacheflush.h:69:2: warning: ‘return’ with a value, in function returning void [enabled by default] return -1; ^ /home/mingo/tip/arch/x86/include/asm/cacheflush.h: At top level: /home/mingo/tip/arch/x86/include/asm/cacheflush.h:72:30: error: parameter 2 (‘memtype’) has incomplete type enum page_cache_mode memtype) ^ /home/mingo/tip/arch/x86/include/asm/cacheflush.h:71:20: error: function declaration isn’t a prototype [-Werror=strict-prototypes] Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when running on Xen
> > > Konrad, > > > this is another bug fix for QEMU: pci hotplug doesn't work when > > > xen_platform_pci=0 without this. > > > > Yes. > > > > > >I think we should have it in 4.5. What do yo think? > > > > Do you believe we should first get an Tested-by from the Intel QA folks? > Liang at Intel was the one to fix and resend. Liang, could you please test > this patch on qemu-xen on xen-unstable? Thanks! I have verified this patch can fix the bug for QEMU: pci hotplug doesn't work when xen_platform_pci=0, my original intention was to fix this bug, so I resent the patch. Liang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: Correction to module@1 (dom0 kernel) DT node.
Hi Ian,
On Mon, Nov 10, 2014 at 02:09:58PM +, Ian Campbell wrote:
> - Include bootargs (kernel command line) property.
Why?
The logic I was going for was to reduce duplicate code/entries in the
DT, and if I read docs/misc/arm/device-tree/booting.txt, the fact that
we have xen,xen-bootargs but no xen,dom0-bootargs then bootargs added
further down in Makefile.am will be used.
Is this not correct or not preferred for some reason?
-Christoffer
> - Update reg property to match #address-cells and #size-cells in the DTB (both
> 2).
>
> Signed-off-by: Ian Campbell
> ---
> Makefile.am |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 9b6c7e3..ed5acbb 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -69,8 +69,9 @@ XEN_OFFSET := 0xA0
> DOM0_OFFSET := $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET
> XEN_BOOTARGS := xen,xen-bootargs = \"$(BOOTARGS)\"; \
> module@1 { \
> + bootargs = \"$(CMDLINE)\"; \
> compatible = \"xen,linux-zimage\",
> \"xen,multiboot-module\"; \
> - reg = <$(DOM0_OFFSET) 0x80>;\
> + reg = <0 $(DOM0_OFFSET) 0 0x80>;\
> };
> endif
>
> --
> 1.7.10.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/4] Fix build when Xen is not enabled
On Mon, Nov 10, 2014 at 02:09:59PM +, Ian Campbell wrote: > If Xen isn't enabled then XEN_IMAGE ends up as "no.o", which obviously doesn't > exist. Handle the dependency explicitly. > > Signed-off-by: Ian Campbell > --- > Makefile.am |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Makefile.am b/Makefile.am > index ed5acbb..6c2786e 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -98,7 +98,10 @@ all: $(IMAGE) $(XIMAGE) > > CLEANFILES = $(IMAGE) boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) > model.lds fdt.dtb > > -$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb > $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE) > +if XEN > +XEN_IMAGE_DEP = $(XEN_IMAGE) > +endif > +$(IMAGE): boot.o cache.o $(GIC) mmu.o ns.o $(BOOTMETHOD) model.lds fdt.dtb > $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE_DEP) > $(LD) -o $@ --script=model.lds > > %.o: %.S Makefile > -- > 1.7.10.4 > I fixed this differently, see the 'xen-psci-support-for-upstream' branch in: http://git.linaro.org/people/christoffer.dall/boot-wrapper-aarch64.git Hopefully you're ok with that change. -Christoffer ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.10 test] 31606: regressions - trouble: broken/fail/pass
flight 31606 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31606/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 26303 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken REGR. vs. 26303 test-amd64-i386-freebsd10-i386 3 host-install(3) broken 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-amd64-xl-sedf 5 xen-boot fail REGR. vs. 26303 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-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-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-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 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-i386-xl-qemuu-win7-amd64 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-i386-xl-qemut-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: linuxbe70188832b22a8f1a49d0e3a3eb2209f9cfdc8a baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 750 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt 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 fail test-amd64-i386-xl pass 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 test-amd64-i386-xl-credit2 pass test-amd64-i386-freebsd10-i386
[Xen-devel] [PATCH v15 06/21] 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
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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, u8 vector);
void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
@@ -497,6 +500,15 @@ void v
[Xen-devel] [PATCH v15 04/21] 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
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 54e96b6..f2e9735 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 e74c871..aec7b5f 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 v15 18/21] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr
The two routines share most of their logic.
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/vpmu.c| 69 +-
xen/include/asm-x86/hvm/vpmu.h | 14 +++--
2 files changed, 39 insertions(+), 44 deletions(-)
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 6a71d53..aa4a5d9 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -91,57 +91,42 @@ 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 vpmu_struct *vpmu = vcpu_vpmu(curr);
+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;
-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(curr);
-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 = vcpu_vpmu(curr);
-
-if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+curr = current;
+vpmu = vcpu_vpmu(curr);
+ops = vpmu->arch_vpmu_ops;
+if ( !ops )
return 0;
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
+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);
+
+/*
+ * 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) )
{
-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(curr);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+ops->arch_vpmu_save(curr);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
}
-return 0;
+
+return ret;
}
static struct vcpu *choose_hwdom_vcpu(void)
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index ada2ab7..56cc09c 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -99,8 +99,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);
@@ -110,6 +110,16 @@ void vpmu_save(struct vcpu *v);
void vpmu_load(struct vcpu *v);
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 v15 09/21] 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
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 | 2 +
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| 90 ++
xen/include/public/pmu.h | 38 ++
xen/include/xlat.lst | 4 +
11 files changed, 274 insertions(+), 133 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 af3cdb2..0d30b37 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -30,10 +30,7 @@
#include
#include
#include
-
-#define F10H_NUM_COUNTERS 4
-#define F15H_NUM_COUNTERS 6
-#define MAX_NUM_COUNTERS F15H_NUM_COUNTERS
+#include
#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 *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
vpmu_reset(vpmu, VPMU_FROZEN);
@@ -198,7 +201,7 @@ static void amd_vpmu_load(struct vcpu *v)
unsigned int i;
for (
[Xen-devel] [PATCH v15 02/21] 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
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 265fc0e..e74c871 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 v15 08/21] 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
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 f44847f..e7fffcf 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
[Xen-devel] [PATCH v15 10/21] 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
Acked-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 v15 11/21] 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
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
tools/flask/policy/policy/modules/xen/xen.te | 3 +
xen/arch/x86/domain.c| 6 +-
xen/arch/x86/hvm/svm/vpmu.c | 4 +-
xen/arch/x86/hvm/vmx/vpmu_core2.c| 10 +-
xen/arch/x86/hvm/vpmu.c | 164 +--
xen/arch/x86/x86_64/compat/entry.S | 4 +
xen/arch/x86/x86_64/entry.S | 4 +
xen/include/asm-x86/hvm/vpmu.h | 27 +++--
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 +
17 files changed, 288 insertions(+), 27 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te
b/tools/flask/policy/policy/modules/xen/xen.te
index d214470..ae7bf3c 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 ae0a344..da5bdf4 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_switch_from(prev, 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(prev) && (prev != next) )
/* Must be done with interrupts enabled */
-vpmu_load(next);
+vpmu_switch_to(prev, next);
context_saved(prev);
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 0d30b37..61d56d5 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -478,14 +478,14 @@ struct arch_vpmu_ops amd_vpmu_ops = {
.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/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index a6cca38..23e4899 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,13 +708,13 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs
*regs)
return 1;
}
-static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+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_flags & VPMU_BOOT_BTS) )
+if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
goto func_out;
/* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
while ( boot_cpu_has(X86_FEATURE_DS) )
@@ -829,7 +829,7 @@ struct arch_vpmu_ops core2_no_vpmu_ops = {
.do_cpuid = core2_no_vpmu_do_cpuid,
};
-int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int vmx_vpmu_initialise(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
uint8_t family = current_cpu_data.x86;
@@ -837,7 +837,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int
vpmu_flags)
int ret = 0;
[Xen-devel] [PATCH v15 14/21] 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
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/domain.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ce1d187..0de8a20 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1541,16 +1541,13 @@ 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(prev, next);
+_update_runstate_area(prev);
+vpmu_switch_from(prev, next);
+}
-if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+if ( is_hvm_vcpu(prev) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
pt_save_timer(prev);
-}
local_irq_disable();
@@ -1589,15 +1586,16 @@ void context_switch(struct vcpu *prev, struct vcpu
*next)
!is_hardware_domain(next->domain));
}
-if ( is_hvm_vcpu(prev) && (prev != next) )
-/* Must be done with interrupts enabled */
-vpmu_switch_to(prev, next);
-
context_saved(prev);
if ( prev != next )
+{
_update_runstate_area(next);
+/* Must be done with interrupts enabled */
+vpmu_switch_to(prev, 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
[Xen-devel] [PATCH v15 15/21] 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
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 | 78 ++-
4 files changed, 53 insertions(+), 61 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b1c4845..d0ba075 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1700,7 +1700,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:
@@ -1851,7 +1852,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 fe852ed..b54a51d 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -305,7 +305,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) )
@@ -335,7 +335,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)
@@ -353,7 +353,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 a7c3a7a..ef7ce72 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 X86EMUL_OKAY;
if ( passive_domain_do_wrmsr(msr, msr_content) )
return X86EMUL_O
[Xen-devel] [PATCH v15 13/21] x86/VPMU: Initialize PMU for PV(H) guests
Code for initializing/tearing down PMU for PV guests
Signed-off-by: Boris Ostrovsky
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
tools/flask/policy/policy/modules/xen/xen.te | 4 ++
xen/arch/x86/domain.c| 2 +
xen/arch/x86/hvm/hvm.c | 1 +
xen/arch/x86/hvm/svm/svm.c | 4 +-
xen/arch/x86/hvm/svm/vpmu.c | 44 +
xen/arch/x86/hvm/vmx/vmx.c | 4 +-
xen/arch/x86/hvm/vmx/vpmu_core2.c| 81 ---
xen/arch/x86/hvm/vpmu.c | 98 +++-
xen/common/event_channel.c | 1 +
xen/include/asm-x86/hvm/vpmu.h | 2 +
xen/include/public/pmu.h | 2 +
xen/include/public/xen.h | 1 +
xen/include/xsm/dummy.h | 3 +
xen/xsm/flask/hooks.c| 4 ++
xen/xsm/flask/policy/access_vectors | 2 +
15 files changed, 212 insertions(+), 41 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te
b/tools/flask/policy/policy/modules/xen/xen.te
index ae7bf3c..9d84004 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -120,6 +120,10 @@ domain_comms(dom0_t, dom0_t)
# Allow all domains to use (unprivileged parts of) the tmem hypercall
allow domain_type xen_t:xen tmem_op;
+# Allow all domains to use PMU (but not to change its settings --- that's what
+# pmu_ctrl is for)
+allow domain_type xen_t:xen2 pmu_use;
+
###
#
# Domain creation
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index da5bdf4..ce1d187 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -445,6 +445,8 @@ int vcpu_initialise(struct vcpu *v)
vmce_init_vcpu(v);
+spin_lock_init(&v->arch.vpmu.vpmu_lock);
+
if ( has_hvm_container_domain(d) )
{
rc = hvm_vcpu_initialise(v);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f49b44..ec9c89a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4820,6 +4820,7 @@ static hvm_hypercall_t *const
pvh_hypercall64_table[NR_hypercalls] = {
HYPERCALL(hvm_op),
HYPERCALL(sysctl),
HYPERCALL(domctl),
+HYPERCALL(xenpmu_op),
[ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
};
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8aca6e6..b1c4845 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1157,7 +1157,9 @@ static int svm_vcpu_initialise(struct vcpu *v)
return rc;
}
-vpmu_initialise(v);
+/* PVH's VPMU is initialized via hypercall */
+if ( is_hvm_vcpu(v) )
+vpmu_initialise(v);
svm_guest_osvw_init(v);
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 8460d7b..fe852ed 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -363,17 +363,19 @@ static void amd_vpmu_destroy(struct vcpu *v)
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
return;
-if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
-amd_vpmu_unset_msr_bitmap(v);
+if ( has_hvm_container_vcpu(v) )
+{
+if ( is_msr_bitmap_on(vpmu) )
+amd_vpmu_unset_msr_bitmap(v);
-xfree(vpmu->context);
-vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
+if ( is_hvm_vcpu(v) )
+xfree(vpmu->context);
-if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
-{
-vpmu_reset(vpmu, VPMU_RUNNING);
release_pmu_ownship(PMU_OWNER_HVM);
}
+
+vpmu->context = NULL;
+vpmu_clear(vpmu);
}
/* VPMU part of the 'q' keyhandler */
@@ -439,15 +441,19 @@ int svm_vpmu_initialise(struct vcpu *v)
if ( !counters )
return -EINVAL;
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
- 2 * sizeof(uint64_t) * num_counters);
-if ( !ctxt )
+if ( is_hvm_vcpu(v) )
{
-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 = xzalloc_bytes(sizeof(*ctxt) +
+ 2 * sizeof(uint64_t) * num_counters);
+if ( !ctxt )
+{
+printk(XENLOG_G_WARNING "%pv: Insufficient memory for PMU, "
+ " PMU feature is unavailable\n", v);
+return -ENOMEM;
+}
}
+else
+ctxt = &v->arch.vpmu.xenpmu_data->pmu.c.amd;
ctxt->counters = sizeof(*ctxt);
ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
@@ -489,6 +495,16 @@ int __init amd_vpmu_init(void)
return -EINVAL;
}
+if ( sizeof(struct xen_pmu_data)
[Xen-devel] [PATCH v15 21/21] x86/VPMU: Move VPMU files up from hvm/ directory
Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.
Specifically:
arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
include/asm-x86/hvm/vpmu.h -> include/asm-x86/vpmu.h
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/cpu/Makefile | 1 +
xen/arch/x86/{hvm => cpu}/vpmu.c| 2 +-
xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} | 2 +-
xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 2 +-
xen/arch/x86/hvm/Makefile | 1 -
xen/arch/x86/hvm/svm/Makefile | 1 -
xen/arch/x86/hvm/vlapic.c | 2 +-
xen/arch/x86/hvm/vmx/Makefile | 1 -
xen/arch/x86/oprofile/op_model_ppro.c | 2 +-
xen/arch/x86/traps.c| 2 +-
xen/include/asm-x86/hvm/vmx/vmcs.h | 2 +-
xen/include/asm-x86/{hvm => }/vpmu.h| 0
12 files changed, 8 insertions(+), 10 deletions(-)
rename xen/arch/x86/{hvm => cpu}/vpmu.c (99%)
rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (99%)
rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (99%)
rename xen/include/asm-x86/{hvm => }/vpmu.h (100%)
diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index d73d93a..74f23ae 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -7,3 +7,4 @@ obj-y += common.o
obj-y += intel.o
obj-y += intel_cacheinfo.o
obj-y += mwait-idle.o
+obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/cpu/vpmu.c
similarity index 99%
rename from xen/arch/x86/hvm/vpmu.c
rename to xen/arch/x86/cpu/vpmu.c
index cf96da7..a52604a 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -27,10 +27,10 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/cpu/vpmu_amd.c
similarity index 99%
rename from xen/arch/x86/hvm/svm/vpmu.c
rename to xen/arch/x86/cpu/vpmu_amd.c
index c21bde0..bb9da12 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -28,8 +28,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#define MSR_F10H_EVNTSEL_GO_SHIFT 40
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/cpu/vpmu_intel.c
similarity index 99%
rename from xen/arch/x86/hvm/vmx/vpmu_core2.c
rename to xen/arch/x86/cpu/vpmu_intel.c
index 271fae5..e5f22a7 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,7 +38,6 @@
#include
#include
#include
-#include
/*
* See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index eea..742b83b 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -22,4 +22,3 @@ obj-y += vlapic.o
obj-y += vmsi.o
obj-y += vpic.o
obj-y += vpt.o
-obj-y += vpmu.o
\ No newline at end of file
diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index a10a55e..760d295 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -6,4 +6,3 @@ obj-y += nestedsvm.o
obj-y += svm.o
obj-y += svmdebug.o
obj-y += vmcb.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 5c3b2be..16ad0ce 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,7 +38,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/xen/arch/x86/hvm/vmx/Makefile b/xen/arch/x86/hvm/vmx/Makefile
index 373b3d9..04a29ce 100644
--- a/xen/arch/x86/hvm/vmx/Makefile
+++ b/xen/arch/x86/hvm/vmx/Makefile
@@ -3,5 +3,4 @@ obj-y += intr.o
obj-y += realmode.o
obj-y += vmcs.o
obj-y += vmx.o
-obj-y += vpmu_core2.o
obj-y += vvmx.o
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c
b/xen/arch/x86/oprofile/op_model_ppro.c
index ca429a1..89649d0 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include "op_x86_model.h"
#include "op_counter.h"
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 663b44f..33f0fc5 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,7 +72,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 949884b..dcf2d31 100644
--- a/xen/include/asm
[Xen-devel] [PATCH v15 03/21] 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
Acked-by: Kevin Tian
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 8e07a98..f49af97 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);
}
@@ -406,7 +410,8 @@ static void amd_vpmu_destroy(struct vcpu *v)
if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) )
return;
-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 68b6272..54e96b6 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;
@@ -822,7 +824,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
return;
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 v15 05/21] 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
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/vmx/vpmu_core2.c| 381 ++-
xen/include/asm-x86/hvm/vmx/vpmu_core2.h | 19 --
2 files changed, 172 insertions(+), 228 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index f2e9735..09af846 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 MASK_EXTR(edx, PMU_FIXED_WIDTH_MASK);
}
static int is_core2_vpmu_msr
[Xen-devel] [PATCH v15 19/21] 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
Acked-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/vpmu.c | 36 ++--
xen/arch/x86/traps.c | 12
xen/include/public/pmu.h | 3 +++
3 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index aa4a5d9..5f0a871 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)) )
return 0;
curr = current;
@@ -144,8 +146,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 )
@@ -155,12 +161,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;
@@ -169,6 +175,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;
@@ -179,6 +186,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
*flags = 0;
+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) )
@@ -207,7 +219,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;
@@ -442,7 +455,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) ||
@@ -585,11 +599,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;
/*
@@ -608,7 +624,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 ( (vpmu_mode == XENPMU_MODE_OFF) || (vpmu_mode == XENPMU_MODE_ALL) )
{
/*
* Make sure all (non-dom0) VCPUs have unloaded their VPMUs. This
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 70477b2..663b44f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2579,6 +2579,10 @@ static int emulate_privileged_op(struct cpu_user_regs
*regs)
[Xen-devel] [PATCH v15 16/21] x86/VPMU: Add support for PMU register handling on PV guests
Intercept accesses to PMU MSRs and process them in VPMU module.
Dump VPMU state for all domains (HVM and PV) when requested.
Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/domain.c | 3 +--
xen/arch/x86/hvm/vmx/vpmu_core2.c | 49 --
xen/arch/x86/traps.c | 50 ++-
3 files changed, 92 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0de8a20..37c6371 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2075,8 +2075,7 @@ void arch_dump_vcpu_info(struct vcpu *v)
{
paging_dump_vcpu_info(v);
-if ( is_hvm_vcpu(v) )
-vpmu_dump(v);
+vpmu_dump(v);
}
void domain_cpuid(
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 2dd8000..839dce0 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -299,12 +300,18 @@ static inline void __core2_vpmu_save(struct vcpu *v)
rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
for ( i = 0; i < arch_pmc_cnt; i++ )
rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
+
+if ( !has_hvm_container_vcpu(v) )
+rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
}
static int core2_vpmu_save(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
+if ( !has_hvm_container_vcpu(v) )
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+
if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
return 0;
@@ -342,6 +349,13 @@ static inline void __core2_vpmu_load(struct vcpu *v)
wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
+
+if ( !has_hvm_container_vcpu(v) )
+{
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, core2_vpmu_cxt->global_ovf_ctrl);
+core2_vpmu_cxt->global_ovf_ctrl = 0;
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
+}
}
static void core2_vpmu_load(struct vcpu *v)
@@ -442,7 +456,6 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int
*type, int *index)
static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
uint64_t supported)
{
-u64 global_ctrl;
int i, tmp;
int type = -1, index = -1;
struct vcpu *v = current;
@@ -486,7 +499,12 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
switch ( msr )
{
case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+if ( msr_content & ~(0xC000 |
+ (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1)) )
+return 1;
core2_vpmu_cxt->global_status &= ~msr_content;
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
return 0;
case MSR_CORE_PERF_GLOBAL_STATUS:
gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -514,14 +532,18 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
return 0;
case MSR_CORE_PERF_GLOBAL_CTRL:
-global_ctrl = msr_content;
+core2_vpmu_cxt->global_ctrl = msr_content;
break;
case MSR_CORE_PERF_FIXED_CTR_CTRL:
if ( msr_content &
( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
return 1;
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+if ( has_hvm_container_vcpu(v) )
+vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+ &core2_vpmu_cxt->global_ctrl);
+else
+rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
*enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
if ( msr_content != 0 )
{
@@ -546,7 +568,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
if ( msr_content & (~((1ull << 32) - 1)) )
return 1;
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+if ( has_hvm_container_vcpu(v) )
+vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+ &core2_vpmu_cxt->global_ctrl);
+else
+rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
if ( msr_content & (1ULL << 22) )
*enabled_cntrs |= 1ULL << tmp;
@@ -560,9 +586,15 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t
msr_content,
if ( type != MSR_TYPE_GLOBAL )
wrmsrl
[Xen-devel] [PATCH v15 17/21] 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
Acked-by: Daniel De Graaf
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/svm/vpmu.c | 11 +--
xen/arch/x86/hvm/vpmu.c | 203 +++---
xen/include/public/arch-x86/pmu.h | 5 +
xen/include/public/pmu.h | 2 +
xen/include/xsm/dummy.h | 4 +-
xen/xsm/flask/hooks.c | 2 +
6 files changed, 207 insertions(+), 20 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index b54a51d..7d9ba8c 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -228,17 +228,12 @@ static int amd_vpmu_save(struct vcpu *v)
struct vpmu_struct *vpmu = vcpu_vpmu(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 2ad9832..6a71d53 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -80,46 +80,203 @@ 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 = vcpu_vpmu(curr);
if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
return 0;
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(curr);
+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 = vcpu_vpmu(curr);
if ( !(vpmu_mode & (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
return 0;
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(curr);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
+}
+return ret;
+}
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 = current;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
+struct vcpu *sampled = current, *sampling;
+struct vpmu_struct *vpmu;
+
+/* dom0 will handle interrupt for special domains (e.g. idle domain) */
+if ( sampled
[Xen-devel] [PATCH v15 12/21] 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
Tested-by: Dietmar Hahn
---
xen/arch/x86/hvm/svm/vpmu.c | 115 +---
xen/arch/x86/hvm/vmx/vpmu_core2.c | 154 +++---
xen/arch/x86/hvm/vpmu.c | 35 +
xen/include/asm-x86/hvm/vpmu.h| 2 +
4 files changed, 166 insertions(+), 140 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 61d56d5..8460d7b 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -356,57 +356,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);
@@ -480,30 +429,66 @@ 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)
+{
+if ( current_cpu_data.x86_vendor != X86_VENDOR_AMD )
+return -EINVAL;
+
+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 23e4899..e199367 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,62 +708,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;
-
[Xen-devel] [PATCH v15 20/21] 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
Acked-by: Jan Beulich
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 | 230
xen/include/asm-x86/hvm/vpmu.h | 4 +-
xen/include/asm-x86/softirq.h | 3 +-
6 files changed, 195 insertions(+), 56 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 0830e5f..d7f988e 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1281,11 +1281,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. ...'
@@ -1297,6 +1297,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 7d9ba8c..c21bde0 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;
}
@@ -223,6 +223,7 @@ static inline void context_save(struct vcpu *v)
rdmsrl(counters[i], counter_regs[i]);
}
+/* Must be NMI-safe */
static int amd_vpmu_save(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 839dce0..271fae5 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 vcpu *v)
rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
}
+/* Must be NMI-safe */
static int core2_vpmu_save(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -706,7 +707,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 5f0a871..cf96da7 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -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;
-default:
-if ( !strcmp(s, "bts") )
-vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-else if ( *s )
+char *ss;
+
+vpmu_mode = XENPMU_MODE
[Xen-devel] [PATCH v15 00/21] x86/PMU: Xen PMU PV(H) support
Version 15 of PV(H) PMU patches. 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 registers were set in later patch then needed. Moved those changes to appropriate place * Added new VPMU mode (XENPMU_MODE_HV). Now XENPMU_MODE_SELF will only provide dom0 with its own samples only (i.e. no hypervisor data) and XENPMU_MODE_HV will be what XENPMU_MODE_SELF used to be. * Kept vmx_add_guest_msr()/vmx_add_host_load_msr() as wrappers around vmx_add_msr() * Cleaned up VPMU context switch macros (moved 'if(prev!=next)' back to context_switch()) * Dropped hypercall continuation from vpmu_force_context_switch() and replaced it with -EAGAIN error if hypercall_preempt_check() is true after 2ms. * Kept vpmu_do_rdmsr()/vpmu_do_wrmsr as wrapperd for vpmu_do_msr() * Move context switching patch (#13) earlier in the series (for proper bisection support) * Various comment updates and cleanups * Dropped a bunch of Reviewed-by and all Tested-by tags Changes in v10: * Swapped address and name fields of xenpf_symdata (to make it smaller on 32-bit) * Dropped vmx_rm_guest_msr() as it requires refcountig which makes code more complicated. * Cleaned up vlapic_reg_write() * Call vpmu_destroy() for both HVM and PVH VCPUs * Verify that (xen_pmu_data+PMU register bank) fit into a page * Return error codes from arch-specific VPMU init code * Moved VPMU-related context switch logic into inlines * vpmu_force_context_switch() changes: o Avoid greater than page-sized allocations o Prevent another VCPU from starting VPMU sync while the first sync is in progress * Avoid stack leak in do_xenpmu_op() * Checked validity of Intel VPMU MSR values before they are committed * Fixed MSR handling in traps.c (avoid potential accesses to Intel MSRs on AMD) * Fixed VCPU selection in interrupt handler for 32-bit dom0 (sampled => sampling) * Clarified comm
[Xen-devel] [PATCH v15 07/21] 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
Acked-by: Kevin Tian
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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 f49af97..af3cdb2 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 0b7b607..5c3b2be 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -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 09af846..f44847f 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 aec7b5f..29d9fde 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 v15 01/21] common/symbols: Export hypervisor symbols to privileged guest
Export Xen's symbols as {} triplet via new XENPF_get_symbol
hypercall
Signed-off-by: Boris Ostrovsky
Acked-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Dietmar Hahn
Tested-by: Dietmar Hahn
---
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
#include
#include
+#include
#include
#include
#include
@@ -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
#include
#include
+#include
+#include
#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_GUEST_HANDLE(char) name;
+uint64_t address;
+char type;
+};
+typedef struct xenpf_symdata xenpf_symdata_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_symdata_t);
+
/*
* ` enum neg_errnoval
* ` HYPERVISOR_platform_op(const struct xen_platform_op*);
@@ -587,6 +605,7 @@ struct xen_platform_op {
[Xen-devel] [rumpuserxen test] 31609: regressions - FAIL
flight 31609 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31609/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437 test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 31437 version targeted for testing: rumpuserxen 9716ed62cb1d73254b552e2077497d684c81639d baseline version: rumpuserxen 1eb3666b469e307b20262e856229d0bd5d06a59e People who touched revisions under test: Martin Lucina jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-rumpuserxen-amd64 fail test-amd64-i386-rumpuserxen-i386 fail 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 9716ed62cb1d73254b552e2077497d684c81639d Author: Martin Lucina Date: Tue Nov 11 16:49:40 2014 +0100 Add .gitignore for tests/configure autoconf cruft Signed-off-by: Martin Lucina commit ef7797ab82fdc95ba0edbd38c0f9be1e46c0ea47 Merge: 3dec9eb 62d0714 Author: Martin Lucina Date: Tue Nov 11 16:44:10 2014 +0100 Merge pull request #11 from mato/wip-exit rumpuser_exit(), _exit(): Cleanly halt Mini-OS. commit 62d07142e5b4c77633bd1283ac06bd71f29d777a Author: Martin Lucina Date: Tue Nov 11 16:11:46 2014 +0100 rumpuser_exit(), _exit(): Cleanly halt Mini-OS. rumpuser_exit() and _exit() were calling minios_do_exit() which is intended to be called from an exception context and/or other "panic" situation. This was causing the stack trace code in minios_do_exit() to walk off into never never land when the rumprun-xen application called exit() or returned from main(). This commit adds a new minios_do_halt(reason) function, with the reason code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently only poweroff and crash are implemented. We then modify the rumpuser_exit() and _exit() functions to correctly shut down the domain by calling minios_stop_kernel() followed by minios_do_halt(MINIOS_HALT_POWEROFF). Signed-off-by: Martin Lucina commit 3dec9eb4656a1af934f4c4222476a77384b2c487 Merge: 1eb3666 f5247f8 Author: Martin Lucina Date: Tue Nov 11 15:47:08 2014 +0100 Merge pull request #10 from mato/wip-xenos Clean up Mini-OS namespace commit f5247f87792ab5084664be70b409964691d14f43 Author: Martin Lucina Date: Mon Nov 10 18:12:34 2014 +0100 Reinstate old demos Xen project osstest CI depends on them, and we do not want to remove them before a replacement is ready. Signed-off-by: Martin Lucina commit 8bd474a4674110ca0fd75d557dc40532a63cc35b Author: Martin Lucina Date: Mon Nov 10 11:05:31 2014 +0100 Synchronise x86_32.o with Mini-OS namespace cleanup. These changes sync the x86_32 arch-specific entrypoints with the Mini-OS namespace cleanups. Now builds and runs correctly on x86. Signed-off-by: Martin Lucina commit 038ec394c921b5fed8c3e3afee4e09125726dc8c Author: Martin Lucina Date: Fri Nov 7 18:17:00 2014 +0100 Minor improvement to hello demo Sleep in the demo to prove at least scheduling is working after all the renaming changes. Signed-off-by: Martin Lucina commit 952b8ff86bb756f52a8e194c9e6831c7e39b4d23 Author: Martin Lucina Date: Fri Nov 7 18:14:50 2014 +0100 Localize all non-public Mini-OS symbols Pass 3 of X in Mini-OS namespace cleanup. We define a set of prefixes in the Makefile for the symbol namespaces we wish to keep. Then, when linking minios.o we use objcopy to localize all other symbols. Note the sole exception of the arch-specific startup file (x86_64.o) as this is used as the linker %startfile. Signed-off-by: Martin Lucina commit 4a8991242b6dc5881fc72a8c37a914afe54de042 Author: Martin Lucina Date: Fri Nov 7 17:52:39 2014 +0100 Clean up Mini-OS public namespace Pass 2 of X
[Xen-devel] [rumpuserxen bisection] complete test-amd64-i386-rumpuserxen-i386
branch xen-unstable xen branch xen-unstable job test-amd64-i386-rumpuserxen-i386 test rumpuserxen-demo-xenstorels/xenstorels 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://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen Bug introduced: 62d07142e5b4c77633bd1283ac06bd71f29d777a Bug not present: 3dec9eb4656a1af934f4c4222476a77384b2c487 commit 62d07142e5b4c77633bd1283ac06bd71f29d777a Author: Martin Lucina Date: Tue Nov 11 16:11:46 2014 +0100 rumpuser_exit(), _exit(): Cleanly halt Mini-OS. rumpuser_exit() and _exit() were calling minios_do_exit() which is intended to be called from an exception context and/or other "panic" situation. This was causing the stack trace code in minios_do_exit() to walk off into never never land when the rumprun-xen application called exit() or returned from main(). This commit adds a new minios_do_halt(reason) function, with the reason code intended to mirror SHUTDOWN_* in xen/sched.h. Of those, currently only poweroff and crash are implemented. We then modify the rumpuser_exit() and _exit() functions to correctly shut down the domain by calling minios_stop_kernel() followed by minios_do_halt(MINIOS_HALT_POWEROFF). Signed-off-by: Martin Lucina For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.rumpuserxen.test-amd64-i386-rumpuserxen-i386.rumpuserxen-demo-xenstorels--xenstorels.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 31609 fail [host=gall-mite] / 31437 [host=itch-mite] 31373 ok. Failure / basis pass flights: 31609 / 31373 (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://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: rumpuserxen https://github.com/rumpkernel/rumprun-xen Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd Tree: xen git://xenbits.xen.org/xen.git Latest d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 9716ed62cb1d73254b552e2077497d684c81639d e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2 Basis pass d7892a4c389d54bccb9bce8e65eb053a33bbe290 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 ca78cc83650b535d7e24baeaea32947be0141534 3d8a59f98b15b625babcb8b19d1832d002cc98b0 e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b f02880da13242d962fd0119d093f05d9d13a2eb4 5283b310e14884341f51be35253cdd59c4cb034c Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#d7892a4c389d54bccb9bce8e65eb053a33bbe290-d7892a4c389d54bccb9bce8e65eb053a33bbe290 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#ca78cc83650b535d7e24baeaea32947be0141534-ca78cc83650b535d7e24baeaea32947be0141534 https://github.com/rumpkernel/rumprun-xen#3d8a59f98b15b625babcb8b19d1832d002cc98b0-9716ed62cb1d73254b552e2077497d684c81639d https://github.com/rumpkernel/buildrump.sh.git#e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b-e8eb61896d1f68884b9c39b61e7e1ddb41e90c0b https://github.com/rumpkernel/src-netbsd#f02880da13242d962fd0119d093f05d9d13a2eb4-f02880da13242d962fd0119d093f05d9d13a2eb4 git://xenbits.xen.org/xen.git#5283b310e14884 341f51be35253cdd59c4cb034c-e6fa63d6cf8e79de2cfb2d428269b6d6f698c3d2 + exec + sh -xe + cd /export/home/osstest/repos/rumprun-xen + git remote set-url origin git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumprun-xen + 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/re
[Xen-devel] [xen-4.2-testing test] 31592: regressions - FAIL
flight 31592 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31592/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 18 guest-migrate/dst_host/src_host fail in 31451 REGR. vs. 30594 Tests which are failing intermittently (not blocking): test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail pass in 31451 test-i386-i386-pair 17 guest-migrate/src_host/dst_host fail pass in 31288 test-amd64-i386-pv7 debian-install fail in 31451 pass in 31592 test-amd64-i386-xl-winxpsp3-vcpus1 5 xen-boot fail in 31451 pass in 31592 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail in 31288 pass in 31592 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate/x10 fail in 31288 pass in 31592 test-amd64-i386-xl-win7-amd64 7 windows-install fail in 31288 pass in 31592 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-i386-i386-libvirt9 guest-start fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass build-i386-rumpuserxen5 rumpuserxen-buildfail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-i386-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-qemuu-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-win7-amd64 14 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-i386-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen c844974caf1501b6527533ab2a3d27ea8920ab90 baseline version: xen fad105dd0ac1a224d91757afee01acd4566f7e82 People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass 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-qemuu-freebsd10-amd64pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
Re: [Xen-devel] [Patch v2 2/3] correct xc_domain_save()'s return value
On 11/14/2014 10:57 PM, Ian Jackson wrote:
> Wen Congyang writes ("[Patch v2 2/3] correct xc_domain_save()'s return
> value"):
>> If suspend_and_state() fails, the errno may be 0. But we assume
>> that the errno is not 0. So remove assert().
>
> Thanks for spotting this.
>
> I think this is going in the wrong direction. Perhaps we could
> instead do something like the patch below ? Please let me know what
> you think.
>
> If you think this is a better idea, please submit it as a proper patch
> with a proper commit message.
OK, I will do it.
>
> (Ideally we would fix the actual suspend hook in libxl, to always set
> errno, but that's too invasive a set of changes to do now, I think.)
libxl and helper program are two programs, and we should update the interface
between libxl and the hepler program first. We can do it later.
Thanks
Wen Congyang
>
> Thanks,
> Ian.
>
> Signed-off-by: Ian Jackson
>
> diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
> index 40bbac8..3ab9dd8 100644
> --- a/tools/libxc/include/xenguest.h
> +++ b/tools/libxc/include/xenguest.h
> @@ -35,7 +35,9 @@
> /* callbacks provided by xc_domain_save */
> struct save_callbacks {
> /* Called after expiration of checkpoint interval,
> - * to suspend the guest.
> + * to suspend the guest. Returns 1 for success, or 0 for failure.
> + * On failure it should ideally set errno. (If it leaves errno
> + * as 0, EIO will be used instead.)
> */
> int (*suspend)(void* data);
>
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index 254fdb3..444aac6 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -361,9 +361,15 @@ static int suspend_and_state(int (*suspend)(void*),
> void* data,
> xc_interface *xch, int io_fd, int dom,
> xc_dominfo_t *info)
> {
> +errno = 0;
> if ( !(*suspend)(data) )
> {
> -ERROR("Suspend request failed");
> +if (!errno) {
> +errno = EIO;
> +ERROR("Suspend request failed (without errno, using EINVAL)");
> +} else {
> +ERROR("Suspend request failed");
> +}
> return -1;
> }
>
> .
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough
On 2014/11/5 22:09, Michael S. Tsirkin wrote:
On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
Currently IGD drivers always need to access PCH by 1f.0, and
PCH vendor/device id is used to identify the card.
Signed-off-by: Tiejun Chen
---
hw/i386/pc_piix.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index b559181..b19c7a9 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -50,7 +50,7 @@
#include "cpu.h"
#include "qemu/error-report.h"
#ifdef CONFIG_XEN
-# include
+#include
#endif
#define MAX_IDE_BUS 2
@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
}
#ifdef CONFIG_XEN
+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
+{
+struct PCIDevice *dev;
+Error *local_err = NULL;
+uint16_t device_id = 0x;
+
+/* Currently IGD drivers always need to access PCH by 1f.0. */
+dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
+"xen-igd-passthrough-isa-bridge");
+
+/* Identify PCH card with its own real vendor/device ids.
+ * Here that vendor id is always PCI_VENDOR_ID_INTEL.
+ */
+if (dev) {
+device_id = object_property_get_int(OBJECT(dev), "device-id",
+&local_err);
+if (!local_err && device_id != 0x) {
+pci_config_set_device_id(dev->config, device_id);
+return;
+}
+}
+
+fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
+}
+
static void pc_xen_hvm_init(MachineState *machine)
{
PCIBus *bus;
@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
bus = pci_find_primary_bus();
if (bus != NULL) {
pci_create_simple(bus, -1, "xen-platform");
+xen_igd_passthrough_isa_bridge_create(bus);
}
}
#endif
Can't we defer this step until the GPU is added?
Sounds great but I can't figure out where we can to do this exactly.
This way there won't be need to poke at host device
directly, you could get all info from dev->config
of the host device.
As I understand We have two steps here:
#1 At first I have to write something to check if we're registering
00:02.0 & IGD, right? But where? While registering each pci device?
#2 Then if that condition is matched, we register this ISA bridge on its
associated bus.
Thanks
Tiejun
Additionally the correct bridge would be initialized automatically.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V2] Decouple SnadyBridge quirk form VTd timeout
Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register. This is the wrong timeout to use and, at
1000 msec, is much too large. Change this behavior by adding a new
boot paramter, snb_igd_timeout, that can specify the timeout to be used
when accessing the IGD registers in the quirk code.
For compatibility purposes, specifying the current boolean parameter,
snb_igd_quirk, will enable the quirk code with a timeout of 1000 msec.
Specifying the new parameter, snb_igd_timeout, with no value will
enable the quirk code with the theoretical maximum timeout of
670 msec. Specifying a value for this parameter sets the timeout
to that number of msec.
Signed-off-by: Don Dugger
diff -r 9d485e2c8339 xen/drivers/passthrough/vtd/quirks.c
--- a/xen/drivers/passthrough/vtd/quirks.c Mon Nov 10 12:03:36 2014 +
+++ b/xen/drivers/passthrough/vtd/quirks.c Sun Nov 16 17:28:17 2014 -0700
@@ -50,6 +50,9 @@
#define IS_ILK(id)(id == 0x00408086 || id == 0x00448086 || id== 0x00628086
|| id == 0x006A8086)
#define IS_CPT(id)(id == 0x01008086 || id == 0x01048086)
+#define SNB_IGD_TIMEOUTMILLISECS(670)
+static u32 snb_igd_timeout = MILLISECS(1000);
+
static u32 __read_mostly ioh_id;
static u32 __initdata igd_id;
bool_t __read_mostly rwbf_quirk;
@@ -158,6 +161,20 @@
* Workaround is to prevent graphics get into RC6
* state when doing VT-d IOTLB operations, do the VT-d
* IOTLB operation, and then re-enable RC6 state.
+ *
+ * This code, enabled by the Xen command line parameter
+ * snb_igd_quirk, due to legacy issues, uses th VTd timeout
+ * of 1000 msec. This timeout is too large so a second
+ * integer parameter, snb_igd_timeout, can be used to fine
+ * tune the IGD register access timeout.
+ *
+ * Specifying snb_igd_timeout with no value enables this
+ * quirk and sets the timeout to the theoretical maximum
+ * of 670 msec. Setting this parameter with a value enables
+ * this quirk and sets the timeout to that value.
+ *
+ * If neither snb_igd_quirk nor snb_igd_timeout are specified
+ * then the quirk code is not enabled.
*/
static void snb_vtd_ops_preamble(struct iommu* iommu)
{
@@ -177,7 +194,7 @@
start_time = NOW();
while ( (*(volatile u32 *)(igd_reg_va + 0x22AC) & 0xF) != 0 )
{
-if ( NOW() > start_time + DMAR_OPERATION_TIMEOUT )
+if ( NOW() > start_time + snb_igd_timeout )
{
dprintk(XENLOG_INFO VTDPREFIX,
"snb_vtd_ops_preamble: failed to disable idle
handshake\n");
@@ -237,6 +254,18 @@
}
}
+static void __init parse_snb_timeout(const char *s)
+{
+
+ if (*s == '\0')
+ snb_igd_timeout = SNB_IGD_TIMEOUT;
+ else
+ snb_igd_timeout = MILLISECS(simple_strtoul(s, &s, 0));
+ snb_igd_quirk = 1;
+ return;
+}
+custom_param("snb_igd_timeout", parse_snb_timeout);
+
/* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
* Fixed in stepping C-2. */
static void __init tylersburg_intremap_quirk(void)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 31618: regressions - FAIL
flight 31618 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31618/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 guest-start fail REGR. vs. 30603 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30603 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-sedf 5 xen-bootfail pass in 31599 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 7 debian-install fail in 31599 REGR. vs. 30603 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail 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-i386-xl-win7-amd64 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-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-i386-xl-qemuu-win7-amd64 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-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 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-i386-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: qemuu4e70f9271dabc58fbf14680843bfac510c193152 baseline version: qemuub00a0ddb31a393b8386d30a9bef4d9bbb249e7ec People who touched revisions under test: Adam Crume Alex Bennée Alex Williamson Alexander Graf Alexey Kardashevskiy Amit Shah Amos Kong Andreas Färber Andrew Jones Ard Biesheuvel Aurelien Jarno Bastian Koppelmann Bharata B Rao Bin Wu Chao Peng Chen Fan Chen Gang Chenliang Chris Johns Chris Spiegel Christian Borntraeger Claudio Fontana Cole Robinson Corey Minyard Cornelia Huck David Gibson David Hildenbrand Denis V. Lunev Don Slutz Dongxue Zhang Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Eduardo Otubo Fabian Aggeler Fam Zheng Frank Blaschka Gal Hammer Gerd Hoffmann Gonglei Greg Bellows Gu Zheng Hannes Reinecke Heinz Graalfs Igor Mammedov James Harper James Harper Jan Kiszka Jan Vesely Jens Freimann Joel Schopp John Snow Jonas Gorski Jonas Maebe Juan Quintela Juan Quintela Jun Li Kevin Wolf KONRAD Frederic Laszlo Ersek Leon Alrae Li Liang Li Liu Luiz Capitulino Maciej W. Rozycki Magnus Reftel Marc-André Lureau Marcel Apfelbaum Mark Cave-Ayland Markus Armbruster Martin Decky Martin Simmons Max Filippov Max Reitz Michael Ellerman Michael Roth Michael S. Tsirkin Michael Tokarev Michael Walle (for lm32) Michal Privoznik Mikhail Ilyin Ming Lei Nikita Belov Nikunj A Dadhania Paolo Bonzini Paul Moore Pavel Dovgalyuk Peter Crosthwaite Peter Lieven Peter Maydell Peter Wu Petr Matousek Philipp Gesang Pierre Mallard Ray Strode Richard Jones Richard W.M. Jones Riku Voipio Rob Herring Roger Pau Monne Roger Pau Monné Sebastian Krahmer SeokYeon Hwang Sergey Fedorov Stefan Berger Stefan Hajnoczi Stefano Stabellini Thomas Huth Ting Wang Tom Musta Tony Breeds Wei Huang Willem Pinckaers Yongbok Kim Zhang Haoyu zhanghailiang Zhu Guihua jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build
[Xen-devel] support for sharing huge pages with grant table?
Hi, I am curious if Xen currently supports sharing hugepages between domains (specifically ones originally allocated in Dom-0 and shared with a guest r/w). I've seen some references to huge pages in the archives of this list, but not in relation to the grant mechanism. Also, can someone confirm that "superpages" are another term for "huge pages" in Xen? This would be helpful for some work we are doing on high speed networking to VMs---DPDK stores packets into huge pages and we'd like to get those to VMs as quickly as possible. thanks! Tim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 00/18] x86: Full support of PAT
On 11/16/2014 02:08 PM, Ingo Molnar wrote: * Juergen Gross wrote: arch/x86/include/asm/cacheflush.h | 38 --- FYI, this series breaks the UML build: In file included from /home/mingo/tip/include/linux/highmem.h:11:0, from /home/mingo/tip/include/linux/pagemap.h:10, from /home/mingo/tip/include/linux/mempolicy.h:14, from /home/mingo/tip/include/linux/shmem_fs.h:6, from /home/mingo/tip/init/do_mounts.c:30: /home/mingo/tip/arch/x86/include/asm/cacheflush.h:67:36: error: return type is an incomplete type static inline enum page_cache_mode get_page_memtype(struct page *pg) ^ /home/mingo/tip/arch/x86/include/asm/cacheflush.h: In function ‘get_page_memtype’: /home/mingo/tip/arch/x86/include/asm/cacheflush.h:69:2: warning: ‘return’ with a value, in function returning void [enabled by default] return -1; ^ /home/mingo/tip/arch/x86/include/asm/cacheflush.h: At top level: /home/mingo/tip/arch/x86/include/asm/cacheflush.h:72:30: error: parameter 2 (‘memtype’) has incomplete type enum page_cache_mode memtype) ^ /home/mingo/tip/arch/x86/include/asm/cacheflush.h:71:20: error: function declaration isn’t a prototype [-Werror=strict-prototypes] Thomas already committed a fixup. Thank you, Thomas. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-unstable test] 31603: tolerable FAIL - PUSHED
flight 31603 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31603/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 9 guest-start fail pass in 31574 test-amd64-amd64-pair 8 xen-boot/dst_host fail pass in 31574 test-amd64-i386-xl5 xen-boot fail in 31574 pass in 31603 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail in 31574 pass in 31603 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 31237 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-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-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-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-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-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-armhf-armhf-xl 10 migrate-support-check fail in 31574 never pass version targeted for testing: qemuuabbbc2f09a53f8f9ee565356ab11a78af006e45e baseline version: qemuuca78cc83650b535d7e24baeaea32947be0141534 People who touched revisions under test: Roger Pau Monne Roger Pau Monné Stefano Stabellini jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass 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-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 test-amd64-i386-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt fail test-armhf-armhf-l
[Xen-devel] [PATCH] libxc: Expose the pdpe1gb cpuid flag to guest
If hardware support the pdpe1gb flag, expose it to guest by default. Users don't have to use a 'cpuid= ' option in config file to turn it on. Signed-off-by: Liang Li --- tools/libxc/xc_cpuid_x86.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index a18b1ff..c97f91a 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -109,6 +109,7 @@ static void amd_xc_cpuid_policy( regs[3] &= (0x0183f3ff | /* features shared with 0x0001:EDX */ bitmaskof(X86_FEATURE_NX) | bitmaskof(X86_FEATURE_LM) | +bitmaskof(X86_FEATURE_PAGE1GB) | bitmaskof(X86_FEATURE_SYSCALL) | bitmaskof(X86_FEATURE_MP) | bitmaskof(X86_FEATURE_MMXEXT) | @@ -192,6 +193,7 @@ static void intel_xc_cpuid_policy( bitmaskof(X86_FEATURE_ABM)); regs[3] &= (bitmaskof(X86_FEATURE_NX) | bitmaskof(X86_FEATURE_LM) | +bitmaskof(X86_FEATURE_PAGE1GB) | bitmaskof(X86_FEATURE_SYSCALL) | bitmaskof(X86_FEATURE_RDTSCP)); break; @@ -386,6 +388,7 @@ static void xc_cpuid_hvm_policy( clear_bit(X86_FEATURE_LM, regs[3]); clear_bit(X86_FEATURE_NX, regs[3]); clear_bit(X86_FEATURE_PSE36, regs[3]); +clear_bit(X86_FEATURE_PAGE1GB, regs[3]); } break; -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC][PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough
On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
> On 2014/11/5 22:09, Michael S. Tsirkin wrote:
> >On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
> >>Currently IGD drivers always need to access PCH by 1f.0, and
> >>PCH vendor/device id is used to identify the card.
> >>
> >>Signed-off-by: Tiejun Chen
> >>---
> >> hw/i386/pc_piix.c | 28 +++-
> >> 1 file changed, 27 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >>index b559181..b19c7a9 100644
> >>--- a/hw/i386/pc_piix.c
> >>+++ b/hw/i386/pc_piix.c
> >>@@ -50,7 +50,7 @@
> >> #include "cpu.h"
> >> #include "qemu/error-report.h"
> >> #ifdef CONFIG_XEN
> >>-# include
> >>+#include
> >> #endif
> >>
> >> #define MAX_IDE_BUS 2
> >>@@ -452,6 +452,31 @@ static void pc_init_isa(MachineState *machine)
> >> }
> >>
> >> #ifdef CONFIG_XEN
> >>+static void xen_igd_passthrough_isa_bridge_create(PCIBus *bus)
> >>+{
> >>+struct PCIDevice *dev;
> >>+Error *local_err = NULL;
> >>+uint16_t device_id = 0x;
> >>+
> >>+/* Currently IGD drivers always need to access PCH by 1f.0. */
> >>+dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
> >>+"xen-igd-passthrough-isa-bridge");
> >>+
> >>+/* Identify PCH card with its own real vendor/device ids.
> >>+ * Here that vendor id is always PCI_VENDOR_ID_INTEL.
> >>+ */
> >>+if (dev) {
> >>+device_id = object_property_get_int(OBJECT(dev), "device-id",
> >>+&local_err);
> >>+if (!local_err && device_id != 0x) {
> >>+pci_config_set_device_id(dev->config, device_id);
> >>+return;
> >>+}
> >>+}
> >>+
> >>+fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed\n");
> >>+}
> >>+
> >> static void pc_xen_hvm_init(MachineState *machine)
> >> {
> >> PCIBus *bus;
> >>@@ -461,6 +486,7 @@ static void pc_xen_hvm_init(MachineState *machine)
> >> bus = pci_find_primary_bus();
> >> if (bus != NULL) {
> >> pci_create_simple(bus, -1, "xen-platform");
> >>+xen_igd_passthrough_isa_bridge_create(bus);
> >> }
> >> }
> >> #endif
> >
> >Can't we defer this step until the GPU is added?
>
> Sounds great but I can't figure out where we can to do this exactly.
>
> >This way there won't be need to poke at host device
> >directly, you could get all info from dev->config
> >of the host device.
>
> As I understand We have two steps here:
>
> #1 At first I have to write something to check if we're registering 00:02.0
> & IGD, right? But where? While registering each pci device?
In xen_pt_initfn.
Just check the device and vendor ID against the table you have.
> #2 Then if that condition is matched, we register this ISA bridge on its
> associated bus.
>
> Thanks
> Tiejun
Yep.
> >Additionally the correct bridge would be initialized automatically.
> >
> >
> >>--
> >>1.9.1
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
Hi, The wiki page is ready. I am not sure whether I am using the correct format or not. Please let me know if any changes are need. Thanks, http://wiki.xenproject.org/wiki/Xen_via_libvirt_for_OpenStack_juno -Xing On Fri, Nov 14, 2014 at 2:01 AM, Ian Campbell wrote: > On Thu, 2014-11-13 at 22:54 -0700, Xing Lin wrote: > > I have been blocked by this problem for almost three weeks and as far > > as I know, I could not find any online tutorial on setting up xen > > based compute node for openstack juno. I will document steps I take > > and share them with the community. > > Awesome, thanks! > > Having this in the Xen wiki would be awesome. If you would like write > access to our wiki (which is granted manually due to spammers spoiling > it for everyone...) then please: > > * Create an account using the "create account" link at the > top-right hand side of http://wiki.xen.org/wiki/Main_Page > * Fill in this form giving your chosen username: > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html > > You could alternatively drop me a line privately with the user name for > the second step, but filling in the form might give a quicker response > time due to reaching multiple people in multiple timezones... > > Ian. > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps
On 2014/11/14 16:21, Jan Beulich wrote: On 14.11.14 at 03:21, wrote: Even if eventually we'll reorder that sequence, this just change that approach to get BDF. Are you fine to this subsequent change? You again pass a struct domain pointer to the IOMMU-specific function. I already told you not to do so - the domain specific I remembered this comment but I want to show this may introduce many duplicated codes. As I understand this kind of check should be a common thing dependent on one given platform. aspect should be taken care of by the callback function, i.e. you need to make SBDF available to it (just like you already properly did in the previous round for BDF). I suppose that'll at once make the ugly open coding of for_each_rmrr_device() unnecessary - you can just use that construct as replacement for what right now is list_for_each_entry(). Okay, I will try to go there. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 07/15] libxl: disallow attaching the same device more than once
> Originally the code allowed users to attach the same device more than
> once. It just stupidly overwrites xenstore entries. This is bogus as
> frontend will be very confused.
>
> Introduce a helper function to check if the device to be written to
> xenstore already exists. A new error code is also introduced.
>
> The check and add are within one xs transaction.
>
> Signed-off-by: Wei Liu
> ---
I find this patch will cause the pci-attach failed if more than one virtual
function devices are attached to the guest.
> @@ -148,15 +150,32 @@ static int libxl__device_pci_add_xenstore(libxl__gc
> *gc,
> uint32_t domid, libxl_d
> if (!starting)
> flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 7));
>
> -retry_transaction:
> -t = xs_transaction_start(ctx->xsh);
> -libxl__xs_writev(gc, t, be_path,
> -libxl__xs_kvs_of_flexarray(gc, back, back->count));
> -if (!xs_transaction_end(ctx->xsh, t, 0))
> -if (errno == EAGAIN)
> -goto retry_transaction;
> +GCNEW(device);
> +libxl__device_from_pcidev(gc, domid, pcidev, device);
> -return 0;
> +for (;;) {
> +rc = libxl__xs_transaction_start(gc, &t);
> +if (rc) goto out;
> +
> +rc = libxl__device_exists(gc, t, device);
> +if (rc < 0) goto out;
> +if (rc == 1) {
> +LOG(ERROR, "device already exists in xenstore");
> +rc = ERROR_DEVICE_EXISTS;
> +goto out;
> +}
The libxl__device_exists will return 1 if more than one PCI devices are
attached to the guest, no matter the BDFs are identical or not.
I don't understand why to check this condition here, if the same device was
attached more than once the xc_test_assign_device() will return error,
and the libxl__device_pci_add_xenstore() will not be called. It seems
unnecessary.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps
On 2014/11/12 16:55, Jan Beulich wrote:
On 12.11.14 at 04:05, wrote:
I don't see any feedback to this point, so I think you still prefer we
should do all check in the callback function.
As a draft this looks reasonable, but there are various bugs to be
dealt with along with cosmetic issues (I'll point out the former, but
I'm tired of pointing out the latter once again - please go back to
earlier reviews of patches to refresh e.g. what types to use for
loop variables).
'earlier reviews' means this subject email? I go back to check this but
just see this comment related to our loop codes:
"
>>> +for ( i = 0; i < xdsr->num_pcidevs; ++i )
>>> +{
>>> +if ( __copy_from_guest_offset(pcidevs, xdsr->pcidevs,
i, 1) )
>>> +{
>>> +xfree(pcidevs);
>>> +return -EFAULT;
>>> +}
>>> +}
>>
>> I don't see the need for a loop here. And you definitely can't use the
>> double-underscore-prefixed variant the way you do.
>
> Do you mean this line?
>
> copy_from_guest_offset(pcidevs, xdsr->pcidevs, 0,
> xdsr->num_pcidevs*sizeof(xen_guest_pcidev_info_t))
Almost:
copy_from_guest(pcidevs, xdsr->pcidevs, xdsr->num_pcidevs *
sizeof(*pcidevs))
"
Or I need to set as 'unsigned int' here?
Anyway I did this in the following codes firstly. If I'm still wrong I
will correct that.
I tried to address this but obviously we have to pass each 'pdf' to
callback functions,
Yes, but at the generic IOMMU layer this shouldn't be named "bdf",
but something more neutral (maybe "id"). And you again lost the
segment there.
@@ -36,9 +40,24 @@ static int get_reserved_device_memory(xen_pfn_t start,
if ( rdm.start_pfn != start || rdm.nr_pages != nr )
return -ERANGE;
-if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
- &rdm, 1) )
-return -EFAULT;
+if ( d->arch.hvm_domain.pci_force )
+{
+if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
+ &rdm, 1) )
+return -EFAULT;
+}
+else
+{
+for ( i = 0; i < d->arch.hvm_domain.num_pcidevs; i++ )
+{
+pt_bdf = PCI_BDF2(d->arch.hvm_domain.pcidevs[i].bus,
+ d->arch.hvm_domain.pcidevs[i].devfn);
+if ( pt_bdf == bdf )
+if ( __copy_to_compat_offset(grdm->map.buffer,
grdm->used_entries,
+ &rdm, 1) )
+return -EFAULT;
I think d->arch.hvm_domain.pcidevs[] shouldn't contain duplicates,
and hence there's no point continuing the loop if you found a match.
+}
+}
}
++grdm->used_entries;
This should no longer get incremented unconditionally.
@@ -314,6 +333,7 @@ int compat_memory_op(unsigned int cmd,
XEN_GUEST_HANDLE_PARAM(void) compat)
return -EFAULT;
grdm.used_entries = 0;
+grdm.domain = current->domain;
rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
&grdm);
Maybe I misguided you with an earlier response, or maybe the
earlier reply was in a different context: There's no point
communicating current->domain to the callback function; there
would be a point communicating the domain if it was _not_
always current->domain.
So we need the caller to pass domain ID, right?
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index af613b9..314d7e6 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -22,10 +22,13 @@ struct get_reserved_device_memory {
unsigned int used_entries;
};
-static int get_reserved_device_memory(xen_pfn_t start,
- xen_ulong_t nr, void *ctxt)
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
u16 seg,
+ u16 *ids, int cnt, void *ctxt)
{
struct get_reserved_device_memory *grdm = ctxt;
+struct domain *d = get_domain_by_id(grdm->map.domid);
+unsigned int i, j;
+u32 sbdf, pt_sbdf;
if ( grdm->used_entries < grdm->map.nr_entries )
{
@@ -36,13 +39,37 @@ static int get_reserved_device_memory(xen_pfn_t start,
if ( rdm.start_pfn != start || rdm.nr_pages != nr )
return -ERANGE;
-if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
- &rdm, 1) )
-return -EFAULT;
+if ( d->arch.hvm_domain.pci_force )
+{
+if ( __copy_to_compat_offset(grdm->map.buffer,
grdm->used_entries,
+ &rdm, 1) )
+return -EFAULT;
+++grdm->used_entries;
+}
+else
+{
+for ( i = 0; i
