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

flight 116915 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116915/ 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 are

Re: [Xen-devel] [RFC PATCH 29/31] xen/arm: Introduce CPUFreq Interface component

On Wed, 6 Dec 2017, Oleksandr Tyshchenko wrote: > >> +perf->platform_limit = platform_limit; > >> +perf->shared_type = CPUFREQ_SHARED_TYPE_ANY; > >> +perf->domain_info.domain = cpumask_first(mask); > >> +perf->domain_info.num_processors = cpumask_weight(mask); > >> + > >> +/*

[Xen-devel] [qemu-mainline test] 116904: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH] domctl: improve locking during domain destruction

On 06/12/17 15:31, Jan Beulich wrote: > There is no need to hold the global domctl lock across domain_kill() - > the domain lock is fully sufficient here, and parallel cleanup after > multiple domains performs quite a bit better this way. > > Signed-off-by: Jan Beulich This is

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

>>> On 25.07.17 at 19:26, 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 best moment for the

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

Hi Andrew, On 12/06/2017 03:08 PM, Andrew Cooper wrote: On 06/12/17 13:04, Julien Grall wrote: Hi Jan, On 12/06/2017 12:58 PM, Jan Beulich wrote: On 06.12.17 at 12:47, wrote: On 12/06/2017 11:45 AM, Jan Beulich wrote: On 06.12.17 at 10:47,

[Xen-devel] [OSSTEST RFC 06/16] Osstest/CentOS.pm: Introduce CentOS support, starting with kickstart_installcmdline_core

This function will be use later to install CentOS on a host. Signed-off-by: Anthony PERARD --- Osstest/CentOS.pm | 51 +++ 1 file changed, 51 insertions(+) create mode 100644 Osstest/CentOS.pm diff --git

[Xen-devel] [OSSTEST RFC 04/16] TestSupport: In host_install_postboot, don't call update-rc.d on CentOS

Signed-off-by: Anthony PERARD --- Osstest/TestSupport.pm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm index 13e4360..b0e21bf 100644 --- a/Osstest/TestSupport.pm +++ b/Osstest/TestSupport.pm @@

Re: [Xen-devel] [PATCH 05/12] ARM: VGIC: move gic_remove_from_lr_pending()

Hi, On 26/10/17 01:20, Stefano Stabellini wrote: > On Thu, 19 Oct 2017, Andre Przywara wrote: >> gic_remove_from_lr_pending() was not only misnamed, it also had the wrong >> abstraction, as it should not live in gic.c. >> Move it into vgic.c and vgic.h, where it belongs, and rename it on the >>

[Xen-devel] [PATCH] x86/intel: Drop zeroed-out select_idle_routine() function

Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpu/intel.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index ac932e5..d3145c0 100644 --- a/xen/arch/x86/cpu/intel.c +++

Re: [Xen-devel] [PATCH 2/2] x86: rename DIRTY_GS_BASE_USER

On 06/12/17 16:38, Jan Beulich wrote: > As of commit 91f85280b9 ("x86: fix GS-base-dirty determination") the > USER part of it isn't really appropriate anymore. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH 1/2] x86: improve MSR_SHADOW_GS accesses

On 06/12/17 16:37, Jan Beulich wrote: > --- a/xen/include/asm-x86/msr.h > +++ b/xen/include/asm-x86/msr.h > @@ -8,6 +8,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -172,6 +173,24 @@ static inline unsigned long rdgsbase(voi > return base; > } >

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

Hi Jan, I guess I have been CCed because you would like this patch is fixing the regression you mentioned on IRC? Cheers, On 12/05/2017 04:13 PM, Jan Beulich wrote: vio->mmio_retry is being set when a repeated string insn is being split up. In that case we'll exit to the guest, expecting

Re: [Xen-devel] [RFC v3 4/4] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

On 12/05/2017 11:26 PM, Goel, Sameer wrote: On 12/5/2017 7:17 AM, Julien Grall wrote: Hello, On 05/12/17 03:59, Sameer Goel wrote: This driver follows an approach similar to smmu driver. The intent here is to reuse as much Linux code as possible. - Glue code has been introduced in headers

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

>>> On 05.12.17 at 19:39, wrote: > The suggested policy is based on the KVM one: > - If we trap a S/W instructions, we enable VM trapping (e.g > HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean. > - We flush the caches on both caches

Re: [Xen-devel] [PATCH] xen-netback: Fix logging message with spurious period after newline

> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: 06 December 2017 06:40 > To: Wei Liu ; Paul Durrant > Cc: xen-devel@lists.xenproject.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH]

Re: [Xen-devel] [PATCH] xenmem_add_to_physmap_one() has no need to know of XENMAPSPACE_gmfn_range

>>> On 06.12.17 at 17:32, wrote: > On 06/12/17 16:21, Jan Beulich wrote: >> As its name says, it handles a single GMFN only anyway. Note that ARM >> needs no adjustment, as it doesn't handle the two types at all. >> >> Also take the opportunity and clean up the handling

Re: [Xen-devel] [PATCH] simplify xenmem_add_to_physmap_batch()

On 06/12/17 16:21, Jan Beulich wrote: > There's no need for > - advancing the handles and at the same time using > __copy_{from,to}_guest_offset(), > - an "out" label, > - local variables "done" and (function scope) "rc". > > Signed-off-by: Jan Beulich These changes do mean

[Xen-devel] [OSSTEST RFC 03/16] Osstest/TestSupport: Add centos to package_install_cmd

Signed-off-by: Anthony PERARD --- Osstest/TestSupport.pm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm index 65324fb..13e4360 100644 --- a/Osstest/TestSupport.pm +++ b/Osstest/TestSupport.pm @@ -530,6 +530,8 @@

[Xen-devel] [OSSTEST RFC 01/16] JobDB-Standalone.tcl: Fix read-runvar

This fix the error bellow, when the runvar exist: can't read "runvarinfo()": no such element in array while executing "set val $runvarinfo($val)" invoked from within "osstestdb eval { SELECT val FROM runvars WHERE flight = $flight AND job = $job AND

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

On Wed, Dec 06, 2017 at 03:04:11PM +, Paul Durrant wrote: >> -Original Message- >> From: Chao Gao [mailto:chao@intel.com] >> Sent: 06 December 2017 07:50 >> To: xen-de...@lists.xen.org >> Cc: Chao Gao ; Paul Durrant >> ; Tim (Xen.org)

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

> -Original Message- > From: Chao Gao [mailto:chao@intel.com] > Sent: 06 December 2017 09:02 > To: Paul Durrant > Cc: xen-de...@lists.xen.org; Tim (Xen.org) ; Stefano > Stabellini ; Konrad Rzeszutek Wilk >

Re: [Xen-devel] [PATCH] VMX: drop bogus gpa parameter from __invept()

On 06/12/17 16:28, Jan Beulich wrote: > Perhaps there once was a plan to have a flush type requiring this, but > the current SDM has no mention of such and all callers pass zero anyway. > > Take the opportunity and also change involved types to uint64_t. > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH] x86/HVM: make explicit that hvm_print_line() does output only

On 06/12/17 16:27, Jan Beulich wrote: > On input "c" being 0xff should already have the effect of bailing early > (due to the isprint()), but let's rather make this explicit. Also > convert the BUG_ON() to an ASSERT() (nothing fatal happens in the > function if this is violated), at the same time

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 12/06/2017 12:58 PM, Julien Grall wrote: > Hi George, > > On 12/06/2017 12:28 PM, George Dunlap wrote: >> On 12/05/2017 06:39 PM, Julien Grall wrote: >>> Hi all, >>> >>> Even though it is an Arm failure, I have CCed x86 folks to get feedback >>> on the approach. I have a WIP branch I could

Re: [Xen-devel] [PATCH] simplify xenmem_add_to_physmap_batch()

>>> On 06.12.17 at 17:40, wrote: > On 06/12/17 16:21, Jan Beulich wrote: >> There's no need for >> - advancing the handles and at the same time using >> __copy_{from,to}_guest_offset(), >> - an "out" label, >> - local variables "done" and (function scope) "rc". >> >>

[Xen-devel] [OSSTEST RFC 07/16] Osstest/CentOS: kickstart_create to generate an autoinstall recipe

Signed-off-by: Anthony PERARD --- Osstest/CentOS.pm | 215 ++ 1 file changed, 215 insertions(+) diff --git a/Osstest/CentOS.pm b/Osstest/CentOS.pm index 33479b1..dbba354 100644 --- a/Osstest/CentOS.pm +++

[Xen-devel] [OSSTEST RFC 15/16] make-centos-flight: Create a flight with CentOS as dom0

This is based on make-flight, with the added all_host_os=centos runvar, and without test that can not be run. Anything based on the recipe "test-debian" or "test-pair" is remove, as they require xen-tools. There is no XSM tests as the CentOS packages is built without. There is no build jobs as

[Xen-devel] [OSSTEST RFC 13/16] WORKAROUND: Osstest/TestSupport: Make target_reboot works with systemd

On host running with systemd as init, doing `ssh host reboot` will result in ssh returning an error. This patch works around by not waiting for the reboot command to return. Signed-off-by: Anthony PERARD --- Osstest/TestSupport.pm | 3 ++- 1 file changed, 2

[Xen-devel] [OSSTEST RFC 11/16] ts-centos-xen-pkg-install: Adjust daemons configuration

Ajust configuration of xenconsoled and libvirtd. Signed-off-by: Anthony PERARD --- ts-centos-xen-pkg-install | 10 ++ 1 file changed, 10 insertions(+) diff --git a/ts-centos-xen-pkg-install b/ts-centos-xen-pkg-install index e10456d..0327b72 100755 ---

[Xen-devel] [OSSTEST RFC 16/16] Osstest/TestSupport: Handle qemu-img location on CentOS

Signed-off-by: Anthony PERARD --- Osstest/TestSupport.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm index 40a5c5a..c82ba96 100644 --- a/Osstest/TestSupport.pm +++ b/Osstest/TestSupport.pm @@

[Xen-devel] [OSSTEST RFC 12/16] ts-centos-xen-pkg-install: Create bridge config

Signed-off-by: Anthony PERARD --- ts-centos-xen-pkg-install | 22 ++ 1 file changed, 22 insertions(+) diff --git a/ts-centos-xen-pkg-install b/ts-centos-xen-pkg-install index 0327b72..9a4dcdd 100755 --- a/ts-centos-xen-pkg-install +++

[Xen-devel] [OSSTEST RFC 14/16] sg-run-job: Select host install script based on all_host_os runvar

This also select a different xen installation script. Signed-off-by: Anthony PERARD --- sg-run-job | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/sg-run-job b/sg-run-job index f6e8340..b324101 100755 --- a/sg-run-job +++

Re: [Xen-devel] [PATCH 07/12] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation

Hi, On 26/10/17 01:37, Stefano Stabellini wrote: > On Thu, 19 Oct 2017, Andre Przywara wrote: >> Currently gic.c holds code to handle hardware IRQs as well as code to >> bridge VGIC requests to the GIC virtualization hardware. > > That is true, however, I don't necessarely see "the code to

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

flight 116876 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116876/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643

[Xen-devel] [OSSTEST RFC 09/16] CentOS: Setup osstest-confirm-booted.service

This emulate the osstest-confirm-booted service that is done on Debian. In order to have the service been started last: - it is made dependent on multi-user.target which is the default target on systemd. - it is part of osstest.target which depend on multi-user.target. - the osstest.target is

Re: [Xen-devel] [PATCH] mm: don't use domain_shutdown() when re-offlining a page

On 06/12/17 16:20, Jan Beulich wrote: > It goes all silent, leaving open what has actually caused the crash. > Use domain_crash() instead, which leaves a log message before calling > domain_shutdown(..., SHUTDOWN_crash). > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [Xen-devel] [PATCH] pdx: correct indentation

On 06/12/17 16:19, Jan Beulich wrote: > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [PATCH 0/2] x86: further GS base handling changes

1: improve MSR_SHADOW_GS accesses 2: rename DIRTY_GS_BASE_USER Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/2] x86: improve MSR_SHADOW_GS accesses

Instead of using RDMSR/WRMSR, on fsgsbase-capable systems use a double SWAPGS combined with RDGSBASE/WRGSBASE. This halves execution time for a shadow GS update alone on my Haswell (and we have indications of good performance improvements by this on Skylake too), while the win is even higher when

[Xen-devel] [PATCH 2/2] x86: rename DIRTY_GS_BASE_USER

As of commit 91f85280b9 ("x86: fix GS-base-dirty determination") the USER part of it isn't really appropriate anymore. Signed-off-by: Jan Beulich --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1276,7 +1276,7 @@ static DEFINE_PER_CPU(unsigned int, dirt #define

Re: [Xen-devel] [PATCH 2/2] xen/pvcalls: Fix a check in pvcalls_front_remove()

On 12/05/2017 01:29 PM, Stefano Stabellini wrote: > On Tue, 5 Dec 2017, Dan Carpenter wrote: >> bedata->ref can't be less than zero because it's unsigned. This affects >> certain error paths in probe. We first set ->ref = -1 and then we set >> it to a valid value later. >> >> Fixes: 219681909913

Re: [Xen-devel] [PATCH] xenmem_add_to_physmap_one() has no need to know of XENMAPSPACE_gmfn_range

On 06/12/17 16:21, Jan Beulich wrote: > As its name says, it handles a single GMFN only anyway. Note that ARM > needs no adjustment, as it doesn't handle the two types at all. > > Also take the opportunity and clean up the handling of XENMAPSPACE_gmfn > a little: There's no point in going through

[Xen-devel] [OSSTEST RFC 08/16] ts-centos-host-install: Install CentOS on a host

Signed-off-by: Anthony PERARD --- ts-centos-host-install | 154 + 1 file changed, 154 insertions(+) create mode 100755 ts-centos-host-install diff --git a/ts-centos-host-install b/ts-centos-host-install new file mode

Re: [Xen-devel] [PATCH v2 06/13] iommu: Add extra use_iommu argument to iommu_domain_init()

Hi Jan. On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich wrote: On 25.07.17 at 19:26, wrote: >> The presence of this flag lets us know that the guest domain has statically >> assigned devices which will most likely be used for passthrough >> and as the

[Xen-devel] [PATCH 1/2] x86/vmx: Don't use hvm_inject_hw_exception() in long_mode_do_msr_write()

Since c/s 49de10f3c1718 "x86/hvm: Don't raise #GP behind the emulators back for MSR accesses", returnning X86EMUL_EXCEPTION has pushed the exception generation to the top of the call tree. Using hvm_inject_hw_exception() and returning X86EMUL_EXCEPTION causes a double #GP injection, which

[Xen-devel] [PATCH 2/2] x86/vmx: Drop enum handler_return

They are straight aliases of the more common X86EMUL_* constants. While adjusting these, fix the case indentation where appropriate. No functional change, confirmed by diff'ing the compiled binary. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

Re: [Xen-devel] [PATCH] xen-netback: Fix logging message with spurious period after newline

From: Joe Perches Date: Tue, 5 Dec 2017 22:40:25 -0800 > Using a period after a newline causes bad output. > > Signed-off-by: Joe Perches Applied. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

On Wed, Dec 6, 2017 at 12:26 AM, Stefano Stabellini wrote: > Hi Oleksandr, Hi Stefano > > I just wanted to tell you that the patch series is very well organized > and the patches very nicely split. Nice to hear. Thank you. > > Thank you! > > - Stefano > > > On Thu, 9 Nov

Re: [Xen-devel] [for-4.10] Re: [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

On 06/12/17 10:53, Julien Grall wrote: > Hi Juergen, > > On 12/05/2017 04:19 PM, Juergen Gross wrote: >> On 05/12/17 16:23, Julien Grall wrote: >>> Hi Juergen, >>> >>> On 04/12/17 15:49, Juergen Gross wrote: On 21/11/17 12:06, Juergen Gross wrote: > The "special pages" for PVH guests

Re: [Xen-devel] [for-4.10] Re: [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

On Wed, Dec 06, 2017 at 12:22:00PM +0100, Juergen Gross wrote: > On 06/12/17 10:53, Julien Grall wrote: > > Hi Juergen, > > > > On 12/05/2017 04:19 PM, Juergen Gross wrote: > >> On 05/12/17 16:23, Julien Grall wrote: > >>> Hi Juergen, > >>> > >>> On 04/12/17 15:49, Juergen Gross wrote: > On

[Xen-devel] Xen Security Advisory 238 (CVE-2017-15591) - DMOP map/unmap missing argument checks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15591 / XSA-238 version 3 DMOP map/unmap missing argument checks UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION =

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

flight 116882 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116882/ 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 are

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

On 11/15/2017 04:46 PM, Julien Grall wrote: > Hi, > > On 11/15/2017 11:29 AM, osstest service owner wrote: >> flight 116178 xen-unstable real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/116178/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

>>> On 06.12.17 at 10:47, wrote: > I guess I have been CCed because you would like this patch is fixing the > regression you mentioned on IRC? Yes, but first of all we need to see whether the issue goes away in master once the patch is in. Jan

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

On 12/06/2017 11:45 AM, Jan Beulich wrote: On 06.12.17 at 10:47, wrote: I guess I have been CCed because you would like this patch is fixing the regression you mentioned on IRC? Yes, but first of all we need to see whether the issue goes away in master once the

Re: [Xen-devel] [for-4.10] Re: [PATCH v2] tools/libxl: mark special pages as reserved in e820 map for PVH

Hi, On 12/06/2017 11:47 AM, Roger Pau Monné wrote: On Wed, Dec 06, 2017 at 12:22:00PM +0100, Juergen Gross wrote: On 06/12/17 10:53, Julien Grall wrote: Hi Juergen, On 12/05/2017 04:19 PM, Juergen Gross wrote: On 05/12/17 16:23, Julien Grall wrote: Hi Juergen, On 04/12/17 15:49, Juergen

Re: [Xen-devel] [RFC v3 4/4] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

Hi Sameer, On 12/05/2017 11:26 PM, Goel, Sameer wrote: On 12/5/2017 7:17 AM, Julien Grall wrote: On 05/12/17 03:59, Sameer Goel wrote: + * tables are shared + */ + +    cfg->vmid    = vmid; +    cfg->vttbr    = page_to_maddr(cfg->domain->arch.p2m.root); +    cfg->vtcr    =

