Re: [Xen-devel] [PATCH v2] docs: note default for timer_mode in xl.cfg man

On Mon, Jan 15, 2018 at 08:45:51AM -0600, Doug Goldstein wrote: > There was no default documented but the header at > xen/include/public/hvm/params.h stated which the default was, so add it > to the docs. While looking at libxl code I've found the following (it's at the end of

[Xen-devel] [libvirt test] 118006: regressions - FAIL

flight 118006 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/118006/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 117772 build-i386-libvirt

Re: [Xen-devel] [PATCH v8 10/17] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

On 01/15/2018 06:11 AM, Jan Beulich wrote: On 12.01.18 at 19:01, wrote: For performance reasons, HVM guests should have direct access to these MSRs when possible. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [linux-linus test] 117996: tolerable FAIL - PUSHED

flight 117996 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/117996/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 117945 test-armhf-armhf-libvirt 14

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

On Jan 12, 2018, at 05:19, Jan Beulich wrote: > > This is a very simplistic change limiting the amount of memory a running > 64-bit PV guest has mapped (and hence available for attacking): Only the > mappings of stack, IDT, and TSS are being cloned from the direct map > into

[Xen-devel] [PATCH v2] docs: note default for timer_mode in xl.cfg man

There was no default documented but the header at xen/include/public/hvm/params.h stated which the default was, so add it to the docs. Signed-off-by: Doug Goldstein --- CC: Wei Liu CC: Ian Jackson CC: Roger Pau Monné

[Xen-devel] [xen-unstable test] 118003: tolerable FAIL - PUSHED

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

Re: [Xen-devel] Clarification regarding Meltdown and 64-bit PV guests

On Sun, 14 Jan 2018, Hans van Kranenburg wrote: > On 14/01/2018 15:00, Dongli Zhang wrote: > > Hi Hans, > > > > On 01/13/2018 07:12 PM, Hans van Kranenburg wrote: > >> On 01/13/2018 11:08 AM, Andy Smith wrote: > >>> Hi Hans, > >>> > >>> On Sat, Jan 13, 2018 at 10:43:03AM +0100, Hans van

Re: [Xen-devel] [PATCH] remove dead code in allocate_memory

Hi Stefano, On 01/13/2018 12:29 AM, Stefano Stabellini wrote: lowmem is unchanged until after this loop, there is no point in testing for its value. Moreover, Coverity complains about dead code. Remove the lowmem test in the first loop. While I understand Coverity complains about dead code,

Re: [Xen-devel] [PATCH v2] docs: note default for timer_mode in xl.cfg man

On 1/15/18 9:59 AM, Roger Pau Monné wrote: > On Mon, Jan 15, 2018 at 08:45:51AM -0600, Doug Goldstein wrote: >> There was no default documented but the header at >> xen/include/public/hvm/params.h stated which the default was, so add it >> to the docs. > > While looking at libxl code I've found

Re: [Xen-devel] [PATCH] don't pass r12/x16 as reference

On Sat, 13 Jan 2018, Julien Grall wrote: > Hi Stefano, > > On 01/13/2018 12:07 AM, Stefano Stabellini wrote: > > r12 and x16 are of different sizes; when passing r12 as a reference to > > do_trap_hypercall on arm64, we end up dereferencing it as a pointer to a > > 64bit value, but actually it

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

On 15/01/18 11:06, Jan Beulich wrote: > This is a very simplistic change limiting the amount of memory a running > 64-bit PV guest has mapped (and hence available for attacking): Only the > mappings of stack, IDT, and TSS are being cloned from the direct map > into per-CPU page tables. Guest

[Xen-devel] [PATCH v2] -xen-attach is needed for pvh boot with qemu-xen

