Re: [Xen-devel] [PATCH 5/5] x86/monitor: Capture Xen's intent to use monitor at boot time

>>> On 12.01.18 at 19:37, wrote: > @@ -312,6 +313,12 @@ static void generic_identify(struct cpuinfo_x86 *c) > if ( cpu_has(c, X86_FEATURE_CLFLUSH) ) > c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8; > > + /* Xen only uses MONITOR if INTERRUPT_BREAK is available. */ > +

Re: [Xen-devel] [PATCH v2] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

>>> On 17.01.18 at 13:56, wrote: > When using a linker that supports both formats the following error > will be triggered: > > efi/buildid.o: file not recognized: File format is ambiguous > efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 > > Solve this by specifying the efi/buildid.o form

Re: [Xen-devel] [PATCH 1/6] xen/pvshim: map vcpu_info earlier for APs

>>> On 17.01.18 at 11:50, wrote: > On Wed, Jan 17, 2018 at 09:48:09AM +, Roger Pau Monne wrote: >> Or else init_percpu_time is going to dereference a NULL pointer when >> trying to access vcpu_info. >> >> Signed-off-by: Roger Pau Monné > > Reviewed-by: Wei Liu Acked-by: Jan Beulich ___

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

>>> On 17.01.18 at 13:53, wrote: > --- a/xen/arch/x86/hvm/vlapic.c > +++ b/xen/arch/x86/hvm/vlapic.c > @@ -422,6 +422,13 @@ void vlapic_EOI_set(struct vlapic *vlapic) > if ( vector == -1 ) > return; > > +/* > + * It is possible that APIC assist has been enabled by the guest

Re: [Xen-devel] [PATCH v2 2/6] xen/pvh: place the trampoline at page 0x1

>>> On 17.01.18 at 13:00, wrote: > Since PVH guest jump straight into trampoline_setup trampoline_phys is > not initialized, thus the trampoline is relocated to address 0. > > This works, but has the undesirable effect of having VA 0 mapped to > MFN 0, which means NULL pointed dereferences no lon

Re: [Xen-devel] [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs

>>> On 17.01.18 at 17:29, wrote: > Since VCPUOP_{up/down} already identity maps vCPU hotplug to pCPU > hotplug also identity pin the vCPUs to the pCPUs in the scheduler. > This prevents vCPU migration and should improve performance. > > While there also use __cpumask_set_cpu instead of cpumask_se

Re: [Xen-devel] [PATCH 4/6] xen/pvshim: simplify replace_va_mapping code

>>> On 17.01.18 at 10:48, wrote: > No functional change. > > Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich I'm not sure I'd call it a simplification, though - you only re-order code. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject

Re: [Xen-devel] [PATCH 5/6] xen/pvshim: fix coding style issues

>>> On 17.01.18 at 10:48, wrote: > --- a/xen/arch/x86/pv/shim.c > +++ b/xen/arch/x86/pv/shim.c > @@ -264,14 +264,14 @@ int pv_shim_shutdown(uint8_t reason) > &old_console_pfn)); > > /* Pause the other vcpus before starting the migration. */ > -

Re: [Xen-devel] [PATCH 4/6] xen/pvshim: simplify replace_va_mapping code

On 17/01/2018 09:48, Roger Pau Monne wrote: > No functional change. > > Signed-off-by: Roger Pau Monné > --- > Cc: Jan Beulich > Cc: Andrew Cooper > --- > xen/arch/x86/pv/shim.c | 21 ++--- > 1 file changed, 6 insertions(+), 15 deletions(-) > > diff --git a/xen/arch/x86/pv/shim.

[Xen-devel] [xen-unstable-smoke test] 118203: regressions - FAIL

flight 118203 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118203/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 118105 Tests which

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 January 2018 08:33 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs > APIC > > >>> On 17.01.18 at 13:53,

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

