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

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

[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict testid debian-hvm-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

Re: [Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen

On Mon, 12 Nov 2018, Julien Grall wrote: > Hi Mirela, > > Thank you for posting the series. Could you provide a branch with the patch > applied? > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > > > > > The

[Xen-devel] [ovmf test] 129918: regressions - FAIL

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

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

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

Re: [Xen-devel] [PATCH 05/18] xen/arm: Trigger Xen suspend when Dom0 completes suspend

On Mon, 12 Nov 2018, Julien Grall wrote: > Hi, > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > When Dom0 finalizes its suspend procedure the suspend of Xen is > > triggered by calling system_suspend(). Dom0 finalizes the suspend from > > its boot core (VCPU#0), which could be mapped to any

[Xen-devel] [ovmf test] 129891: regressions - FAIL

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

Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)

On Mon, 12 Nov 2018, Andrew Cooper wrote: > On 12/11/18 16:35, Mirela Simonovic wrote: > > Hi Julien, > > > > Thanks for your feedback, I'll need to answer in iterations. > > > > On Mon, Nov 12, 2018 at 4:27 PM Julien Grall wrote: > >> Hi Mirela, > >> > >> On 11/12/18 11:30 AM, Mirela Simonovic

[Xen-devel] [ovmf test] 129902: regressions - FAIL

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

[Xen-devel] [ovmf test] 129912: regressions - FAIL

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

Re: [Xen-devel] [PATCH 15/18] xen/arm: Resume memory management on Xen resume

On Mon, 12 Nov 2018, Julien Grall wrote: > Hi, > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > The MMU needs to be enabled in the resume flow before the context > > can be restored (we need to be able to access the context data by > > virtual address in order to restore it). The

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

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

[Xen-devel] [ovmf test] 129856: regressions - FAIL

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

Re: [Xen-devel] [RFC 09/16] xen/arm: p2m: Introduce a function to resolve translation fault

On Mon, 12 Nov 2018, Julien Grall wrote: > Hi Stefano, > > On 11/6/18 2:20 PM, Julien Grall wrote: > > On 05/11/2018 17:56, Stefano Stabellini wrote: > > > On Mon, 5 Nov 2018, Julien Grall wrote: > > > > On 02/11/2018 23:27, Stefano Stabellini wrote: > > > > > On Mon, 8 Oct 2018, Julien Grall

[Xen-devel] [linux-4.4 test] 129761: regressions - FAIL

flight 129761 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/129761/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail REGR. vs. 129159 Tests which did not

[Xen-devel] [ovmf test] 129905: regressions - FAIL

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

[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-examine

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-examine testid reboot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git

[Xen-devel] [xen-unstable-smoke bisection] complete build-amd64

branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-amd64 testid xen-build Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in

Re: [Xen-devel] [PATCH] xen/pt: fix some pass-thru devices don't work across reboot

>>> On 12.11.18 at 05:58, wrote: > On Fri, Nov 09, 2018 at 02:14:04AM -0700, Jan Beulich wrote: > On 09.11.18 at 01:11, wrote: >>> I find some pass-thru devices don't work any more across guest >>> reboot. Assigning it to another domain also meets the same issue. And >>> the only way to make

Re: [Xen-devel] [PATCH] x86/hvm: Unify hvm_event_pending()'s API with the !CONFIG_HVM version

On 12/11/2018 09:57, Jan Beulich wrote: On 09.11.18 at 15:42, wrote: >> No functional change. > So I understand that "unify" means converting the return type to > bool. You could have said so. Perhaps, but that misses the point of making the change. The patch introducing the !CONFIG_HVM

[Xen-devel] [ovmf test] 129824: regressions - FAIL

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

Re: [Xen-devel] [PATCH] x86/badpage: Fix badpage->order overflow

>>> On 09.11.18 at 15:42, wrote: > For order 32 or more, the shift will truncate. Spotted by Coverity. I find this pretty absurd. What about order 64 or more? Are you suggesting you expect 16Tb or larger bad page ranges? > Signed-off-by: Andrew Cooper Anyway, as I don't mind the adjustment

Re: [Xen-devel] [PATCH 3/3 Xen-4.8] x86/dom0: Fix shadowing of PV guests with 2M superpages

>>> On 09.11.18 at 16:26, wrote: > This is a minimal backport of pieces of: > > c/s 28d9a9a2d41759b9e5163037b759ac557aea767c > c/s 4c5d78a10dc89427140a50a1df5a0b8e9f073e82 > > to fix a PV shadowing problem which I hadn't anticipated at the time these > fixes were first accepted. > > Having

[Xen-devel] [distros-debian-sid test] 75589: tolerable FAIL

flight 75589 distros-debian-sid real [real] http://osstest.xensource.com/osstest/logs/75589/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 75571

[Xen-devel] [ovmf test] 129832: regressions - FAIL

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

Re: [Xen-devel] [PATCH 2/2] guest/pvh: special case the low 1MB

>>> On 09.11.18 at 18:22, wrote: > When running as a PVH guest Xen only special cases the trampoline > code in the low 1MB, without also reserving the space used by the > relocated metadata or the trampoline stack. > > Fix this by always reserving the low 1MB regardless of whether Xen is >

Re: [Xen-devel] [PATCH v5 03/13] x86: infrastructure to allow converting certain indirect calls to direct ones

>>> On 08.11.18 at 17:08, wrote: > --- a/xen/include/xen/lib.h > +++ b/xen/include/xen/lib.h > @@ -66,6 +66,10 @@ > > #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1)) > > +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x > +#define count_va_arg(args...) \ > +

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

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

Re: [Xen-devel] [PATCH] x86/hvm: Unify hvm_event_pending()'s API with the !CONFIG_HVM version

>>> On 09.11.18 at 15:42, wrote: > No functional change. So I understand that "unify" means converting the return type to bool. You could have said so. > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 1/3] x86/dom0: Avoid using 1G superpages if shadowing may be necessary

>>> On 09.11.18 at 16:26, wrote: > The shadow code doesn't support 1G superpages, and will hand #PF[RSVD] back to > guests. So this change is then instead of trying to make shadow code cope? > --- a/xen/arch/x86/pv/dom0_build.c > +++ b/xen/arch/x86/pv/dom0_build.c > @@ -148,7 +148,14 @@ static

Re: [Xen-devel] [PATCH 2/3 Xen-4.9] x86/dom0: Fix shadowing of PV guests with 2M superpages

>>> On 09.11.18 at 16:26, wrote: > This is a straight backport of c/s 28d9a9a2d41759b9e5163037b759ac557aea767c > but with a different justification. > > Dom0 may have superpages (e.g. initial P2M), and may be shadowed > (e.g. PV-L1TF). Because of this incorrect check, when PV superpages are >

Re: [Xen-devel] [PATCH 6/6] x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid()

>>> On 09.11.18 at 18:16, wrote: > On 06/11/18 16:16, Jan Beulich wrote: > On 06.11.18 at 16:52, wrote: >>> On 06/11/18 15:38, Jan Beulich wrote: >>> On 05.11.18 at 12:21, wrote: > They are identical, so provide a single x86emul_cpuid() instead. > > As x86_emulate() now only

Re: [Xen-devel] [PATCH 1/3] x86/dom0: Avoid using 1G superpages if shadowing may be necessary

On 12/11/2018 10:05, Jan Beulich wrote: On 09.11.18 at 16:26, wrote: >> The shadow code doesn't support 1G superpages, and will hand #PF[RSVD] back >> to >> guests. > So this change is then instead of trying to make shadow code cope? At the moment, that is an unknown quantity of work. 

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

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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemuu-rhel6hvm-amd

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemuu-rhel6hvm-amd testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [ovmf test] 129928: regressions - FAIL

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

[Xen-devel] [ovmf test] 129923: regressions - FAIL

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

[Xen-devel] [linux-4.14 test] 129762: tolerable FAIL - PUSHED

flight 129762 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/129762/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 6 xen-install fail like 129492 test-amd64-amd64-libvirt 13

[Xen-devel] [PATCH 06/18] xen/x86: Move freeze/thaw_domains into common files

These functions will be reused by suspend/resume support for ARM. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi --- xen/arch/x86/acpi/power.c | 28 xen/common/domain.c | 29 + xen/include/xen/sched.h | 3 +++ 3

[Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen

This series contains support for suspend to RAM (in the following text just 'suspend') for Xen on arm64. The implementation is aligned with the design specification that has been proposed on xen-devel list: https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01574.html At a high-level

[Xen-devel] [PATCH 08/18] xen/arm: Disable/enable non-boot physical CPUs on suspend/resume

Non-boot CPUs have to be disabled on suspend and enabled on resume (hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI CPU_OFF to be called by each non-boot CPU. Depending on the underlying platform capabilities, this may lead to the physical powering down of CPUs. Tested on

[Xen-devel] [PATCH 01/18] xen/arm: Move code that initializes VCPU context into a separate function

From: Saeed Nowshadi The arch_set_info_guest() has code to initialize the context of a VCPU. When a VCPU is resumed it needs to go through the same context initialization excluding all the validations that this routine does. We move the actual VCPU context setting into a function so that it can

[Xen-devel] [PATCH 16/18] xen/arm: Save/restore context on suspend/resume

The context of CPU general purpose and system control registers has to be saved on suspend and restored on resume. This is implemented in hyp_suspend and before the return from hyp_resume function. The hyp_suspend is invoked just before the PSCI system suspend call is issued to the ATF. The

[Xen-devel] [PATCH 18/18] xen/arm: Suspend/resume console on Xen suspend/resume

This is done using generic console_suspend/resume functions that cause uart driver specific suspend/resume handlers to be called for each initialized port (if the port has suspend/resume driver handlers implemented). Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi ---

[Xen-devel] [PATCH 13/18] xen/arm: Implement PSCI SYSTEM_SUSPEND call (physical interface)

PSCI system suspend function shall be invoked to finalize Xen suspend procedure. Resume entry point, which needs to be passed via 1st argument of PSCI system suspend call to the EL3, is hyp_resume. For now, hyp_resume is just a placeholder that will be implemented in assembly. Context ID, which is

[Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)

The implementation consists of: -Adding PSCI system suspend call as new PSCI function -Trapping PSCI system_suspend HVC -Implementing PSCI system suspend call (virtual interface that allows guests to suspend themselves) The PSCI system suspend should be called by a guest from its boot VCPU.

[Xen-devel] [PATCH 07/18] xen/arm: Freeze domains on suspend and thaw them on resume

Freeze and thaw of domains is reused as implemented for x86. In addition, system_state variable is updated to represent the actual state of the system. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi --- xen/arch/arm/suspend.c | 8 1 file changed, 8 insertions(+) diff

[Xen-devel] [PATCH 09/18] xen/arm: Add rcu_barrier() before enabling non-boot CPUs on resume

The rcu_barrier() has to be added to ensure that the per cpu area is freed before a non-boot CPU tries to initialize it (_free_percpu_area() has to be called before the init_percpu_area()). This scenario occurs when non-boot CPUs are hot-unplugged on suspend and hotplugged on resume.

[Xen-devel] [PATCH 14/18] xen/arm: Convert setting MMU page tables code into a routine

From: Saeed Nowshadi The code that sets up MMU page tables during the boot is also needed when the system resumes. Convert that code in head.S into a routine so the resume code can use it as well. This patch does not include any functional change. Signed-off-by: Saeed Nowshadi Signed-off-by:

[Xen-devel] [PATCH 15/18] xen/arm: Resume memory management on Xen resume

The MMU needs to be enabled in the resume flow before the context can be restored (we need to be able to access the context data by virtual address in order to restore it). The configuration of system registers prior to branching to the routine that sets up the page tables is copied from

[Xen-devel] [PATCH 17/18] xen/arm: Resume Dom0 after Xen resumes

The resume of Dom0 should always follow Xen's resume. This is done by unblocking the first vCPU of Dom0. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi --- xen/arch/arm/suspend.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/arm/suspend.c

[Xen-devel] [PATCH 04/18] xen/arm: While a domain is suspended put its watchdogs on pause

While a domain is suspended its watchdogs must be paused. Otherwise, if the domain stays in the suspend state for a longer period of time compared to the watchdog period, the domain would be shutdown on resume. Proper solution to this problem is to stop (suspend) the watchdog timers after the

[Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends

GIC and virtual timer context must be saved when the domain suspends. This is done by moving the respective code in ctxt_switch_from() before the return that happens if the domain suspended. Signed-off-by: Mirela Simonovic Signed-off-by: Saeed Nowshadi --- xen/arch/arm/domain.c | 14

[Xen-devel] [PATCH 11/18] xen/arm: Suspend/resume GIC on system suspend/resume

GIC state is saved on system suspend by calling gic_suspend (this function does not change current state of the GIC but only saves the values of configuration registers). The state of GIC has to be restored by calling gic_resume, but only if the gic_suspend has succeeded. If gic_suspend fails,

[Xen-devel] [PATCH 05/18] xen/arm: Trigger Xen suspend when Dom0 completes suspend

When Dom0 finalizes its suspend procedure the suspend of Xen is triggered by calling system_suspend(). Dom0 finalizes the suspend from its boot core (VCPU#0), which could be mapped to any physical CPU, i.e. the system_suspend() function could be executed by any physical CPU. Since Xen suspend

Re: [Xen-devel] [PATCH 3/5] xen/domain: Audit config->max_vcpus during {, arch_}check_domain_config()

On 12/11/18 11:43, Julien Grall wrote: > Hi, > > On 11/9/18 6:43 PM, Andrew Cooper wrote: >> On 09/10/18 12:23, Julien Grall wrote: >>> On 05/10/2018 15:54, Andrew Cooper wrote: ---    xen/arch/arm/domain.c | 18 ++    xen/arch/x86/domain.c |  6 ++   

Re: [Xen-devel] [PATCH 3/5] xen/domain: Audit config->max_vcpus during {, arch_}check_domain_config()

Hi, On 11/9/18 6:43 PM, Andrew Cooper wrote: On 09/10/18 12:23, Julien Grall wrote: On 05/10/2018 15:54, Andrew Cooper wrote: ---   xen/arch/arm/domain.c | 18 ++   xen/arch/x86/domain.c |  6 ++   xen/common/domain.c   |  3 +++   3 files changed, 27 insertions(+) diff

Re: [Xen-devel] [PATCH 01/18] xen/arm: Move code that initializes VCPU context into a separate function

First thing first, thanks for posting this series. I'm not an ARM maintainer but I do have a few comments. On Mon, Nov 12, 2018 at 12:30:27PM +0100, Mirela Simonovic wrote: > From: Saeed Nowshadi > > The arch_set_info_guest() has code to initialize the context of a VCPU. > When a VCPU is

Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)

What? On Mon, Nov 12, 2018 at 12:42 PM Jan Beulich wrote: > >>> On 12.11.18 at 12:30, wrote: > > --- a/xen/include/xen/sched.h > > +++ b/xen/include/xen/sched.h > > @@ -24,6 +24,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > >

Re: [Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen

Hi Julien, On Mon, Nov 12, 2018 at 12:50 PM Julien Grall wrote: > Hi Mirela, > > Thank you for posting the series. Could you provide a branch with the > patch applied? > > I have applied patches on top of upstream/staging. > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > >

Re: [Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen

On 11/12/18 12:01 PM, Mirela Simonovic wrote: Hi Julien, Hi Mirela, Please configure your e-mail client to avoid quoting using "space". Otherwise, this is going to make difficult to follow the discussions. On Mon, Nov 12, 2018 at 12:50 PM Julien Grall > wrote:

Re: [Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen

Hi Julien, On Mon, Nov 12, 2018 at 1:08 PM Julien Grall wrote: > > On 11/12/18 12:01 PM, Mirela Simonovic wrote: > > Hi Julien, > > Hi Mirela, > > Please configure your e-mail client to avoid quoting using "space". > Otherwise, this is going to make difficult to follow the discussions. > Sure,

Re: [Xen-devel] [PATCH 1/2] guest/pvh: fix handling of multiboot info and module list

>>> On 12.11.18 at 12:49, wrote: > On Mon, Nov 12, 2018 at 03:28:37AM -0700, Jan Beulich wrote: >> >>> On 09.11.18 at 18:22, wrote: >> > for ( i = 0; i < pvh_info->nr_modules; i++ ) >> > { >> > BUG_ON(entry[i].paddr >> 32); >> > BUG_ON(entry[i].cmdline_paddr >> 32);

Re: [Xen-devel] [PATCH v7 5/7] iommu / vtd: introduce a new 'refcount' flag...

>>> On 15.10.18 at 12:35, wrote: > ...to mean 'the page (being) mapped is reference counted'. > > An important pre-requisite for PV-IOMMU mapping is being able to tell the > difference between IOMMU entries added at start-of-day by Xen and those > that have been added by a PV-IOMMU map

Re: [Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen

Hi, One thing I screwed - I forgot to remove changes log from an internal review, so please ignore it. This is officially the first version. Thanks, Mirela On Mon, Nov 12, 2018 at 12:31 PM Mirela Simonovic < mirela.simono...@aggios.com> wrote: > This series contains support for suspend to RAM

Re: [Xen-devel] [PATCH] libxl/depriv: Remove RLIMIT_NPROC restriction

On 11/12/18 11:26 AM, Ian Jackson wrote: > George Dunlap writes ("[PATCH] libxl/depriv: Remove RLIMIT_NPROC > restriction"): >> This also prevents QEMU from creating ptreads, which it requires for >> certain devices to function. > > Acked-by: Ian Jackson > > To unblock staging. > > We should

Re: [Xen-devel] x86 Community Call: Nov 14 - 15:00 - 16:00 UTC - Call for Agenda Items

On Thu, Nov 8, 2018, 7:37 AM Daniel Kiper On Wed, Nov 07, 2018 at 04:15:17PM +0100, Juergen Gross wrote: > > On 07/11/2018 16:06, Daniel Kiper wrote: > > > On Wed, Nov 07, 2018 at 11:49:38AM +0100, Daniel Kiper wrote: > > >> On Tue, Nov 06, 2018 at 09:54:54AM -0700, Jan Beulich wrote: > > >>

[Xen-devel] [PATCH 10/18] xen/arm: Implement GIC suspend/resume functions (gicv2 only)

System suspend may lead to a state where GIC would be powered down. Therefore, Xen should save/restore the context of GIC on suspend/resume. Note that the context consists of states of registers which are controlled by the hypervisor. Other GIC registers which are accessible by guests are

[Xen-devel] [PATCH 12/18] xen/arm: Suspend/resume timer interrupt generation

Timer interrupts have to be disabled while the system is in suspend. Otherwise, a timer interrupt would fire and wake-up the system. Suspending the timer interrupts consists of disabling physical EL1 and EL2 timers. The resume consists only of raising timer softirq, which will trigger the generic

Re: [Xen-devel] [PATCH v5 11/13] IOMMU: move inclusion point of asm/iommu.h

Hi Jan, On 11/8/18 4:14 PM, Jan Beulich wrote: In preparation of allowing inline functions in asm/iommu.h to de-reference struct struct iommu_ops, move the inclusion downwards past the declaration of that structure. This in turn requires moving the struct domain_iommu declaration, as it

[Xen-devel] [PATCH] libxl/depriv: Remove RLIMIT_NPROC restriction

This also prevents QEMU from creating ptreads, which it requires for certain devices to function. Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Wei Liu CC: Anthony Perard --- docs/designs/qemu-deprivilege.md | 4 +++- tools/libxl/libxl_linux.c| 1 - 2 files changed, 3

Re: [Xen-devel] [PATCH 01/18] xen/arm: Move code that initializes VCPU context into a separate function

>>> On 12.11.18 at 12:30, wrote: > --- a/xen/include/xen/domain.h > +++ b/xen/include/xen/domain.h > @@ -73,6 +73,7 @@ int arch_domain_soft_reset(struct domain *d); > void arch_p2m_set_access_required(struct domain *d, bool access_required); > > int arch_set_info_guest(struct vcpu *,

Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)

>>> On 12.11.18 at 12:30, wrote: > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > #include > #include > #include Why? Jan. ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 04/18] xen/arm: While a domain is suspended put its watchdogs on pause

>>> On 12.11.18 at 12:30, wrote: > --- a/xen/include/xen/timer.h > +++ b/xen/include/xen/timer.h > @@ -18,6 +18,9 @@ struct timer { > /* System time expiry value (nanoseconds since boot). */ > s_time_t expires; > > +/* Suspend timestamp value (nanoseconds since boot). */ > +

Re: [Xen-devel] [PATCH 4/4] xen/arm: gic: Relax barrier when sending an SGI

Hi Stefano, On 11/9/18 11:14 PM, Stefano Stabellini wrote: On Tue, 23 Oct 2018, Julien Grall wrote: When sending an SGI to another CPU, we require a barrier to ensure that any pending stores to normal memory are made visible to the recipient before the interrupt arrives. For GICv2, rather

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

flight 129760 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/129760/ 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. 128858

Re: [Xen-devel] [PATCH 01/18] xen/arm: Move code that initializes VCPU context into a separate function

Hi Mirela, On 11/12/18 11:30 AM, Mirela Simonovic wrote: From: Saeed Nowshadi The arch_set_info_guest() has code to initialize the context of a VCPU. When a VCPU is resumed it needs to go through the same context initialization excluding all the validations that this routine does. We move the

Re: [Xen-devel] [PATCH v7 4/7] iommu: introduce iommu_map_page_nocrash

>>> On 15.10.18 at 12:35, wrote: > --- a/xen/drivers/passthrough/iommu.c > +++ b/xen/drivers/passthrough/iommu.c > @@ -313,16 +313,23 @@ void iommu_domain_destroy(struct domain *d) > hd->reserved_ranges = NULL; > } > > -int iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn, > -

Re: [Xen-devel] [PATCH v2 11/11] tools/libvchan: libxenvchan_client_init: use ENOENT for no server

Marek Marczykowski-Górecki writes ("Re: [Xen-devel] [PATCH v2 11/11] tools/libvchan: libxenvchan_client_init: use ENOENT for no server"): > Since xtl_log now accepts NULL, it should be fine. Thanks! > Reviewed-by: Marek Marczykowski-Górecki Thanks. I am reluctant to commit this series without

Re: [Xen-devel] [PATCH] libxl/depriv: Remove RLIMIT_NPROC restriction

On Mon, Nov 12, 2018 at 11:24:54AM +, George Dunlap wrote: > This also prevents QEMU from creating ptreads, which it requires for ptreads -> pthreads > certain devices to function. > > Signed-off-by: George Dunlap Acked-by: Wei Liu ___

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

flight 129836 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129836/ 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 v3 4/4] xen: use SYMBOL everywhere

Hi Stefano, On 11/8/18 10:27 PM, Stefano Stabellini wrote: On Thu, 8 Nov 2018, Jan Beulich wrote: On 06.11.18 at 23:05, wrote: Use SYMBOL everywhere _stext, _etext, etc. are used. Technically, it is required when comparing and subtracting pointers [1], but use it everywhere to avoid

Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)

>>> On 12.11.18 at 12:50, wrote: > What? Please don't top post. > On Mon, Nov 12, 2018 at 12:42 PM Jan Beulich wrote: > >> >>> On 12.11.18 at 12:30, wrote: >> > --- a/xen/include/xen/sched.h >> > +++ b/xen/include/xen/sched.h >> > @@ -24,6 +24,7 @@ >> > #include >> > #include >> >

[Xen-devel] [PATCH] x86: fix hvm_migrate_irq assertion

782cf8ba46 ("pass-through: adjust pIRQ migration") added an assertion to hvm_migrate_irq. PVH Dom0 is broken because it doesn't have dpci allocated. Add an is_hardware_domain check to the assertion. Signed-off-by: Wei Liu --- xen/arch/x86/hvm/hvm.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [Xen-devel] [PATCH] libxl/depriv: Remove RLIMIT_NPROC restriction

George Dunlap writes ("[PATCH] libxl/depriv: Remove RLIMIT_NPROC restriction"): > This also prevents QEMU from creating ptreads, which it requires for > certain devices to function. Acked-by: Ian Jackson To unblock staging. We should consider whether we can impose a smaller limit and if so

Re: [Xen-devel] [PATCH 1/2] guest/pvh: fix handling of multiboot info and module list

On Mon, Nov 12, 2018 at 03:28:37AM -0700, Jan Beulich wrote: > >>> On 09.11.18 at 18:22, wrote: > > When booting Xen as a PVH guest the data in the PVH start info > > structure is copied over to a multiboot structure and a module list > > array that resides in the .init section of the Xen image.

Re: [Xen-devel] [PATCH 00/18] xen/arm64: Suspend to RAM support for Xen

Hi Mirela, Thank you for posting the series. Could you provide a branch with the patch applied? On 11/12/18 11:30 AM, Mirela Simonovic wrote: The series does not include: a) UART driver-specific suspend/resume

Re: [Xen-devel] Problems building and running Xen on Hikey960

On 11/11/18 1:15 AM, Matthew Daley wrote: Hi Julien, Hi Matthew, On Sat, 10 Nov 2018 at 00:22, Julien Grall wrote: Firstly, Xen fails to bring up any other CPUs but the one it is booting on: (XEN) Bringing up CPU1 (XEN) Failed to bring up CPU1 (XEN) Failed to bring up CPU 1 (error -9)

[Xen-devel] [ovmf test] 129838: regressions - FAIL

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

Re: [Xen-devel] [PATCH 1/2] guest/pvh: fix handling of multiboot info and module list

>>> On 12.11.18 at 16:00, wrote: > Yes, it's only the module list that's passed by physical address and > then mapped using __va. How about the following description: > > "When booting Xen as a PVH guest the data in the PVH start info > structure is copied over to a multiboot structure and a

Re: [Xen-devel] [PATCH v5 11/15] libxl_dm: Pre-open QMP socket for QEMU

Anthony PERARD writes ("Re: [PATCH v5 11/15] libxl_dm: Pre-open QMP socket for QEMU"): > On Tue, Oct 16, 2018 at 03:11:03PM +0100, Ian Jackson wrote: > > Anthony PERARD writes ("[PATCH v5 11/15] libxl_dm: Pre-open QMP socket for > > QEMU"): > > > ret = libxl__build_device_model_args(gc,

Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)

Hi Mirela, On 11/12/18 11:30 AM, Mirela Simonovic wrote: The implementation consists of: -Adding PSCI system suspend call as new PSCI function -Trapping PSCI system_suspend HVC -Implementing PSCI system suspend call (virtual interface that allows guests to suspend themselves) The PSCI system

[Xen-devel] [freebsd-master test] 129834: all pass - PUSHED

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

Re: [Xen-devel] [PATCH 15/18] xen/arm: Resume memory management on Xen resume

Hi, On 11/12/18 11:30 AM, Mirela Simonovic wrote: The MMU needs to be enabled in the resume flow before the context can be restored (we need to be able to access the context data by virtual address in order to restore it). The configuration of system registers prior to branching to the routine

Re: [Xen-devel] [PATCH v7 7/7] x86: extend the map and unmap xen_iommu_ops to support grant references

>>> On 15.10.18 at 12:35, wrote: > --- a/xen/common/grant_table.c > +++ b/xen/common/grant_table.c > @@ -3927,6 +3927,157 @@ int gnttab_get_status_frame(struct domain *d, > unsigned long idx, > return rc; > } > > +int > +acquire_gref_for_iommu(struct domain *d, grant_ref_t gref, > +

Re: [Xen-devel] [PATCH] x86: fix hvm_migrate_irq assertion

On Mon, Nov 12, 2018 at 07:35:57AM -0700, Jan Beulich wrote: > >>> On 12.11.18 at 15:04, wrote: > > 782cf8ba46 ("pass-through: adjust pIRQ migration") added an assertion > > to hvm_migrate_irq. > > > > PVH Dom0 is broken because it doesn't have dpci allocated. Add an > > is_hardware_domain check

Re: [Xen-devel] [PATCH 04/18] xen/arm: While a domain is suspended put its watchdogs on pause

Hi Jan, On Mon, Nov 12, 2018 at 12:47 PM Jan Beulich wrote: > > >>> On 12.11.18 at 12:30, wrote: > > --- a/xen/include/xen/timer.h > > +++ b/xen/include/xen/timer.h > > @@ -18,6 +18,9 @@ struct timer { > > /* System time expiry value (nanoseconds since boot). */ > > s_time_t expires;

Re: [Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends

Hi Mirela, On 11/12/18 11:30 AM, Mirela Simonovic wrote: GIC and virtual timer context must be saved when the domain suspends. Please provide the rationale for this. Is it required by the spec? This is done by moving the respective code in ctxt_switch_from() before the return that happens

Re: [Xen-devel] [PATCH 05/18] xen/arm: Trigger Xen suspend when Dom0 completes suspend

Hi, On 11/12/18 11:30 AM, Mirela Simonovic wrote: When Dom0 finalizes its suspend procedure the suspend of Xen is triggered by calling system_suspend(). Dom0 finalizes the suspend from its boot core (VCPU#0), which could be mapped to any physical CPU, i.e. the system_suspend() function could be

Re: [Xen-devel] [PATCH v5 11/15] libxl_dm: Pre-open QMP socket for QEMU

Anthony PERARD writes ("Re: [PATCH v5 11/15] libxl_dm: Pre-open QMP socket for QEMU"): > On Mon, Nov 12, 2018 at 03:14:30PM +, Ian Jackson wrote: > > Yes, it would have to be initialised along with the other members of > > libxl__domain_build_state. > > I didn't manage to findout where this

  1   2   >