>>> 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 cloned from the direct map
>
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
>>> 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 spec (Page 208 in UEFI spe
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 overwr
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
> CC: Ian Jackson
> # George for the
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
>>> 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 += -DGCC_HAS_VISIBILITY_ATTRIBUTE
> endif
> +
> +# Compile with thunk-ex
flight 117980 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117980/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 117697
Tests which are
flight 118001 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118001/
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 suc
>>> 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 branches in the early boot and k
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:
> build-amd64
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 += -DGCC_HAS_VISIBILITY_ATTRI
>>> 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
>>> ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
>>> 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 successfully made) dispatch ser
1: x86: Meltdown band-aid against malicious 64-bit PV guests
2: x86: allow Meltdown band-aid to be disabled
Signed-off-by: Jan Beulich
---
v2: Addressing review comments for patch 1 (see there) and new
patch 2.
___
Xen-devel mailing list
Xen-deve
First of all we don't need it on AMD systems. Additionally allow its use
to be controlled by command line option. For best backportability, this
intentionally doesn't use alternative instruction patching to achieve
the intended effect - while we likely want it, this will be later
follow-up.
Signed
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 controlled parts of the page tables are
being copied
>>> 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
with one spelling fix (see below)
As these are non-trivial changes to VMX and SVM code I think you
should h
Roger Pau Monné writes ("Re: [Xen-devel] [xen-unstable test] 117920:
regressions - FAIL"):
> This failure is quite weird:
This is probably my fault due to my broken ad-hoc flight on Friday.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.or
>>> 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);
>
> +/*
> + * For guests which know
>>> 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] = current;
> +init_shadow
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
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 )
>> + wrms
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)
> > > }
> > >
> > >
> -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
> ; Jan Beulich ; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ;
> -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 ; Wei Liu ; Andrew
> Cooper ; George Dunlap
> ; Jan Beulich ; Konrad
> Rzeszutek
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 saver
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é
# George for the 4.8 and 4.9 backport
CC: George Dunlap
change from v1:
- a
Added Juergen and Ian:
On 12/01/2018, 20:36, "Marek Marczykowski-Górecki"
wrote:
On Fri, Jan 12, 2018 at 06:20:05PM +, Julien Grall wrote:
>> Hi Lars,
>>
>> As I understand from Xen 4.10 [1] , we are going to use SUPPORT.MD or the
>> list of features existing.
Correc
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
On Fri, Dec 15, 2017 at 09:33:24AM +, Daniel P. Berrange wrote:
> On Wed, Dec 13, 2017 at 03:01:51PM +, Anthony PERARD wrote:
> > On Tue, Dec 12, 2017 at 02:10:44PM +, Daniel P. Berrange wrote:
> > > Replace the scancode2linux table with an automatically
> > > generated table. In doing
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 libxl__domain_build_
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
with one spelling fix (see below)
As these are non-trivial changes to
flight 118056 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118056/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
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 per-CPU page tables.
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 Kranenburg
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 isn'
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 contro
On 15/01/18 11:07, Jan Beulich wrote:
> First of all we don't need it on AMD systems. Additionally allow its use
> to be controlled by command line option. For best backportability, this
> intentionally doesn't use alternative instruction patching to achieve
> the intended effect - while we likely
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
> >> dereferencing it.
> >
> > I doubt handles could be NULL if LocateHandle succeed. This seems
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 save
Hi Stefano,
On 15 Jan 2018 19:51, "Stefano Stabellini" 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
> >> dereferencing it.
> >
> > I
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, i
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 th
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 == LIBXL_DOMAIN_
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 switch
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
test-amd64-amd64-libvi
> 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
>
> Reviewed-by: Jan Beulich
>
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 suc
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
CC: Roger Pau Monné
CC: George Dunlap
CC: Andrew
There was no default documented but inspecting
libxl__domain_build_info_setdefault() shows the default to be
LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS.
Signed-off-by: Doug Goldstein
---
CC: Wei Liu
CC: Ian Jackson
CC: Roger Pau Monné
# George for the 4.8 and 4.9 backport
CC: George Dunlap
c
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 im
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 whic
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 'xl
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 git://xenbits.xen.org/qemu-
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
test-amd64-amd64-xl-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, January 5, 2018 4:21 AM
>
> DMA-ing to the stack is generally considered bad practice. In this case, if a
> timeout occurs because of a sluggish device which is processing the request,
> the completion notification will corr
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 Rc
>>> 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
>> >> dereferencing it.
>> >
>> > I doubt handles could be
>>> On 15.01.18 at 17:54, wrote:
> 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
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
>>> 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)
>> SAVE_ALL
>> +
>> +
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: V
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 +++
xen/in
All other discussions related to the dma mapping interfaces are on the
iommu list, so let's make it the official list for swiotlb and the
second list for xen-swiotlb.
Signed-off-by: Christoph Hellwig
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINER
This patch add Intel processor trace context
date structure for guest.
Signed-off-by: Luwei Kang
---
xen/include/asm-x86/hvm/vmx/vmcs.h | 3 +++
xen/include/asm-x86/intel_pt.h | 17 +
xen/include/asm-x86/msr-index.h| 20
3 files changed, 40 insertion
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 | 18
xen/inc
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 | 4
xen/includ
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”
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/arch/x86/cpu/intel_pt.c| 69 +
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).
Signed-off
71 matches
Mail list logo