Re: [Xen-devel] [RFC PATCH 22/31] xen/arm: Add Xen changes to SCPI protocol

Hi Julien, Stefano On Tue, Dec 5, 2017 at 11:41 PM, Julien Grall wrote: > > > On 05/12/2017 21:20, Stefano Stabellini wrote: >> >> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote: >>> >>> From: Oleksandr Tyshchenko >>> >>> Modify the direct

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

flight 116891 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116891/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116832 test-armhf-armhf-libvirt 14

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

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

Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator

Hi, Answering to myself. On 12/04/2017 02:30 PM, Julien Grall wrote: On 01/12/17 22:58, Stefano Stabellini wrote: On Mon, 27 Nov 2017, Volodymyr Babchuk wrote: = Xen command forwarding = In the code below, it looks like Xen is forwarding everything to OP-TEE. Are there some commands Xen

Re: [Xen-devel] [PATCH v2 06/13] iommu: Add extra use_iommu argument to iommu_domain_init()

Hi, On 12/06/2017 07:53 PM, Oleksandr Tyshchenko wrote: On Wed, Dec 6, 2017 at 6:51 PM, Jan Beulich wrote: On 25.07.17 at 19:26, wrote: The presence of this flag lets us know that the guest domain has statically assigned devices which will most likely

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