On Wed, 2018-01-17 at 18:26 +0100, David Woodhouse wrote: > > > In both switching to idle, and back to the vCPU, we should hit this > > case and not the 'else' case that does the IBPB: > >  > > 1710 if ( (per_cpu(curr_vcpu, cpu) == next) || > > 1711  (is_idle_domain(nextd) && cpu_onlin

[Xen-devel] Repeated problems with network receive path in Linux

Hi, We have experienced 3 full crashes over the last 3 months in the Linux network receive path, and one additional crash of a vif queue that killed networking for a single guest but did not bring down the entire host. I am not 100% sure if it is Xen related or not, but it seems possible. Becau

Re: [Xen-devel] [PATCH v3 2/6] x86/hvm: Provide XEN_DMOP_add_to_physmap

>>> On 12.01.18 at 13:45, wrote: > --- a/xen/arch/x86/hvm/dm.c > +++ b/xen/arch/x86/hvm/dm.c > @@ -640,6 +640,42 @@ static int dm_op(const struct dmop_args *op_args) > break; > } > > +case XEN_DMOP_add_to_physmap: > +{ > +struct xen_dm_op_add_to_physmap *data = > +

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

>>> On 12.01.18 at 13:45, wrote: > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -597,10 +597,6 @@ struct xen_domctl_ioport_mapping { > #define XEN_DOMCTL_MEM_CACHEATTR_WB 6 > #define XEN_DOMCTL_MEM_CACHEATTR_UCM 7 > #define XEN_DOMCTL_DELETE_MEM_CACHEATTR (~(uint3

Re: [Xen-devel] [PATCH v3 2/6] x86/hvm: Provide XEN_DMOP_add_to_physmap

On 01/18/2018 09:24 AM, Jan Beulich wrote: On 12.01.18 at 13:45, wrote: --- a/xen/arch/x86/hvm/dm.c +++ b/xen/arch/x86/hvm/dm.c @@ -640,6 +640,42 @@ static int dm_op(const struct dmop_args *op_args) break; } +case XEN_DMOP_add_to_physmap: +{ +struct xen_dm_op

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

>>> On 18.01.18 at 10:06, wrote: >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 18 January 2018 08:33 >> To: Paul Durrant >> Cc: Andrew Cooper ; xen- >> de...@lists.xenproject.org >> Subject: Re: [PATCH] x86/hvm: more sure APIC assist is aborted if guest

Re: [Xen-devel] [PATCH v3 2/6] x86/hvm: Provide XEN_DMOP_add_to_physmap

>>> On 18.01.18 at 10:32, wrote: > On 01/18/2018 09:24 AM, Jan Beulich wrote: > On 12.01.18 at 13:45, wrote: >>> --- a/xen/include/public/hvm/dm_op.h >>> +++ b/xen/include/public/hvm/dm_op.h >>> @@ -368,6 +368,24 @@ struct xen_dm_op_remote_shutdown { >>> /* (Other

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 January 2018 09:39 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: RE: [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs > APIC > > >>> On 18.01.18 at 10:06,

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

On Wed, Jan 17, 2018 at 05:58:43PM +, Andrew Cooper wrote: > On 17/01/18 17:32, Roger Pau Monné wrote: > > On Wed, Jan 17, 2018 at 04:24:27PM +, Ian Jackson wrote: > >> Roger Pau Monne writes ("[PATCH 6/6] firmware/shim: fix build process to > >> use POSIX find options"): > >>> The -printf

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

>>> On 18.01.18 at 10:55, wrote: > Ok. I'll re-work it so that abort is passed a vector and warns on mismatch. You mean on the new path only, I suppose? The old path should not trigger warnings (aiui it would always do so). Jan ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

Wei, On 01/12/17 15:14, Juergen Gross wrote: > Instead of locating the RSDP table below 1MB put it just below 4GB > like the rest of the ACPI tables in case of PVH guests. This will > avoid punching more holes than necessary into the memory map. > > Signed-off-by: Juergen Gross > Acked-by: Wei L

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote: > Wei, > > On 01/12/17 15:14, Juergen Gross wrote: > > Instead of locating the RSDP table below 1MB put it just below 4GB > > like the rest of the ACPI tables in case of PVH guests. This will > > avoid punching more holes than necessar

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 January 2018 10:17 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: RE: [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs > APIC > > >>> On 18.01.18 at 10:55,

Re: [Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

On Thu, Jan 18, 2018 at 7:59 AM, Jan Beulich wrote: On 12.01.18 at 19:37, wrote: >> Windows is the only OS which pages out kernel datastructures, so chances are >> good that this is a vestigial remnant of the PV Windows XP experiment. > > This is based on what? How do you know there are no o

Re: [Xen-devel] [PATCH] ocaml: fix arm build

On Wed, Jan 17, 2018 at 04:43:54PM +, Wei Liu wrote: > ARM doesn't have emulation_flags in the arch_domainconfig. > > Signed-off-by: Wei Liu > --- > Cc: Ian Jackson > Cc: Julien Grall > Cc: Andrew Cooper > --- > tools/ocaml/libs/xc/xenctrl_stubs.c | 6 ++ > 1 file changed, 6 insertion

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

On 17/01/18 14:31, Lars Kurth wrote: Hi Julien, Hi Lars, On 17 Jan 2018, at 12:31, Julien Grall > wrote: If you took the code from Linux, you need to add the original Signed-off-by from the Linux commit. Aside from that: There are multiple commits touchin

Re: [Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

>>> On 18.01.18 at 11:38, wrote: > On Thu, Jan 18, 2018 at 7:59 AM, Jan Beulich wrote: > On 12.01.18 at 19:37, wrote: >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -1942,11 +1942,8 @@ int domain_relinquish_resources(struct domain *d) >>> { >>> f

Re: [Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

On 18/01/18 10:38, George Dunlap wrote: > On Thu, Jan 18, 2018 at 7:59 AM, Jan Beulich wrote: > On 12.01.18 at 19:37, wrote: >>> Windows is the only OS which pages out kernel datastructures, so chances are >>> good that this is a vestigial remnant of the PV Windows XP experiment. >> This is b

Re: [Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

On 18/01/18 10:57, Andrew Cooper wrote: > On 18/01/18 10:38, George Dunlap wrote: >> On Thu, Jan 18, 2018 at 7:59 AM, Jan Beulich wrote: >> On 12.01.18 at 19:37, wrote: Windows is the only OS which pages out kernel datastructures, so chances are good that this is a vestigial r

[Xen-devel] [PATCH v3 2/7] xen/pvh: place the trampoline starting at MFN 1

Since PVH guest jump straight into trampoline_setup trampoline_phys is not initialized, thus the trampoline is relocated to address 0. This works, but has the undesirable effect of having VA 0 mapped to MFN 0, which means NULL pointed dereferences no longer trigger a page fault. In order to solve

[Xen-devel] [PATCH v3 1/7] xen/pvshim: map vcpu_info earlier for APs

Or else init_percpu_time is going to dereference a NULL pointer when trying to access vcpu_info. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson Cc: Wei Liu --- Should be backported to the 4.10.0-shim-comet bran

[Xen-devel] [PATCH v3 6/7] firmware/shim: fix build process to use POSIX find options

The -printf find option is not POSIX compatible, so replace it with another rune. Signed-off-by: Roger Pau Monné --- Cc: Ian Jackson Cc: Wei Liu --- Changes since v1: - Drop the exec rune and instead process the whole output at once. --- tools/firmware/xen-dir/Makefile | 3 ++- 1 file changed

[Xen-devel] [PATCH v3 0/7] xen/pvshim: fixes for staging

Hello, The following series contain some code and style fixes for the pvshim (comet) code that has been merged into staging. IMHO patches 1-3 should be backported to the stable comet branch. A branch with the series is also available at: git://xenbits.xen.org/people/royger/xen.git pvshim_fixes_v

[Xen-devel] [PATCH v3 7/7] xen/pvshim: switch shim.c to use typesafe mfn_to_page and virt_to_mfn

No functional change intended. Signed-off-by: Roger Pau Monné Requested-by: Andrew Cooper --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu --- xen/arch/x86/pv/shim.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/pv/shim.c b/xen

[Xen-devel] [PATCH v3 3/7] xen/pvshim: identity pin shim vCPUs to pCPUs

Since VCPUOP_{up/down} already identity maps vCPU hotplug to pCPU hotplug also identity pin the vCPUs to the pCPUs in the scheduler. This prevents vCPU migration and should improve performance. While there also use __cpumask_set_cpu instead of cpumask_set_cpu, there's no need to use the locked var

[Xen-devel] [PATCH v3 5/7] xen/pvshim: fix coding style issues

Fix a couple of coding style issues. No code or functional change. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/pv/shim.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git

Re: [Xen-devel] [PATCH v3 7/7] xen/pvshim: switch shim.c to use typesafe mfn_to_page and virt_to_mfn

On 18/01/18 11:02, Roger Pau Monne wrote: > No functional change intended. > > Signed-off-by: Roger Pau Monné > Requested-by: Andrew Cooper > --- > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Wei Liu Acked-by: Andrew Cooper Thanks. ___ Xen-devel ma

[Xen-devel] [PATCH v3 4/7] xen/pvshim: re-order replace_va_mapping code

No functional change. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v1: - Fix double ; and space. --- xen/arch/x86/pv/shim.c | 21 ++--- 1 file changed, 6 insertions(+), 15 deletions(-) diff

Re: [Xen-devel] [PATCH] ocaml: fix arm build

On Thu, Jan 18, 2018 at 10:44:58AM +, Wei Liu wrote: > On Wed, Jan 17, 2018 at 04:43:54PM +, Wei Liu wrote: > > ARM doesn't have emulation_flags in the arch_domainconfig. > > > > Signed-off-by: Wei Liu > > --- > > Cc: Ian Jackson > > Cc: Julien Grall > > Cc: Andrew Cooper > > --- > >

Re: [Xen-devel] [PATCH v10 00/11] Enable Memory Bandwidth Allocation in Xen

On Tue, Jan 09, 2018 at 08:31:52AM +0800, Yi Sun wrote: > On 18-01-08 12:25:02, Wei Liu wrote: > > On Mon, Jan 08, 2018 at 12:28:58PM +0800, Yi Sun wrote: > > > On 17-12-20 02:11:32, Jan Beulich wrote: > > > > >>> On 19.12.17 at 01:42, wrote: > > > > > We plan to bring a new PSR (Platform Shared R

Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build process to use POSIX find options"): > What about using: > > find $(XEN_ROOT)/$(d)/ -type d | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir > -p > > This AFAICT works fine, and should be the one involving less forks > s

Re: [Xen-devel] [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs

Jan Beulich writes ("Re: [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs"): > On 17.01.18 at 17:29, wrote: > > Since VCPUOP_{up/down} already identity maps vCPU hotplug to pCPU > > hotplug also identity pin the vCPUs to the pCPUs in the scheduler. > > This prevents vCPU migration and

Re: [Xen-devel] [PATCH v3 7/7] xen/pvshim: switch shim.c to use typesafe mfn_to_page and virt_to_mfn

On Thu, Jan 18, 2018 at 11:02:52AM +, Roger Pau Monne wrote: > No functional change intended. > > Signed-off-by: Roger Pau Monné > Requested-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https:/

Re: [Xen-devel] [PATCH v3 6/7] firmware/shim: fix build process to use POSIX find options

Roger Pau Monne writes ("[PATCH v3 6/7] firmware/shim: fix build process to use POSIX find options"): > The -printf find option is not POSIX compatible, so replace it with > another rune. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@list

Re: [Xen-devel] [PATCH v3 6/7] firmware/shim: fix build process to use POSIX find options

On Thu, Jan 18, 2018 at 11:02:51AM +, Roger Pau Monne wrote: > The -printf find option is not POSIX compatible, so replace it with > another rune. > > Signed-off-by: Roger Pau Monné Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xe

Re: [Xen-devel] [PATCH 5/5] xen/arm64: Implement branch predictor hardening for affected Cortex-A CPUs

Hi, On 17/01/18 17:11, Stefano Stabellini wrote: On Wed, 17 Jan 2018, Julien Grall wrote: Hi Stefano, On 17/01/18 00:42, Stefano Stabellini wrote: On Tue, 16 Jan 2018, Julien Grall wrote: #define MIDR_RANGE(model, min, max) \ @@ -205,6 +232,28 @@ static const struct arm_cpu_capabiliti

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Paul Durrant > Sent: 18 January 2018 10:37 > To: 'Jan Beulich' > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is

Re: [Xen-devel] [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs

>>> On 18.01.18 at 12:11, wrote: > Jan Beulich writes ("Re: [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs > to pCPUs"): >> On 17.01.18 at 17:29, wrote: >> > Since VCPUOP_{up/down} already identity maps vCPU hotplug to pCPU >> > hotplug also identity pin the vCPUs to the pCPUs in the schedul

Re: [Xen-devel] [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs to pCPUs

On Thu, Jan 18, 2018 at 04:22:11AM -0700, Jan Beulich wrote: > >>> On 18.01.18 at 12:11, wrote: > > Jan Beulich writes ("Re: [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs > > to pCPUs"): > >> On 17.01.18 at 17:29, wrote: > >> > Since VCPUOP_{up/down} already identity maps vCPU hotplug to pC

Re: [Xen-devel] [PATCH v10 00/11] Enable Memory Bandwidth Allocation in Xen

On Thu, Jan 18, 2018 at 11:10:50AM +, Wei Liu wrote: > On Tue, Jan 09, 2018 at 08:31:52AM +0800, Yi Sun wrote: > > On 18-01-08 12:25:02, Wei Liu wrote: > > > On Mon, Jan 08, 2018 at 12:28:58PM +0800, Yi Sun wrote: > > > > On 17-12-20 02:11:32, Jan Beulich wrote: > > > > > >>> On 19.12.17 at 01:

Re: [Xen-devel] [PATCH 4/5] x86/pv: Drop support for paging out the LDT

>>> On 18.01.18 at 12:00, wrote: > On 18/01/18 10:57, Andrew Cooper wrote: >> On 18/01/18 10:38, George Dunlap wrote: >>> On Thu, Jan 18, 2018 at 7:59 AM, Jan Beulich wrote: >>> On 12.01.18 at 19:37, wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1942,11

Re: [Xen-devel] [PATCH v10 00/11] Enable Memory Bandwidth Allocation in Xen

On Thu, Jan 18, 2018 at 11:31:51AM +, Wei Liu wrote: > On Thu, Jan 18, 2018 at 11:10:50AM +, Wei Liu wrote: > > On Tue, Jan 09, 2018 at 08:31:52AM +0800, Yi Sun wrote: > > > On 18-01-08 12:25:02, Wei Liu wrote: > > > > On Mon, Jan 08, 2018 at 12:28:58PM +0800, Yi Sun wrote: > > > > > On 17-

[Xen-devel] [xen-unstable-smoke test] 118206: regressions - FAIL

flight 118206 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118206/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 118105 Tests which

Re: [Xen-devel] [PATCH 4/5] xen/arm64: Add skeleton to harden the branch predictor aliasing attacks

Hi Stefano, On 17/01/18 18:26, Stefano Stabellini wrote: On Tue, 16 Jan 2018, Julien Grall wrote: diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h index 7de68361ff..23ebf367ea 100644 --- a/xen/include/asm-arm/cpuerrata.h +++ b/xen/include/asm-arm/cpuerrata.h @@ -1,

Re: [Xen-devel] [PATCH v4] kexec-tools: Perform run-time linking of libxenctrl.so

On Wed, Jan 17, 2018 at 10:39:01AM -0600, Eric DeVolder wrote: > When kexec is utilized in a Xen environment, it has an explicit > run-time dependency on libxenctrl.so. This dependency occurs > during the configure stage and when building kexec-tools. [...] As I saw Simon applied the patch. Great

Re: [Xen-devel] [PATCH v2 07/13] iommu: Make decision about needing IOMMU for hardware domains in advance

Sorry for the delay in the reply. On Tue, Jul 25, 2017 at 08:26:49PM +0300, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The hardware domains require IOMMU to be used in the most cases and > a decision to use it is made at hardware domain construction time. > But, it is not the b

[Xen-devel] XSA-254 SP2 for ARM (was Re: [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU)

(+ Security team) Hi Stefano, On 17/01/18 21:47, Stefano Stabellini wrote: On Wed, 17 Jan 2018, Stefano Stabellini wrote: On Wed, 17 Jan 2018, Lars Kurth wrote: Regarding README.source, this is covering file and contain the same mention as in the commit message. As this is a single fu

Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

>>> On 18.01.18 at 12:21, wrote: > Actually reading through the code and the spec. again, I'm not convinced by > the logic even with the EOI fix. It looks to me like vlapic_has_pending_irq() > could leave an existing assist in place and return a higher priority irr > value. This guest would the

[Xen-devel] AMD / SVM vm_event support

Hello, We're looking at potentially working with vm_event on SVM hosts. To that end, we've removed a few cpu_has_vmx tests and saw that some things just work. That is, unfortunately, not the case for EPT events. There's this old thread about NPT support: https://lists.gt.net/xen/devel/339571 b

Re: [Xen-devel] [PATCH] ocaml: fix arm build

This looks good to me. I don't think conditional compilation can be avoided here. -- Christian > On 17. Jan 2018, at 17:00, Wei Liu wrote: > > CC Ocaml experts > > On Wed, Jan 17, 2018 at 04:43:54PM +, Wei Liu wrote: >> ARM doesn't have emulation_flags in the arch_domainconfig. >> >> Sig

[Xen-devel] [xen-unstable-smoke test] 118210: tolerable all pass - PUSHED

flight 118210 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/118210/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 1

Re: [Xen-devel] [PATCH v4 2/4] x86emul: Support vpclmulqdq

>>> On 03.01.18 at 09:26, wrote: > The previous vpclmulqdq only support AVX128. > Icelake added AVX256 support. And 512-bit support as well; you only don't add support for the EVEX encoding forms in your patch. The patch itself looks fine, but please clarify its testing status. > @@ -6168,6 +61

Re: [Xen-devel] [PATCH v4 3/4] x86emul: Support vaes insns

>>> On 03.01.18 at 09:26, wrote: > The previous aes insns only support legacy and AVX128. > Icelake added AVX256 support. Same remark here as for the pclmulqdq patch. > Signed-off-by: Yang Zhong > --- Please provide a brief list of changes at this spot in each patch. > @@ -7336,17 +7337,23 @@

Re: [Xen-devel] [PATCH v2 07/13] iommu: Make decision about needing IOMMU for hardware domains in advance

Hi, Roger On Thu, Jan 18, 2018 at 2:09 PM, Roger Pau Monné wrote: > Sorry for the delay in the reply. No problem. > > On Tue, Jul 25, 2017 at 08:26:49PM +0300, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko >> >> The hardware domains require IOMMU to be used in the most cases and >>

[Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist code

It appears there is a case where Windows enables the APIC assist enlightenment[1] but does not use it. This scenario is perfectly valid according to the documentation, but causes the state machine in Xen to become confused leading to a domain_crash() such as the following: (XEN) d4: VIRIDIAN GUEST

[Xen-devel] [PATCH] x86: slightly reduce Meltdown band-aid overhead

I'm not sure why I didn't do this right away: By avoiding to make any of the cloned directmap PTEs global, there's no need to fiddle with CR4.PGE on any of the entry paths. Only the exit paths need to flush global mappings. The reduced flushing, however, implies that we now need to have interrupts

[Xen-devel] [PATCH v9 03/11] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

As per the spec currently available here: https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf MSR_ARCH_CAPABILITIES will only come into existence on new hardware, but is implemented as a straight #GP for now to avoid being leaky w

[Xen-devel] [PATCH v9 01/11] x86/thunk: Fix GEN_INDIRECT_THUNK comment

This is a rebasing error in c/s 858cba0d4c6b "x86: Introduce alternative indirect thunks" hidden by other changes in the same sentence. The name with dots rather than underscores was the prerelease GCC ABI. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v9: New. --- xen/arch/x86/indirect-th

[Xen-devel] [PATCH v9 00/11] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection

This series is availabe in git form from: http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/sp2-mitigations-v9 A copy of Intel's spec for IBRS/IBPB can be found here: https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-

[Xen-devel] [PATCH v9 07/11] x86/boot: Calculate the most appropriate BTI mitigation to use

Signed-off-by: Andrew Cooper --- CC: Jan Beulich v7: * static, and tweak comment --- docs/misc/xen-command-line.markdown | 6 ++- xen/arch/x86/spec_ctrl.c| 104 ++-- 2 files changed, 105 insertions(+), 5 deletions(-) diff --git a/docs/misc/xen-com

[Xen-devel] [PATCH v9 08/11] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

ret instructions are speculated directly to values recorded in the RSB/RAS, as there is no uncertainty in well-formed code. Guests can take advantage of this in two ways: 1) If they can find a path in Xen which executes more ret instructions than call instructions. (At least one in the wa

[Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

Intel specifies IBRS/IBPB (combined, in a single bit) and STIBP as a separate bit. AMD specifies IBPB alone in a 3rd bit. AMD's IBPB is a subset of Intel's combined IBRS/IBPB. For performance reasons, administrators might wish to express "IBPB only" even on Intel hardware, so we allow the AMD bi

[Xen-devel] [PATCH v9 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

Issuing an IBPB command flushes the Branch Target Buffer, so that any poison left by one vcpu won't remain when beginning to execute the next. The cost of IBPB is substantial, and skipped on transition to idle, as Xen's idle code is robust already. All transitions into vcpu context are fully seri

[Xen-devel] [PATCH v9 05/11] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

For performance reasons, HVM guests should have direct access to these MSRs when possible. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima CC: Kevin Tian CC: Boris Ostrovsky CC: Suravee Suthikulpanit v7: * Drop excess brackets v9: * Re-implement it light of Intels new sp

[Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

We need to be able to either set or clear IBRS in Xen context, as well as restore appropriate guest values in guest context. See the documentation in asm-x86/spec_ctrl_asm.h for details. Writes to %cr3 are slower when SPEC_CTRL.IBRS is set, so the SPEC_CTRL_{ENTRY/EXIT}* positioning is important,

[Xen-devel] [PATCH v9 04/11] x86/migrate: Move MSR_SPEC_CTRL on migrate

Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Jan Beulich --- xen/arch/x86/domctl.c | 2 ++ xen/arch/x86/hvm/hvm.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 2585d4e..1a15a34 100644 --- a/xen/arch/x86/domctl.c +++

[Xen-devel] [PATCH v9 10/11] x86/cpuid: Offer Indirect Branch Controls to guests

With all infrastructure in place, it is now safe to let guests see and use these features. Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Acked-by: Wei Liu --- v9: * Split patch in half with the libxc hunk moving earlier, and rebasing over the changed nature of STIBP --- xen/include/pu

[Xen-devel] [PATCH v9 11/11] x86/idle: Clear SPEC_CTRL while idle

On contemporary hardware, setting IBRS/STIBP has a performance impact on adjacent hyperthreads. It is therefore recommended to clear the setting before becoming idle, to avoid an idle core preventing adjacent userspace execution from running at full performance. Care must be taken to ensure there

[Xen-devel] Ping: [PATCH v2 1/2] x86/PoD: correctly handle non-order-0 decrease-reservation requests

>>> On 20.12.17 at 10:34, wrote: > p2m_pod_decrease_reservation() at the moment only returns a boolean > value: true for "nothing more to do", false for "something more to do". > If it returns false, decrease_reservation() will loop over the entire > range, calling guest_remove_page() for each pag

Re: [Xen-devel] [PATCH v9 01/11] x86/thunk: Fix GEN_INDIRECT_THUNK comment

>>> On 18.01.18 at 16:46, wrote: > This is a rebasing error in c/s 858cba0d4c6b "x86: Introduce alternative > indirect thunks" hidden by other changes in the same sentence. > > The name with dots rather than underscores was the prerelease GCC ABI. > > Signed-off-by: Andrew Cooper Acked-by: Jan

Re: [Xen-devel] [PATCH v2] x86/efi: fix build with linkers that support both coff-x86-64 and pe-x86-64

On 1/17/18 6:56 AM, Roger Pau Monne wrote: > When using a linker that supports both formats the following error > will be triggered: > > efi/buildid.o: file not recognized: File format is ambiguous > efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 > > Solve this by specifying the efi/build

Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist code

>>> On 18.01.18 at 16:10, wrote: > -int viridian_complete_apic_assist(struct vcpu *v) > +bool viridian_apic_assist_completed(struct vcpu *v) > { > uint32_t *va = v->arch.hvm_vcpu.viridian.vp_assist.va; > -int vector; > > if ( !va ) > -return 0; > +return false; >

Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist code

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 January 2018 16:21 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH v2] x86/hvm: re-work viridian APIC assist code > > >>> On 18.01.18 at 16:10, wrote: > > -int

[Xen-devel] [PATCH v3] x86/hvm: re-work viridian APIC assist code

It appears there is a case where Windows enables the APIC assist enlightenment[1] but does not use it. This scenario is perfectly valid according to the documentation, but causes the state machine in Xen to become confused leading to a domain_crash() such as the following: (XEN) d4: VIRIDIAN GUEST

Re: [Xen-devel] Ping: [PATCH v2 1/2] x86/PoD: correctly handle non-order-0 decrease-reservation requests

Hi Jan, On 18/01/18 15:59, Jan Beulich wrote: On 20.12.17 at 10:34, wrote: p2m_pod_decrease_reservation() at the moment only returns a boolean value: true for "nothing more to do", false for "something more to do". If it returns false, decrease_reservation() will loop over the entire range, ca

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

flight 118153 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/118153/ 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. 118112 test-amd64-amd64-xl-

Re: [Xen-devel] [RFC PATCH] arm64: vgic-v3: Add ITS doorbell region in Dom0 stage-2

Hi Manish, On 18/01/18 06:15, mja...@caviumnetworks.com wrote: From: Manish Jaggi This patch introduces a function vgic_map_translation_space for mapping ITS 64K translater space for doorbells in dom0 stage-2. It is required as dom0 PCI devices behined SMMU wont be able to write MSIs. s/beh

[Xen-devel] [PATCH] xen: append EXTRA_CFLAGS to CFLAGS for expert builds

Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS environment variable. This is not a configuration that is supported but is only aimed to help support testing and troubleshooting when you need to make changes. Signed-off-by: Doug Goldstein --- CC: Andrew Cooper CC: George Dunlap CC: Ia

Re: [Xen-devel] [PATCH] xen: append EXTRA_CFLAGS to CFLAGS for expert builds

Doug Goldstein writes ("[PATCH] xen: append EXTRA_CFLAGS to CFLAGS for expert builds"): > Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS environment > variable. This is not a configuration that is supported but is only > aimed to help support testing and troubleshooting when you need to

[Xen-devel] [xen-4.6-testing test] 118166: tolerable FAIL - PUSHED

flight 118166 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/118166/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 117116 test-armhf-armhf-libvirt-raw 13 s

Re: [Xen-devel] [RFC PATCH] arm64: vgic-v3: Add ITS doorbell region in Dom0 stage-2

On 01/18/2018 10:22 PM, Julien Grall wrote: Hi Manish, Hi Julien, On 18/01/18 06:15, mja...@caviumnetworks.com wrote: From: Manish Jaggi This patch introduces a function vgic_map_translation_space for mapping ITS 64K translater space for doorbells in dom0 stage-2. It is required as dom0 P

Re: [Xen-devel] [RFC PATCH] arm64: vgic-v3: Add ITS doorbell region in Dom0 stage-2

Hi, On 18/01/18 17:25, Manish Jaggi wrote: On 01/18/2018 10:22 PM, Julien Grall wrote: Hi Manish, Hi Julien, On 18/01/18 06:15, mja...@caviumnetworks.com wrote: From: Manish Jaggi This patch introduces a function vgic_map_translation_space for mapping ITS 64K translater space for doorbe

Re: [Xen-devel] [PATCH] xen: append EXTRA_CFLAGS to CFLAGS for expert builds

On 18/01/18 17:04, Doug Goldstein wrote: > Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS environment > variable. This is not a configuration that is supported but is only > aimed to help support testing and troubleshooting when you need to make > changes. > > Signed-off-by: Doug Goldste

[Xen-devel] [linux-linus test] 118154: trouble: broken/fail/pass

flight 118154 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118154/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw broken test-armhf-armhf-libv

Re: [Xen-devel] [PATCH v9 05/11] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

On 01/18/2018 10:46 AM, Andrew Cooper wrote: > For performance reasons, HVM guests should have direct access to these MSRs > when possible. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Jun Nakajima > CC: Kevin Tian > CC: Boris Ostrovsky > CC: Suravee Suthikulpanit > > v7: >

[Xen-devel] [PATCH 1/9] Update shim.config

To avoid having it changed every time the shim is built. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper --- tools/firmware/xen-dir/shim.config | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config index 78b965f

[Xen-devel] [PATCH 3/9] x86/guest: clean up guest/xen.h

Remove extraneous semicolon. Add blank lines. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/include/asm-x86/guest/xen.h | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-x86/guest/xen.h inde

[Xen-devel] [PATCH 0/9] Fix and improvements to pvshim

First batch of patches to fix problems I know of. Wei Liu (9): Update shim.config libxl: remove whitespaces introduced in 62982da926 x86/guest: clean up guest/xen.h Remove sched=null from shim cmdline and doc x86: relocate pvh_info Revert "x86/boot: Map more than the first 16MB" libx

[Xen-devel] [PATCH 8/9] xen/consoled: discard NUL from guest

According to [0], some program sends NUL for padding purpose. We can discard them. https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html#SEC7 Reported-by: Sarah Newman Signed-off-by: Wei Liu --- Cc: Sarah Newman Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson A

  1   2   >