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

flight 120151 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120151/ 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

Re: [Xen-devel] [PATCH v2 1/5] x86/entry: Correct comparisons against boolean variables

>>> On 27.02.18 at 15:50, wrote: > The correct way to check a boolean is `cmpb $0` or `testb $0xff`, whereas a > lot of our entry code uses `testb $1`. This will work in principle for values > which are really C _Bool types, but won't work for other integer types which

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

On 02/03/18 17:10, Jan Beulich wrote: On 02.03.18 at 16:43, wrote: >> On 02/03/18 15:35, Jan Beulich wrote: >>> --- a/xen/arch/x86/mm.c >>> +++ b/xen/arch/x86/mm.c >>> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p) >>> STACK_SIZE -

Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image

On 02/03/18 14:34, Jan Beulich wrote: > Commit 422588e885 ("x86/xpti: Hide almost all of .text and all > .data/.rodata/.bss mappings") carefully limited the Xen image cloning to > just entry code, but then overwrote the just allocated and populated L3 > entry with the normal one again covering

Re: [Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

>>> On 02.03.18 at 17:46, wrote: > Xen also uses clang's assembler when it is possible. Change the macro > names to not be GAS specific. > > Patch produced with: > > $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \ > do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done > >

Re: [Xen-devel] update_runstate_area and Linux KPTI

>>> On 02.03.18 at 17:25, wrote: > On 02/03/18 16:18, Jan Beulich wrote: > On 02.03.18 at 17:04, wrote: >>> The proper way to do this is indeed by a nominated (guest) physical >>> address, at which point Xen can make all/any updates at times

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

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

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

On 02/03/18 14:35, Jan Beulich wrote: > Other than for the main mappings, don't even do this in release builds, > as there are no huge page shattering concerns here. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper , although I think somewhere

Re: [Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

>>> On 21.02.18 at 15:02, wrote: > @@ -872,7 +879,7 @@ map_grant_ref( > struct grant_table *lgt, *rgt; > struct vcpu *led; > grant_handle_t handle; > -unsigned long frame = 0; > +mfn_t frame = _mfn(0); If the initializer is needed at all, I think

Re: [Xen-devel] update_runstate_area and Linux KPTI

On 02/03/18 15:57, Julien Grall wrote: > Hi, > > While I was looking at some unrelated problem with Xen ARM P2M code, I > noticed that the function update_runstate_area is using guest virtual > address to update the vCPU runstate. That function will be called when > context switch to a vCPU.

Re: [Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

>>> On 02.03.18 at 16:59, wrote: > On 02/03/18 15:54, Jan Beulich wrote: > On 21.02.18 at 15:02, wrote: >>> @@ -872,7 +879,7 @@ map_grant_ref( >>> struct grant_table *lgt, *rgt; >>> struct vcpu *led; >>> grant_handle_t handle;

Re: [Xen-devel] update_runstate_area and Linux KPTI

>>> On 02.03.18 at 17:04, wrote: > The proper way to do this is indeed by a nominated (guest) physical > address, at which point Xen can make all/any updates at times of its > choosing, and the guests pagetable/permissions state at an instantaneous > moment don't

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

>>> On 02.03.18 at 17:41, wrote: > On 02/03/18 17:10, Jan Beulich wrote: > On 02.03.18 at 16:43, wrote: >>> On 02/03/18 15:35, Jan Beulich wrote: --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5576,6 +5576,14 @@ void

Re: [Xen-devel] Setting up a Xen x86 community call

> -Original Message- > From: Lars Kurth [mailto:lars.kurth@gmail.com] > Sent: 02 March 2018 15:40 > To: xen-devel > Cc: committ...@xenproject.org; Jan Beulich ; Andrew > Cooper ; Susie Li

[Xen-devel] osstest planned outage consultation

Several of the VMs in the Massachusetts Xen Project Test Lab, which runs our community osstest instance, need to be upgraded. And we want to sort out some oddities with the way the storage is configured. This will involve a long outage, maybe 3 days or so. We should schedule this when it is

Re: [Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

On 02/03/18 16:46, Wei Liu wrote: > Xen also uses clang's assembler when it is possible. Change the macro > names to not be GAS specific. > > Patch produced with: > > $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \ > do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done

Re: [Xen-devel] Setting up a Xen x86 community call

On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote: > Hi all, > (sorry for the extensive distribution list - I went through MAINTAINERS and > people who may have an interest) > > I would like to start organizing a recurring x86 community call to discuss > and sync-up on upcoming

Re: [Xen-devel] Setting up a Xen x86 community call

On 02/03/18 16:39, Lars Kurth wrote: > Hi all, > (sorry for the extensive distribution list - I went through MAINTAINERS and > people who may have an interest) > > I would like to start organizing a recurring x86 community call to discuss > and sync-up on upcoming features for Xen on x86. This

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

On Fri, 2 Mar 2018, Stefano Stabellini wrote: > On Fri, 2 Mar 2018, Julien Grall wrote: > > Hi, > > > > On 01/03/18 23:27, Stefano Stabellini wrote: > > > See the corresponding Linux commit as reference: > > > > > >commit f91e2c3bd427239c198351f44814dd39db91afe0 > > >Author: Catalin

Re: [Xen-devel] [PATCH v4 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

Hi Jan, On 02/03/18 15:54, Jan Beulich wrote: On 21.02.18 at 15:02, wrote: @@ -872,7 +879,7 @@ map_grant_ref( struct grant_table *lgt, *rgt; struct vcpu *led; grant_handle_t handle; -unsigned long frame = 0; +mfn_t frame = _mfn(0); If the

Re: [Xen-devel] [PATCH] Please Welcome Julien, our new Committer

Hi Stefano, On 01/03/18 19:17, Stefano Stabellini wrote: In recognition of his expertise and commitment to Xen Project, please join me in welcoming Julien among the Committers and REST Maintainers. Signed-off-by: Stefano Stabellini Thank you for the nomination! FWIW:

Re: [Xen-devel] Setting up a Xen x86 community call

On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote: > Hi all, > (sorry for the extensive distribution list - I went through MAINTAINERS and > people who may have an interest) > > I would like to start organizing a recurring x86 community call to discuss > and sync-up on upcoming

Re: [Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

On Fri, Mar 02, 2018 at 04:46:25PM +, Wei Liu wrote: > Xen also uses clang's assembler when it is possible. Change the macro > names to not be GAS specific. > > Patch produced with: > > $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \ > do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done grep

Re: [Xen-devel] update_runstate_area and Linux KPTI

On 02/03/18 17:25, Julien Grall wrote: > > > On 02/03/18 16:18, Jan Beulich wrote: > On 02.03.18 at 17:04, wrote: >>> The proper way to do this is indeed by a nominated (guest) physical >>> address, at which point Xen can make all/any updates at times of its >>>

Re: [Xen-devel] update_runstate_area and Linux KPTI

On 02/03/18 17:05, Juergen Gross wrote: > On 02/03/18 17:51, Jan Beulich wrote: > On 02.03.18 at 17:25, wrote: >>> On 02/03/18 16:18, Jan Beulich wrote: >>> On 02.03.18 at 17:04, wrote: > The proper way to do this is indeed by a

Re: [Xen-devel] Setting up a Xen x86 community call

On 03/02/2018 03:39 PM, Lars Kurth wrote: > Hi all, > (sorry for the extensive distribution list - I went through MAINTAINERS and > people who may have an interest) > > I would like to start organizing a recurring x86 community call to discuss > and sync-up on upcoming features for Xen on x86.

Re: [Xen-devel] update_runstate_area and Linux KPTI

On 02/03/18 18:09, Andrew Cooper wrote: > On 02/03/18 17:05, Juergen Gross wrote: >> On 02/03/18 17:51, Jan Beulich wrote: >> On 02.03.18 at 17:25, wrote: On 02/03/18 16:18, Jan Beulich wrote: On 02.03.18 at 17:04, wrote: >>

Re: [Xen-devel] [PATCH v4 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

>>> On 21.02.18 at 15:02, wrote: > --- a/xen/arch/x86/pv/emul-priv-op.c > +++ b/xen/arch/x86/pv/emul-priv-op.c > @@ -43,16 +43,6 @@ > #include "emulate.h" > #include "mm.h" > > -/* Override macros from asm/page.h to make them work with mfn_t */ > -#undef mfn_to_page >

Re: [Xen-devel] update_runstate_area and Linux KPTI

On 02/03/18 16:18, Jan Beulich wrote: On 02.03.18 at 17:04, wrote: The proper way to do this is indeed by a nominated (guest) physical address, at which point Xen can make all/any updates at times of its choosing, and the guests pagetable/permissions state at an

Re: [Xen-devel] PVH backports to 4.9 and 4.8

On Fri, Mar 02, 2018 at 08:23:50AM -0700, Jan Beulich wrote: > >>> On 02.03.18 at 15:36, wrote: > > On Fri, Mar 02, 2018 at 07:31:43AM -0700, Jan Beulich wrote: > >> >>> On 02.03.18 at 15:22, wrote: > >> > I'd be in favor of merging the 4.8.3pre-shim-comet

Re: [Xen-devel] [PATCH v2 3/5] x86/pv: Introduce pv_create_exception_frame()

>>> On 27.02.18 at 15:50, wrote: > v2: > * Use domain_crash() rather than domain_crash_sync(). All callers >immediately continue to {compat_}test_all_events > * Count the number of frame[] entries correctly > * Consistently use 64bit operations when adjusting

[Xen-devel] [PATCH] x86: rename HAVE_GAS_* to HAVE_AS_*

Xen also uses clang's assembler when it is possible. Change the macro names to not be GAS specific. Patch produced with: $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \ do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done Signed-off-by: Wei Liu --- Cc: Jan Beulich

Re: [Xen-devel] [PATCH v2] x86: invpcid support

On 02/03/18 16:47, Jan Beulich wrote: On 02.03.18 at 17:23, wrote: >> +static inline void invpcid(unsigned int pcid, unsigned long addr, >> + unsigned int type) >> +{ >> +struct { >> +uint64_t pcid:12; >> +uint64_t

Re: [Xen-devel] Setting up a Xen x86 community call

On 02/03/18 15:39, Lars Kurth wrote: > Hi all, > (sorry for the extensive distribution list - I went through MAINTAINERS and > people who may have an interest) > > I would like to start organizing a recurring x86 community call to discuss > and sync-up on upcoming features for Xen on x86. This

Re: [Xen-devel] Setting up a Xen x86 community call

On Mar 2, 2018, at 10:39, Lars Kurth wrote: > I would suggest to start with a 1 hour monthly meeting: possibly every 2nd > Tue or Thu each month (depends on timing). I know that people are spread > across different timezones (from China to the US), so I would like to

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

On Fri, 2 Mar 2018, Julien Grall wrote: > Hi Stefano, > > On 01/03/18 23:26, Stefano Stabellini wrote: > > Even different cpus in big.LITTLE systems are expected to have the same > > cacheline size. Unless the minimum of all cacheline sizes is used across > > all cpu cores, cache coherency

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

On Fri, 2 Mar 2018, Andrew Cooper wrote: > On 02/03/18 18:26, Stefano Stabellini wrote: > > > >>> Suggested-by: Julien Grall > >>> Signed-off-by: Stefano Stabellini > >>> > >>> --- > >>> Changes in v3: > >>> - new patch > >>> > >>> --- > >>>

Re: [Xen-devel] [PATCH] vvmx: fixes after CR4 trapping optimizations

On Fri, Mar 02, 2018 at 02:29:54PM +, Sergey Dyasli wrote: > On Thu, 2018-03-01 at 16:19 +, Roger Pau Monne wrote: > > Commit 406817 doesn't update nested VMX code in order to take into > > account L1 CR4 host mask when nested guest (L2) writes to CR4, and > > thus the mask written to

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

On 02/03/18 18:26, Stefano Stabellini wrote: > >>> Suggested-by: Julien Grall >>> Signed-off-by: Stefano Stabellini >>> >>> --- >>> Changes in v3: >>> - new patch >>> >>> --- >>> Interestingly I couldn't find a better way in C89 to printk a size_t

[Xen-devel] [PATCH v2] x86: invpcid support

Provide the functions needed for different modes. Add cpu_has_invpcid. Signed-off-by: Wei Liu Reviewed-by: Juergen Gross --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Juergen Gross ---

Re: [Xen-devel] update_runstate_area and Linux KPTI

On 02/03/18 16:18, Jan Beulich wrote: On 02.03.18 at 17:04, wrote: >> The proper way to do this is indeed by a nominated (guest) physical >> address, at which point Xen can make all/any updates at times of its >> choosing, and the guests pagetable/permissions state

Re: [Xen-devel] [RFC PATCH 31/49] ARM: new VGIC: Add PENDING registers handlers

Hi, On 19/02/18 15:43, Julien Grall wrote: > > > On 19/02/18 15:32, Andre Przywara wrote: >> Hi, > > Hi Andre, > >> On 16/02/18 17:16, Julien Grall wrote: >>> On 09/02/18 14:39, Andre Przywara wrote: + +    /* Loop over all IRQs affected by this read */ +    for ( i = 0; i <

Re: [Xen-devel] [PATCH v2] x86: invpcid support

>>> On 02.03.18 at 17:23, wrote: > +static inline void invpcid(unsigned int pcid, unsigned long addr, > + unsigned int type) > +{ > +struct { > +uint64_t pcid:12; > +uint64_t reserved:52; > +uint64_t addr; > +} desc =

Re: [Xen-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

Any chance ALSA community may also review the below? BTW, the driver, with the changes proposed, is at [1] Thank you, Oleksandr On 02/05/2018 10:24 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Hi, all! Foreword This change is

Re: [Xen-devel] [PATCH v2] x86: invpcid support

On Fri, Mar 02, 2018 at 09:47:45AM -0700, Jan Beulich wrote: > >>> On 02.03.18 at 17:23, wrote: > > +static inline void invpcid(unsigned int pcid, unsigned long addr, > > + unsigned int type) > > +{ > > +struct { > > +uint64_t pcid:12; >

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On 03/02/2018 05:40 AM, Wei Liu wrote: On Fri, Mar 02, 2018 at 12:29:31PM +, Wei Liu wrote: On Mon, Feb 26, 2018 at 09:53:38AM -0700, Jim Fehlig wrote: On 02/26/2018 01:46 AM, Juergen Gross wrote: When creating a pthread in xs_watch() try to get the minimal needed size of the thread from

Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image

On 02/03/18 17:04, Jan Beulich wrote: On 02.03.18 at 17:53, wrote: >> On 02/03/18 14:34, Jan Beulich wrote: >>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything - >>> there already is a suitable ASSERT() in xen.lds.S. >> This isn't quite true.

Re: [Xen-devel] [PATCH v2 1/5] x86/entry: Correct comparisons against boolean variables

On Tue, Feb 27, 2018 at 02:50:32PM +, Andrew Cooper wrote: > The correct way to check a boolean is `cmpb $0` or `testb $0xff`, whereas a > lot of our entry code uses `testb $1`. This will work in principle for values > which are really C _Bool types, but won't work for other integer types

Re: [Xen-devel] [PATCH v4 11/16] xen/mm: Switch page_alloc.c to typesafe MFN

On 02/03/18 15:18, Jan Beulich wrote: On 21.02.18 at 15:02, wrote: @@ -1735,14 +1743,14 @@ static void init_heap_pages( if ( unlikely(!avail[nid]) ) { -unsigned long s = page_to_mfn(pg + i); -unsigned long e =

[Xen-devel] update_runstate_area and Linux KPTI

Hi, While I was looking at some unrelated problem with Xen ARM P2M code, I noticed that the function update_runstate_area is using guest virtual address to update the vCPU runstate. That function will be called when context switch to a vCPU. However, that vCPU may run in userspace context.

Re: [Xen-devel] [PATCH v4 15/16] xen/x86: Switch mfn_to_page in x86_64/mm.c to use typesafe MFN

>>> On 21.02.18 at 15:02, wrote: > @@ -160,7 +162,8 @@ static int m2p_mapped(unsigned long spfn) > > static int share_hotadd_m2p_table(struct mem_hotadd_info *info) > { > -unsigned long i, n, v, m2p_start_mfn = 0; > +unsigned long i, n, v; > +mfn_t

Re: [Xen-devel] [PATCH v2 2/2] x86/xpti: don't map stack guard pages

>>> On 02.03.18 at 16:43, wrote: > On 02/03/18 15:35, Jan Beulich wrote: >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p) >> STACK_SIZE - PRIMARY_STACK_SIZE - IST_MAX * >> PAGE_SIZE);

[Xen-devel] [PATCH v2] vvmx: fixes after CR4 trapping optimizations

Commit 406817 doesn't update nested VMX code in order to take into account L1 CR4 host mask when nested guest (L2) writes to CR4, and thus the mask written to CR4_GUEST_HOST_MASK is likely not as restrictive as it should be. Also the VVMCS GUEST_CR4 value should be updated to match the underlying

Re: [Xen-devel] [PATCH v2] x86: invpcid support

On 02/03/18 16:23, Wei Liu wrote: > Provide the functions needed for different modes. Add cpu_has_invpcid. > > Signed-off-by: Wei Liu > Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image

>>> On 02.03.18 at 17:53, wrote: > On 02/03/18 14:34, Jan Beulich wrote: >> Note that the removed BUILD_BUG_ON()s don't get replaced by anything - >> there already is a suitable ASSERT() in xen.lds.S. > > This isn't quite true. You've changed the mechanism by which

Re: [Xen-devel] update_runstate_area and Linux KPTI

On 02/03/18 17:51, Jan Beulich wrote: On 02.03.18 at 17:25, wrote: >> On 02/03/18 16:18, Jan Beulich wrote: >> On 02.03.18 at 17:04, wrote: The proper way to do this is indeed by a nominated (guest) physical address, at which

Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get minimum thread stack size for watch thread

On Fri, Mar 02, 2018 at 10:23:08AM -0700, Jim Fehlig wrote: > On 03/02/2018 05:40 AM, Wei Liu wrote: > > On Fri, Mar 02, 2018 at 12:29:31PM +, Wei Liu wrote: > > > On Mon, Feb 26, 2018 at 09:53:38AM -0700, Jim Fehlig wrote: > > > > On 02/26/2018 01:46 AM, Juergen Gross wrote: > > > > > When

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

On Fri, 2 Mar 2018, Julien Grall wrote: > Hi, > > On 01/03/18 23:27, Stefano Stabellini wrote: > > See the corresponding Linux commit as reference: > > > >commit f91e2c3bd427239c198351f44814dd39db91afe0 > >Author: Catalin Marinas > >Date: Tue Dec 7

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

Thanks, I'll mention it in the commit message. On Fri, 2 Mar 2018, Julien Grall wrote: > Hi, > > I forgot to mention in the title: > > You read the minimum D-Cache line size. The minimum I-Cache line size is read > from CTR_EL0.IminLine. > > Cheers, > > On 01/03/18 23:27, Stefano Stabellini

[Xen-devel] [PATCH v4 5/7] xen/arm: set VPIDR based on the MIDR value of the underlying pCPU

On big.LITTLE systems not all cores have the same MIDR. Instead of storing only one VPIDR per domain, initialize it to the value of the MIDR of the pCPU where the vCPU will run. This way, assuming that the vCPU has been created with the right pCPU affinity, the guest will be able to read the

Re: [Xen-devel] [PATCH v4 01/20] x86emul: extend vbroadcasts{s, d} to AVX2

On 28/02/18 12:57, Jan Beulich wrote: > These gain register forms now. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [xen-4.10-testing test] 120111: regressions - trouble: broken/fail/pass

flight 120111 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120111/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-amd64-pvgrub broken

Re: [Xen-devel] [PATCH] xl: remove apic option for PVH guests

On 02/03/18 11:09, Wei Liu wrote: > On Thu, Mar 01, 2018 at 05:01:55PM +, Roger Pau Monné wrote: >> On Thu, Mar 01, 2018 at 04:01:23PM +, Wei Liu wrote: >>> On Thu, Mar 01, 2018 at 03:57:18PM +, Andrew Cooper wrote: On 01/03/18 12:22, Wei Liu wrote: > On Wed, Feb 28, 2018 at

[Xen-devel] [PATCH v4 7/7] xen/arm: disable CPUs with different dcache line sizes

Even different cpus in big.LITTLE systems are expected to have the same dcache line size. Unless the minimum of all dcache line sizes is used across all cpu cores, cache coherency protocols can go wrong. Instead, for now, just disable any cpu with a different dcache line size. This check is not

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

flight 120164 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120164/ 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

[Xen-devel] [PATCH v4 3/7] xen/arm: make processor a per cpu variable

There can be processors of different kinds on a single system. Make processor a per_cpu variable pointing to the right processor type for each core. Suggested-by: Julien Grall Signed-off-by: Stefano Stabellini Reviewed-by: Julien Grall

[Xen-devel] [PATCH v4 1/7] xen/arm: Read the dcache line size from CTR register

See the corresponding Linux commit as reference: commit f91e2c3bd427239c198351f44814dd39db91afe0 Author: Catalin Marinas Date: Tue Dec 7 16:52:04 2010 +0100 ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on ARMv7 The current

[Xen-devel] [PATCH v4 4/7] xen/arm: read ACTLR on the pcpu where the vcpu will run

On big.LITTLE systems not all cores have the same ACTLR. Instead of reading ACTLR and setting v->arch.actlr in vcpu_initialise, do it later on the same pcpu where the vcpu will run. This way, assuming that the vcpu has been created with the right pcpu affinity, the guest will be able to read the

[Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support

Hi all, This series changes the initialization of two virtual registers to make sure they match the value of the underlying physical cpu. It also disables cpus different from the boot cpu, unless a newly introduced command line option is specified. In that case, it explains how to setup the

[Xen-devel] [PATCH v4 2/7] xen/arm: Park CPUs with a MIDR different from the boot CPU.

From: Julien Grall From: Julien Grall Xen does not properly support big.LITTLE platform. All vCPUs of a guest will always have the MIDR of the boot CPU (see arch_domain_create). At best the guest may see unreliable performance (vCPU switching between

Re: [Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

On 02/03/18 07:10, Jan Beulich wrote: On 01.03.18 at 17:58, wrote: >> On 01/03/18 10:54, Jan Beulich wrote: >> On 01.03.18 at 11:36, wrote: On Thu, Mar 01, 2018 at 12:28:27AM -0700, Jan Beulich wrote: Andrew Cooper

[Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

[Xen-devel] [PATCH 0/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

Here is the patch for updating the canonical definition of the hvm_start_info struct corresponding to the discussion happening on the linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH entry point: KVM: x86: Allow Qemu/KVM to use PVH entry point

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

On 02/03/2018 18:33, Stefano Stabellini wrote: On Fri, 2 Mar 2018, Stefano Stabellini wrote: On Fri, 2 Mar 2018, Julien Grall wrote: Hi, On 01/03/18 23:27, Stefano Stabellini wrote: See the corresponding Linux commit as reference: commit f91e2c3bd427239c198351f44814dd39db91afe0

Re: [Xen-devel] [PATCH v3 6/6] xen/arm: disable CPUs with different cacheline sizes

On 02/03/2018 18:35, Stefano Stabellini wrote: On Fri, 2 Mar 2018, Andrew Cooper wrote: On 02/03/18 18:26, Stefano Stabellini wrote: Suggested-by: Julien Grall Signed-off-by: Stefano Stabellini --- Changes in v3: - new patch ---

[Xen-devel] [PATCH] x86/boot: Annotate the multiboot headers with size and type information

This causes objdump not to try and disassemble the data. While altering this area, switch to using .balign, and fill with 0xc2 to help highlight the embedded padding (rather than having it filled with 0f 1f 40 00 which is a long nop). Also, shorten the labels by stripping off the _start suffix.

[Xen-devel] [PATCH v4 6/7] xen/arm: update the docs about heterogeneous computing

Introduce a new document about big.LITTLE and update the documentation of hmp-unsafe. Also update the warning messages to point users to the docs. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall CC: jbeul...@suse.com CC:

Re: [Xen-devel] Setting up a Xen x86 community call

On Fri, Mar 2, 2018 at 8:39 AM, Lars Kurth wrote: > Hi all, > (sorry for the extensive distribution list - I went through MAINTAINERS and > people who may have an interest) > > I would like to start organizing a recurring x86 community call to discuss > and sync-up on

Re: [Xen-devel] Setting up a Xen x86 community call

On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote: > Hi all, > (sorry for the extensive distribution list - I went through MAINTAINERS and > people who may have an interest) > > I would like to start organizing a recurring x86 community call to discuss > and sync-up on upcoming

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote: > The start info structure that is defined as part of the x86/HVM direct boot > ABI and used for starting Xen PVH guests would be more versatile if it also > included a way to pass information about the memory map to the guest. This >

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On 3/2/2018 1:20 PM, Konrad Rzeszutek Wilk wrote: On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote: The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass

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

flight 120169 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120169/ 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

Re: [Xen-devel] [PATCH 2/3] xen/arm: domain_build: Rework the way to allocate the event channel interrupt

On Tue, 27 Feb 2018, julien.gr...@arm.com wrote: > From: Julien Grall > > At the moment, a placeholder will be created in the device-tree for the > event channel information. Later in the domain construction, the > interrupt for the event channel upcall will be allocated

Re: [Xen-devel] [PATCH 1/3] xen/arm: domain_build: Prepare DTB/ACPI tables after specific mappings

On Tue, 27 Feb 2018, julien.gr...@arm.com wrote: > From: Julien Grall > > A follow-up patch will require to have all interrupts routed to the > hardware registered before calling prepare_dtb/prepare_acpi. > > At the moment, it is not necessary to call platform specific

Re: [Xen-devel] [PATCH 3/3] xen/arm: domain_builder: irq sanity check logic fix

On Tue, 27 Feb 2018, julien.gr...@arm.com wrote: > From: Stewart Hildebrand > > Since commit "xen/arm: domain_build: Rework the way to allocate the > event channel interrupt", it is not possible for an irq to be both below 16 > and greater/equal than 32. > >

Re: [Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

On Wed, 28 Feb 2018, Julien Grall wrote: > Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt" > assumed the read-write lock can be taken recursively. However, this > assumption is wrong and will lead to deadlock when the lock is > contended. > > To avoid the nested lock, rework

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

flight 120116 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120116/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 17 guest-start.2 fail blocked in 119771

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

flight 120177 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120177/ 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

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

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

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

flight 120120 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/120120/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 120037

Re: [Xen-devel] [PATCH v4 00/20] x86: emulator enhancements

On 02/28/2018 02:50 PM, Jan Beulich wrote: > 01: extend vbroadcasts{s,d} to AVX2 > 02: support most remaining AVX2 insns > 03: support AVX2 gather insns > 04: support XOP insns > 05: support 3DNow! insns > 06: place test blobs in executable section > 07: move and rename XSTATE_* > 08: abstract out

Re: [Xen-devel] [PATCH v2] x86/link: Don't merge .init.text and .init.data

>>> On 01.03.18 at 19:33, wrote: > c/s 1308f0170c merged .init.text and .init.data, because EFI might properly > write-protect r/o sections. > > However, that change makes xen-syms unusable for disassembly analysis. In > particular, searching for indirect branches as

Re: [Xen-devel] [PATCH] xen/arm: Read the cacheline size from CTR register

Hi, On 01/03/18 23:27, Stefano Stabellini wrote: See the corresponding Linux commit as reference: commit f91e2c3bd427239c198351f44814dd39db91afe0 Author: Catalin Marinas Date: Tue Dec 7 16:52:04 2010 +0100 ARM: 6527/1: Use CTR instead of CCSIDR for

[Xen-devel] [PATCH v2 0/6] xen/x86: various XPTI speedups

This patch series aims at reducing the overhead of the XPTI Meltdown mitigation. It is based on Jan's XPTI speedup series and Wei's series for support of PCID and INVPCID. Patch 1 had been posted before, the main changes in this patch are due to addressing Jan's comments on my first version. The

[Xen-devel] [PATCH v2 6/6] xen/x86: use PCID feature for XPTI

Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI: - hypervisor active and guest in kernel mode - guest active and in kernel mode - hypervisor active and guest

[Xen-devel] [PATCH v2 4/6] xen/x86: disable global pages for domains with XPTI active

Instead of flushing the TLB from global pages when switching address spaces with XPTI being active just disable global pages via %cr4 completely when a domain subject to XPTI is active. This avoids the need for extra TLB flushes as loading %cr3 will remove all TLB entries. Signed-off-by: Juergen

[Xen-devel] [PATCH v2 1/6] x86/xpti: avoid copying L4 page table contents when possible

For mitigation of Meltdown the current L4 page table is copied to the cpu local root page table each time a 64 bit pv guest is entered. Copying can be avoided in cases where the guest L4 page table hasn't been modified while running the hypervisor, e.g. when handling interrupts or any hypercall

[Xen-devel] [PATCH v2 5/6] xen/x86: use flag byte for decision whether xen_cr3 is valid

Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to be switched on entry to Xen, or negative for keeping the value while indicating not to restore %cr3, or positive in case %cr3 is to be restored. Switch to use a flag byte instead of a negative xen_cr3 value in order to allow

[Xen-devel] [PATCH v2 2/6] x86/xpti: don't flush TLB twice when switching to 64-bit pv context

When switching to a 64-bit pv context the TLB is flushed twice today: the first time when switching to the new address space in write_ptbase(), the second time when switching to guest mode in restore_to_guest. Avoid the first TLB flush in that case. Signed-off-by: Juergen Gross

[Xen-devel] [xtf test] 120100: all pass - PUSHED

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

  1   2   >