Hi Jan, On 12/06/2017 09:15 AM, Jan Beulich wrote: On 05.12.17 at 19:39, wrote: The suggested policy is based on the KVM one: - If we trap a S/W instructions, we enable VM trapping (e.g HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean.

Re: [Xen-devel] [PATCH] arm64/xen: Add missing #address-cells and #size-cells properties

On Thu, Nov 30, 2017 at 10:22:57PM +0100, Daniel Kiper wrote: [...] > Understood! I will apply this patch next week. Pushed! Thanks, Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH for-next 06/16] xen/arm: Extend copy_to_guest to support copying from/to guest physical address

Hi Stefano, On 12/06/2017 01:22 AM, Stefano Stabellini wrote: On Thu, 23 Nov 2017, Julien Grall wrote: The only differences between copy_to_guest and access_guest_memory_by_ipa are: - The latter does not support copying data crossing page boundary - The former is copying from/to

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 12/05/2017 06:39 PM, Julien Grall wrote: > Hi all, > > Even though it is an Arm failure, I have CCed x86 folks to get feedback > on the approach. I have a WIP branch I could share if that interest people. > > Few months ago, we noticed an heisenbug on jobs run by osstest on the > cubietrucks

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 12/06/2017 12:58 PM, Julien Grall wrote: Hi George, On 12/06/2017 12:28 PM, George Dunlap wrote: On 12/05/2017 06:39 PM, Julien Grall wrote: Hi all, Even though it is an Arm failure, I have CCed x86 folks to get feedback on the approach. I have a WIP branch I could share if that