Currently the boot of a pvh guest using the qemu-xen device model fails with the error xen emulation not implemented (yet) in the qemu-dm log file. This patch adds the missing -xen-attach argument. V2: Use b_info->type != LIBXL_DOMAIN_TYPE_HVMinstead of (b_info->type ==

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

On Mon, 2018-01-15 at 14:23 +0100, David Woodhouse wrote: > > > >  > > > Also... if you're doing that in context_switch() does it do the right > > > thing with idle? If a CPU switches to the idle domain and then back > > > again to the same vCPU, does that do the IBPB twice? > > > > Context

[Xen-devel] Unexpected behavior: Xen creating domains on startup

Hello all, I am doing some testing with Xen. After some of the guest domains I am testing crashed, I decided to add some logging to Xen and the tools. After rebuilding, reinstalling and rebooting the system, Xen seems to create guest domains (the ones created before reboot) on startup (with no

[Xen-devel] Xen on RCarH3 Starter Kit

Hi, Does Xen support RCarH3 Starter Kit - https://elinux.org/R-Car/Boards/H3SK I followed the build procedures explained in this link for Salvator X - https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X But the Yocto build instructions given in the link is for

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

flight 118036 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118036/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 17 guest-start.2fail in 117980 pass in 118036 test-armhf-armhf-xl-rtds

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

>>> On 15.01.18 at 19:23, wrote: > On 15/01/18 11:06, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_64/compat/entry.S >> +++ b/xen/arch/x86/x86_64/compat/entry.S >> @@ -199,6 +199,17 @@ ENTRY(cstar_enter) >> pushq $0 >> movl $TRAP_syscall, 4(%rsp) >>

Re: [Xen-devel] [PATCH V5] pci: removed the is_express field since a uniform interface was inserted

On Mon, Dec 18, 2017 at 05:21:40PM +0200, Yoni Bettan wrote: > according to Eduardo Habkost's commit fd3b02c889 all PCIEs now implement > INTERFACE_PCIE_DEVICE so we don't need is_express field anymore. > > Devices that implements only INTERFACE_PCIE_DEVICE (is_express == 1) > or > devices that

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

flight 118034 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/118034/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 117930 Tests

[Xen-devel] [libvirt bisection] complete build-armhf-libvirt

branch xen-unstable xenbranch xen-unstable job build-armhf-libvirt testid libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: qemuu

[Xen-devel] [linux-next test] 118031: regressions - FAIL

flight 118031 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/118031/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 117945

[Xen-devel] [PATCH RESEND v1 2/7] x86: configure vmcs for Intel processor trace virtualization

This patch configure VMCS to make Intel PT output address can be treat as guest physical address and translated by EPT when intel_pt option is true. There have some constraint condition on VMCS configuration, otherwise will cause VM entry failed. 1. If the “Guest PT uses Guest Physical Addresses”

[Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write

Intel PT MSRs read/write will not be intercepted when guest enabled Intel PT. IA32_RTIT_CTL read/write will always cause a VM-Exit. Signed-off-by: Luwei Kang --- xen/arch/x86/cpu/intel_pt.c| 101 + xen/arch/x86/hvm/vmx/vmx.c

[Xen-devel] [PATCH RESEND v1 3/7] x86: add intel proecessor trace support for cpuid

This patch add Intel processor trace support for cpuid handling. Signed-off-by: Luwei Kang --- tools/libxc/xc_cpuid_x86.c | 12 ++-- xen/arch/x86/cpuid.c| 22 ++ xen/arch/x86/domctl.c

[Xen-devel] [PATCH RESEND v1 5/7] x86: Implement Intel Processor Trace context switch

Load/Store Intel processor trace register in context switch. MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS. When Intel PT is supported in guest, we need load/restore PT MSRs only when PT is enabled in guest. Signed-off-by: Luwei Kang ---

[Xen-devel] [PATCH RESEND v1 7/7] x86: Disable Intel Processor Trace when VMXON in L1 guest

Disable intel Processor Trace VMX operation(IA32_VMX_MISC[bit 14] is 0) in L1 guest. As mentioned in SDM, on these type of processors, execution of the VMXON instruction will clears IA32_RTIT_CTL.TraceEn and any attempt to write IA32_RTIT_CTL causes a general-protection xception (#GP).

Re: [Xen-devel] [PATCH] fix potential null dereference

>>> On 15.01.18 at 19:51, wrote: > On Mon, 15 Jan 2018, Jan Beulich wrote: >> >>> On 13.01.18 at 07:21, wrote: >> > On 01/12/2018 11:40 PM, Stefano Stabellini wrote: >> >> handles can theoretically be NULL, check for it explicitly before >> >>

[Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

Hi All, Here is a patch-series which adding Processor Trace enabling in XEN guest. You can get It's software developer manuals from: https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf In Chapter 5 INTEL PROCESSOR TRACE:

[Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

This patch add a flag to enable Intel PT (Intel processor trace). Default value is 1 (enabled). Signed-off-by: Luwei Kang --- docs/misc/xen-command-line.markdown | 7 +++ xen/arch/x86/cpu/Makefile | 1 + xen/arch/x86/cpu/intel_pt.c | 27

Re: [Xen-devel] [PATCH v8 10/17] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, January 15, 2018 7:11 PM > > >>> On 12.01.18 at 19:01, wrote: > > For performance reasons, HVM guests should have direct access to these > MSRs > > when possible. > > > > Signed-off-by: Andrew Cooper

[Xen-devel] [seabios test] 118041: regressions - FAIL

flight 118041 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118041/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

[Xen-devel] [qemu-upstream-4.10-testing test] 118021: tolerable FAIL - PUSHED

flight 118021 qemu-upstream-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118021/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass

[Xen-devel] [PATCH v3 1/2] public/hvm/params.h: fix comment for timer_mode default

In libxl__domain_build_info_setdefault() in tools/libxl/libxl_create.c the default for timer_mode for HVM and PVH is LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS so adjust the comments in the header to reflect this. --- CC: Wei Liu CC: Ian Jackson

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

On Mon, 2018-01-15 at 13:02 +, Andrew Cooper wrote: > On 15/01/18 12:54, David Woodhouse wrote: > > > > On Fri, 2018-01-12 at 18:01 +, Andrew Cooper wrote: > > > > > > @@ -1736,6 +1736,9 @@ void context_switch(struct vcpu *prev, struct > > > vcpu *next) > > > } > > >   > > >

Re: [Xen-devel] [PATCH v3 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

> -Original Message- > From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com] > Sent: 12 January 2018 12:45 > To: xen-de...@lists.xen.org > Cc: Ross Lagerwall ; Paul Durrant > ; Daniel De Graaf ; Ian > Jackson

Re: [Xen-devel] [PATCH] docs: note default for timer_mode in xl.cfg man

On Sun, Jan 14, 2018 at 11:28:15PM -0600, Doug Goldstein wrote: > There was no default documented but the header at > xen/include/public/hvm/params.h stated which the default was, so add it > to the docs. > > Signed-off-by: Doug Goldstein > --- > CC: Wei Liu

Re: [Xen-devel] [PATCH] -xen-attach is needed for pvh boot with qemu-xen

On Sun, Jan 14, 2018 at 09:12:51PM +, Michael Young wrote: > Currently the boot of a pvh guest using the qemu-xen device model fails > with the error > xen emulation not implemented (yet) > in the qemu-dm log file. This patch adds the missing -xen-attach > argument. > > Signed-off-by: Michael

Re: [Xen-devel] [PATCH v8 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

>>> On 12.01.18 at 19:01, wrote: > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -668,6 +668,7 @@ void __init noreturn __start_xen(unsigned long mbi_p) > set_processor_id(0); > set_current(INVALID_VCPU); /* debug sanity. */ > idle_vcpu[0] =

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

On Fri, 2018-01-12 at 18:01 +, Andrew Cooper wrote: > > @@ -1736,6 +1736,9 @@ void context_switch(struct vcpu *prev, struct > vcpu *next) > } >   > ctxt_switch_levelling(next); > + > +    if ( opt_ibpb ) > +    wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB); > } > If

Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

On 15/01/18 12:54, David Woodhouse wrote: > On Fri, 2018-01-12 at 18:01 +, Andrew Cooper wrote: >> @@ -1736,6 +1736,9 @@ void context_switch(struct vcpu *prev, struct >> vcpu *next) >> } >>   >> ctxt_switch_levelling(next); >> + >> +    if ( opt_ibpb ) >> +   

[Xen-devel] [distros-debian-sid test] 74460: trouble: blocked/broken

flight 74460 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74460/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386

Re: [Xen-devel] [PATCH] fix potential null dereference

>>> On 13.01.18 at 07:21, wrote: > On 01/12/2018 11:40 PM, Stefano Stabellini wrote: >> handles can theoretically be NULL, check for it explicitly before >> dereferencing it. > > I doubt handles could be NULL if LocateHandle succeed. This seems to be > confirmed by the

Re: [Xen-devel] [PATCH] don't pass r12/x16 as reference

Hi Stefano, On 01/13/2018 12:07 AM, Stefano Stabellini wrote: r12 and x16 are of different sizes; when passing r12 as a reference to do_trap_hypercall on arm64, we end up dereferencing it as a pointer to a 64bit value, but actually it isn't. Instead, pass r12/x16 as values and explicitly

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

>>> On 13.01.18 at 18:48, wrote: > On 12/01/18 10:19, Jan Beulich wrote: >> This is a very simplistic change limiting the amount of memory a running >> 64-bit PV guest has mapped (and hence available for attacking): Only the >> mappings of stack, IDT, and TSS are being

Re: [Xen-devel] [PATCH v8 01/17] x86: Support compiling with indirect branch thunks

>>> On 15.01.18 at 11:40, wrote: > On 15/01/18 10:14, Jan Beulich wrote: > On 12.01.18 at 19:00, wrote: >>> --- a/xen/arch/x86/Rules.mk >>> +++ b/xen/arch/x86/Rules.mk >>> @@ -30,3 +30,10 @@ CFLAGS += -fno-asynchronous-unwind-tables >>>

Re: [Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

>>> On 12.01.18 at 19:00, wrote: > Introduce INDIRECT_CALL and INDIRECT_JMP which either degrade to a normal > indirect branch, or dispatch to the __x86_indirect_thunk_* symbols. > > Update all the manual indirect branches in to use the new thunks. The > indirect

Re: [Xen-devel] [xen-unstable test] 117920: regressions - FAIL

On Sat, Jan 13, 2018 at 07:52:08PM +, osstest service owner wrote: > flight 117920 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/117920/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] [PATCH v8 05/17] x86: Introduce alternative indirect thunks

>>> On 12.01.18 at 19:00, wrote: > Depending on hardware and microcode availability, we will want to replace > IND_THUNK_REPOLINE with other implementations. > > For AMD hardware, choose IND_THUNK_LFENCE in preference to retpoline if lfence > is known to be (or was

Re: [Xen-devel] [PATCH v8 01/17] x86: Support compiling with indirect branch thunks

On 15/01/18 10:14, Jan Beulich wrote: On 12.01.18 at 19:00, wrote: >> --- a/xen/arch/x86/Rules.mk >> +++ b/xen/arch/x86/Rules.mk >> @@ -30,3 +30,10 @@ CFLAGS += -fno-asynchronous-unwind-tables >> ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n) >> CFLAGS

Re: [Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads

>>> On 12.01.18 at 19:01, wrote: > --- a/xen/include/asm-x86/spec_ctrl.h > +++ b/xen/include/asm-x86/spec_ctrl.h > @@ -20,8 +20,29 @@ > #ifndef __X86_SPEC_CTRL_H__ > #define __X86_SPEC_CTRL_H__ > > +#include > + > void init_speculation_mitigations(void); > > +/*