[Xen-devel] [ovmf test] 111621: all pass - PUSHED

flight 111621 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111621/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c82fc2b555285306904c9c1ed6524a85bee8841a baseline version: ovmf e9651c12721d882f384ef

[Xen-devel] [linux-3.18 test] 111614: regressions - FAIL

flight 111614 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111614/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 REGR. vs. 110441 Tes

Re: [Xen-devel] [PATCH v13 01/23] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

On 17-07-07 12:37:28, Meng Xu wrote: > > + Sample cache capacity bitmasks for a bitlength of 8 are shown below. > > Please > > + note that all (and only) contiguous '1' combinations are allowed (e.g. > > H, > > + 0FF0H, 003CH, etc.). > > IIRC, the number of contiguous '1's in CBM should b

[Xen-devel] patch to the latest version of oprofile

Hi, I am an worker of intel. I am working on xengt now. I want to test the performance of xengt with skylake platform. As we know, the platform is supported by the latest version of oprofile-1.1.0. But I don't know if the "oprofile-0.9.5-xen.patch

[Xen-devel] [libvirt test] 111604: tolerable all pass - PUSHED

flight 111604 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/111604/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 111552 test-armhf-armhf-libvirt-xsm 14 saveresto

[Xen-devel] [qemu-mainline test] 111601: regressions - FAIL

flight 111601 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/111601/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 111403 test-armhf-armhf-

[Xen-devel] [PATCH v8 0/7] Add LMCE support

Changes in v8: * Adjust the generalization of setting vMCE parameters in patch 1&2. * Other patches are not changed. Haozhong Zhang (7): [M ] 1/7 x86/domctl: generalize the restore of vMCE parameters [ M ] 2/7 x86/vmce: emulate MSR_IA32_MCG_EXT_CTL [ R ] 3/7 x86/vmce: enable injecting

[Xen-devel] [PATCH v8 1/7] x86/domctl: generalize the restore of vMCE parameters

vMCE parameters in struct xen_domctl_ext_vcpucontext were extended in the past, and is likely to be extended in the future. When migrating a PV domain from old Xen, XEN_DOMCTL_set_ext_vcpucontext should handle the differences. Instead of adding ad-hoc handling code at each extension, we introduce

[Xen-devel] [PATCH v8 2/7] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest to read/write MSR_IA32_MCG_EXT_CTL. Signed-off-by: Haozhong Zhang --- Cc: Jan Beulich Cc: Andrew Cooper Changes in v8: * Use offsetof() + sizeof() (VMCE_SIZE()) in valid_sizes[]. --- xen/arch/x86/cpu/mcheck/vmce.c |

[Xen-devel] [PATCH v8 4/7] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP. By default, LMCE is not exposed to guest so as to keep the backwards migration compatibility. Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v8 3/7] x86/vmce: enable injecting LMCE to guest on Intel host

Inject LMCE to guest if the host MCE is LMCE and the affected vcpu is known. Otherwise, broadcast MCE to all vcpus on Intel host. Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/cpu/mcheck/mcaction.c | 23 --- x

[Xen-devel] [PATCH v8 5/7] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/cpu/mcheck/mce.c | 24 +++- xen/include/public/arch-x86/xen-mca.h | 1 + 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/mc

[Xen-devel] [PATCH v8 7/7] tools/xen-mceinj: add support of injecting LMCE

If option '-l' or '--lmce' is specified and the host supports LMCE, xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c' is not present). Signed-off-by: Haozhong Zhang Acked-by: Wei Liu --- Cc: Ian Jackson Cc: Wei Liu --- tools/tests/mce-test/tools/xen-mceinj.c | 50 +

[Xen-devel] [PATCH v8 6/7] tools/libxc: add support of injecting MC# to specified CPUs

Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the current xc_mca_op() does not use this feature and not provide an interface to callers. This commit add a new xc_mca_op_inject_v2() that receives a cpumap providing the set of target CPUs. Signed-off-by: Haozhong Zhang Acked-by: W

Re: [Xen-devel] [PATCH v4 3/4] VT-d PI: restrict the vcpu number on a given pcpu

On Fri, Jul 07, 2017 at 09:57:47AM -0600, Jan Beulich wrote: On 07.07.17 at 08:48, wrote: >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -95,22 +95,91 @@ static DEFINE_PER_CPU(struct vmx_pi_blocking_vcpu, >> vmx_pi_blocking); >> uint8_t __read_mostly posted_in

Re: [Xen-devel] [PATCH v4 1/4] VT-d PI: track the vcpu number on pi blocking list

On Fri, Jul 07, 2017 at 09:41:18AM -0600, Jan Beulich wrote: On 07.07.17 at 08:48, wrote: >> This patch adds a field, counter, in struct vmx_pi_blocking_vcpu to track >> how many entries are on the pi blocking list. >> >> Signed-off-by: Chao Gao > >Looks okay now, but didn't you have ASSERT