Re: [Xen-devel] [PATCH for-next 07/16] xen/arm: Introduce copy_to_guest_phys_flush_dcache

Hi Stefano, On 12/06/2017 01:26 AM, Stefano Stabellini wrote: On Thu, 23 Nov 2017, Julien Grall wrote: Hi Andrew, On 23/11/17 18:49, Andrew Cooper wrote: On 23/11/17 18:32, Julien Grall wrote: This new function will be used in a follow-up patch to copy data to the guest using the IPA (aka

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

>>> On 06.12.17 at 12:47, wrote: > On 12/06/2017 11:45 AM, Jan Beulich wrote: > On 06.12.17 at 10:47, wrote: >>> I guess I have been CCed because you would like this patch is fixing the >>> regression you mentioned on IRC? >> >> Yes, but

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

Hi George, On 12/06/2017 12:28 PM, George Dunlap wrote: On 12/05/2017 06:39 PM, Julien Grall wrote: Hi all, Even though it is an Arm failure, I have CCed x86 folks to get feedback on the approach. I have a WIP branch I could share if that interest people. Few months ago, we noticed an

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

Hi Jan, On 12/06/2017 12:58 PM, Jan Beulich wrote: On 06.12.17 at 12:47, wrote: On 12/06/2017 11:45 AM, Jan Beulich wrote: On 06.12.17 at 10:47, wrote: I guess I have been CCed because you would like this patch is fixing the regression you

[Xen-devel] [PATCH] xen/arm: gic-v3: Bail out if gicv3_cpu_init fail

From: Julien Grall When system registers are not enabled, all the access to them will trap in EL2. In Xen, system registers will be enabled by gicv3_cpu_init only on success. As the rest of the code (e.g gicv3_hyp_init) relies on system register, it is better to bail out

Re: [Xen-devel] [RFC Patch v4 1/8] ioreq: remove most 'buf' parameter from static functions

> -Original Message- > From: Chao Gao [mailto:chao@intel.com] > Sent: 06 December 2017 07:50 > To: xen-de...@lists.xen.org > Cc: Chao Gao ; Andrew Cooper > ; Jan Beulich ; Paul > Durrant >

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

.snip.. > The suggested policy is based on the KVM one: > - If we trap a S/W instructions, we enable VM trapping (e.g > HCR_EL2.TVM) to > detect cache being turned on/off, and do a full clean. > - We flush the caches on both caches being turned on and off. > - Once the caches

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

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

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

>>> On 06.12.17 at 13:58, wrote: > On 12/06/2017 12:28 PM, George Dunlap wrote: >> 2. It sounds like rather than using PoD, you could use the >> "misconfigured p2m table" technique that x86 uses: set bits in the p2m >> entry which cause a specific kind of HAP fault when

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

Hi Konrad, On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote: .snip.. The suggested policy is based on the KVM one: - If we trap a S/W instructions, we enable VM trapping (e.g HCR_EL2.TVM) to detect cache being turned on/off, and do a full clean. - We flush the caches on

Re: [Xen-devel] [RFC Patch v4 2/8] ioreq: bump the number of IOREQ page to 4 pages

> -Original Message- > From: Chao Gao [mailto:chao@intel.com] > Sent: 06 December 2017 07:50 > To: xen-de...@lists.xen.org > Cc: Chao Gao ; Paul Durrant > ; Tim (Xen.org) ; Stefano Stabellini > ; Konrad

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 12/06/2017 03:19 PM, Julien Grall wrote: > Hi Konrad, > > On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote: >> .snip.. >>> The suggested policy is based on the KVM one: >>> - If we trap a S/W instructions, we enable VM trapping (e.g >>> HCR_EL2.TVM) to >>> detect cache being turned

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

flight 116890 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/116890/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm broken in 116862 build-armhf-xsm 5

Re: [Xen-devel] [RFC] xen/arm: Handling cache maintenance instructions by set/way

On 12/06/2017 03:24 PM, George Dunlap wrote: On 12/06/2017 03:19 PM, Julien Grall wrote: Hi Konrad, On 12/06/2017 03:10 PM, Konrad Rzeszutek Wilk wrote: .snip.. The suggested policy is based on the KVM one: - If we trap a S/W instructions, we enable VM trapping (e.g HCR_EL2.TVM) to

Re: [Xen-devel] [PATCH] x86/HVM: don't retain emulated insn cache when exiting back to guest

On 06/12/17 13:04, Julien Grall wrote: > Hi Jan, > > On 12/06/2017 12:58 PM, Jan Beulich wrote: > On 06.12.17 at 12:47, wrote: >>> On 12/06/2017 11:45 AM, Jan Beulich wrote: >>> On 06.12.17 at 10:47, wrote: > I guess I have been CCed

[Xen-devel] [PATCH] domctl: improve locking during domain destruction

There is no need to hold the global domctl lock across domain_kill() - the domain lock is fully sufficient here, and parallel cleanup after multiple domains performs quite a bit better this way. Signed-off-by: Jan Beulich --- Changes since RFC: Comment added. --- Obviously

Re: [Xen-devel] [RFC Patch v4 1/8] ioreq: remove most 'buf' parameter from static functions

On Wed, Dec 06, 2017 at 02:44:52PM +, Paul Durrant wrote: >> -Original Message- >> From: Chao Gao [mailto:chao@intel.com] >> Sent: 06 December 2017 07:50 >> To: xen-de...@lists.xen.org >> Cc: Chao Gao ; Andrew Cooper >> ; Jan Beulich