Re: [Xen-devel] [PATCH v4 4/4] Xentrace: add support for HVM's PI blocking list operation

On Fri, Jul 07, 2017 at 09:37:04AM -0600, Jan Beulich wrote: On 07.07.17 at 08:49, wrote: >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -190,7 +190,9 @@ static void vmx_vcpu_block(struct vcpu *v) >> */ >> ASSERT(old_lock == NULL); >> >> -per_cp

[Xen-devel] [xen-unstable test] 111589: regressions - FAIL

flight 111589 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/111589/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 111506 test-armhf-

Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1

On Fri, Jul 07, 2017 at 06:39:03PM +0200, Andreas Kinzler wrote: > Hello, > > I noticed that PCI passthrough for an LSI SAS HBA 9211 did not longer work > (at least under Windows) when using Xen 4.8.1. > I then bisected through various released versions and finally I narrowed it > down to > > 4

[Xen-devel] [linux-3.18 test] 111591: regressions - FAIL

flight 111591 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111591/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 REGR. vs. 110441 Tes

[Xen-devel] [linux-linus test] 111580: regressions - FAIL

flight 111580 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/111580/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 7 xen-bootfail REGR. vs. 110515 test-amd64-amd64-xl

[Xen-devel] [PATCH] xen_pt_msi.c: Check for xen_host_pci_get_* failures in xen_pt_msix_init()

Check the return status of the xen_host_pci_get_* functions we call in xen_pt_msix_init(), and fail device init if the reads failed rather than ploughing ahead. (Spotted by Coverity: CID 777338.) Signed-off-by: Peter Maydell --- Disclaimer: compile tested only! The only other Xen-related Coverit

[Xen-devel] [xen-4.8-testing baseline-only test] 71675: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71675 xen-4.8-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71675/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-

[Xen-devel] [libvirt test] 111552: tolerable all pass - PUSHED

flight 111552 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/111552/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 111458 test-armhf-armhf-libvirt-xsm 14 saveresto

Re: [Xen-devel] maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On 08/07/17 02:59, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote: >> On 28/03/17 16:27, Boris Ostrovsky wrote: >>> On 03/28/2017 04:08 AM, Jan Beulich wrote: >>> On 28.03.17 at 03:57, wrote: > I think there is indeed a disconnect between targe

[Xen-devel] [qemu-mainline test] 111548: regressions - FAIL

flight 111548 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/111548/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 111403 test-armhf-armhf-

[Xen-devel] [xen-unstable-coverity test] 111597: regressions - ALL FAIL

flight 111597 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/111597/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: coverity-amd646 coverity-build fail REGR. vs. 40 version t

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-libvirt-pair

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-libvirt-pair testid guest-start/debian Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: linux git://git

[Xen-devel] [PATCH 15/15] xen: tools: expose EPC in ACPI table

On physical machine EPC is exposed in ACPI table via "INT0E0C". Although EPC can be discovered by CPUID but Windows driver requires EPC to be exposed in ACPI table as well. This patch exposes EPC in ACPI table. Signed-off-by: Kai Huang --- tools/firmware/hvmloader/util.c | 23 ++

[Xen-devel] [PATCH 14/15] xen: tools: add SGX to applying CPUID policy

In libxc, a new structure 'xc_cpuid_policy_build_info_t' is added to carry domain's EPC base and size info from libxl. libxl_cpuid_apply_policy is also changed to take 'libxl_domain_build_info_t' as parameter, where domain's EPC base and size can be got and passed to xc_cpuid_apply_policy. xc_cpuid

[Xen-devel] [PATCH 13/15] xen: tools: add new 'epc' parameter support

In order to be able to configure domain's EPC size when it is created, a new 'epc' parameter is added to XL configuration file. Like memory it indicates EPC size in MB. A new 'libxl_sgx_buildinfo', which contains EPC base and size, is also added to libxl_domain_buind_info. EPC base and size are als

[Xen-devel] [PATCH 05/15] xen: p2m: new 'p2m_epc' type for EPC mapping

A new 'p2m_epc' type is added for EPC mapping type. Two wrapper functions set_epc_p2m_entry and clear_epc_p2m_entry are also added for further use. Signed-off-by: Kai Huang --- xen/arch/x86/mm/p2m-ept.c | 3 +++ xen/arch/x86/mm/p2m.c | 41 + xen/inclu

[Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

Currently Xen only has non-cacheable version of ioremap. Although EPC is reported as reserved memory in e820 but it can be mapped as cacheable. This patch adds ioremap_cache (cacheable version of ioremap). Signed-off-by: Kai Huang --- xen/arch/x86/mm.c | 15 +-- xen/include/xen/

[Xen-devel] [PATCH 08/15] xen: x86: add SGX cpuid handling support.

This patch adds SGX to cpuid handling support. In init_guest_cpuid, for raw_policy and host_policy, physical EPC info is reported, but for pv_max_policy and hvm_max_policy EPC is hidden, as for particular domain, it's EPC base and size are from tookstack, and it is meaningless to contain physical E

[Xen-devel] [PATCH 07/15] xen: x86: add functions to populate and destroy EPC for domain

Add per-domain structure to store SGX per-domain info. Currently only domain's EPC base and size are stored. Also add new functions for further use: - hvm_populate_epc # populate EPC when EPC base & size are notified. - hvm_reset_epc # Reset domain's EPC to be invalid. Used when domain

[Xen-devel] [PATCH 10/15] xen: vmx: handle ENCLS VMEXIT

Currently EPC are statically allocated and mapped to guest, we don't have to trap ENCLS as it runs perfectly in VMX non-root mode. But exposing SGX to guest means we also expose ENABLE_ENCLS bit to L1 hypervisor, therefore we cannot stop L1 from enabling ENCLS VMEXIT. For ENCLS VMEXIT from L2 guest

[Xen-devel] [PATCH 11/15] xen: vmx: handle VMEXIT from SGX enclave

VMX adds new bit to both exit_reason and GUEST_INTERRUPT_STATE to indicate whether VMEXIT happens in Enclave. Several instructions are also invalid or behave differently in enclave according to SDM. This patch handles those cases. Signed-off-by: Kai Huang --- xen/arch/x86/hvm/vmx/vmx.c |

[Xen-devel] [PATCH 02/15] xen: vmx: detect ENCLS VMEXIT

If ENCLS VMEXIT is not present then we cannot support SGX virtualization. This patch detects presence of ENCLS VMEXIT. A Xen boot boolean parameter 'sgx' is also added to manually enable/disable SGX. Signed-off-by: Kai Huang --- xen/arch/x86/hvm/vmx/vmcs.c| 17 + xen/incl

[Xen-devel] [PATCH 12/15] xen: x86: reset EPC when guest got suspended.

EPC is destroyed when power state goes to S3-S5. Emulate this behavior. A new function s3_suspend is added to hvm_function_table for this purpose. Signed-off-by: Kai Huang --- xen/arch/x86/hvm/hvm.c| 3 +++ xen/arch/x86/hvm/vmx/vmx.c| 7 +++ xen/include/asm-x86/hvm/hvm.h | 3 +++

[Xen-devel] [PATCH 03/15] xen: x86: add early stage SGX feature detection

This patch adds early stage SGX feature detection via SGX CPUID 0x12. Function detect_sgx is added to detect SGX info on each CPU (called from vmx_cpu_up). SDM says SGX info returned by CPUID is per-thread, and we cannot assume all threads will return the same SGX info, so we have to detect SGX for

[Xen-devel] [PATCH 06/15] xen: x86: add SGX basic EPC management

EPC is limited resource reserved by BIOS. Typically EPC size is from dozens of MB to more than a hundred MB. EPC is reported as reserved memory in e820 but not normal memory. EPC must be managed in 4K pages. From implementation's view, we can choose either to manage EPC separately, or to extend ex

[Xen-devel] [PATCH 09/15] xen: vmx: handle SGX related MSRs

This patch handles IA32_FEATURE_CONTROL and IA32_SGXLEPUBKEYHASHn MSRs. For IA32_FEATURE_CONTROL, if SGX is exposed to domain, then SGX_ENABLE bit is always set. If SGX launch control is also exposed to domain, and physical IA32_SGXLEPUBKEYHASHn are writable, then SGX_LAUNCH_CONTROL_ENABLE bit is

[Xen-devel] [PATCH 01/15] xen: x86: expose SGX to HVM domain in CPU featureset

Expose SGX in CPU featureset for HVM domain. SGX will not be supported for PV domain, as ENCLS (which SGX driver in guest essentially runs) must run in ring 0, while PV kernel runs in ring 3. Theoretically we can support SGX in PV domain via either emulating #GP caused by ENCLS running in ring 3, o

[Xen-devel] [RFC PATCH 00/15] RFC: SGX virtualization design and draft patches

Hi all, This series is RFC Xen SGX virtualization support design and RFC draft patches. Intel SGX (Software Guard Extensions) is a new set of instructions and memory access mechanisms targetting for application developers seeking to protect select code and data from disclosure or modification. T

[Xen-devel] [xen-4.8-testing test] 111538: tolerable FAIL - PUSHED

flight 111538 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/111538/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 47 xtf/test-hvm64-lbr-tsx-vmentry fail like 111005 test-armhf-armhf-xl-rtds 16 g