Re: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi, Peng! On 04/12/2018 05:21 AM, Peng Fan wrote: Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? They are orthogonal Thanks, Peng. ___ Xen-devel

[Xen-devel] [libvirt test] 122167: regressions - FAIL

flight 122167 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/122167/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 122005

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Edgar, > -Original Message- > From: Edgar E. Iglesias [mailto:edgar.igles...@xilinx.com] > Sent: 2018年3月26日 19:43 > To: Peng Fan > Cc: Mirela Simonovic ; xen-de...@lists.xen.org; > sstabell...@kernel.org; julien.gr...@linaro.org >

Re: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? Thanks, Peng. > Subject: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV > display frontend > > From: Oleksandr Andrushchenko

Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: pcistub_probe() is never called in atomic context. This function is only set as ".probe" in struct pci_driver. Despite never getting called from atomic context, pcistub_probe() calls kmalloc() with GFP_ATOMIC, which does not sleep for allocation.

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes

On Wed, Apr 11, 2018 at 05:10:40PM +, Lars Kurth wrote: >## Longer Term - Agreed to Pause > >### [PATCH v4 00/28] add vIOMMU support with irq remapping function of >### virtual VT-d > >Sent in for meeting agenda by George >v3 posted by Lan Tianyu on 22 September 2017: ​marc.info/?l=xen-devel=

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

flight 122166 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122166/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 121320 Tests

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

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

Re: [Xen-devel] [PATCH 7/7] xen/arm: Restore IRQ affinity after hotplugging a CPU

On Wed, 11 Apr 2018, Mirela Simonovic wrote: > Secondary pCPUs will be offlined on system suspend and hotplugged > on resume. When offlining secondary CPUs all interrupts targeted > to those CPUs will be routed to the boot CPU. The boot CPU > is responsible for finalizing suspend procedure. All

Re: [Xen-devel] [PATCH 5/7] xen/arm: Remove __initdata and __init to enable CPU hotplug

On Wed, 11 Apr 2018, Mirela Simonovic wrote: > CPU up flow is currently used during the initial boot to start secondary > CPUs. However, the same flow should be used for CPU hotplug, e.g. when > hotplugging secondary CPUs within the resume procedure (resume from the > suspend to RAM). Therefore,

Re: [Xen-devel] [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly

On Wed, 11 Apr 2018, Julien Grall wrote: > On 11/04/18 14:19, Mirela Simonovic wrote: > > Freeing percpu area is done when a non-boot CPU is disabled upon suspend. > > This use to be scheduled for execution after a period of time, what caused > > the following racing issues. If CPU is enabled

Re: [Xen-devel] [PATCH 2/7] xen/arm/vgic-v2: Ignore write to GICD_ISACTIVERn registers

On Wed, 11 Apr 2018, Julien Grall wrote: > On 11/04/18 14:19, Mirela Simonovic wrote: > > Guests attempt to write into these registers on resume (for example Linux). > > Without this patch a data abort exception will be raised to the guest. > > This patch handles the write access by ignoring it.

Re: [Xen-devel] [PATCH 1/7] xen/arm: Added handling of the trapped access to OSLSR register

On Wed, 11 Apr 2018, Julien Grall wrote: > Hi, > > You seem to have used a wrong address for me. > > Title: This patch is only adding the arm64 side. Please make it clear in it. With that: Reviewed-by: Stefano Stabellini > Cheers, > > On 04/11/2018 02:19 PM, Mirela

[Xen-devel] [qemu-mainline test] 122165: regressions - trouble: blocked/broken/fail/pass

flight 122165 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122165/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-armhf-pvops 5

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

flight 122164 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122164/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

Il Mer 11 Apr 2018, 22:48 Olaf Hering ha scritto: > On Wed, Apr 11, Dario Faggioli wrote: > > > It will crash, again, possibly with the same stack trace, but I think > > it's worth a try. > > BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc))); > > (XEN) Xen BUG at sched_credit.c:876 >

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Dario Faggioli wrote: > It will crash, again, possibly with the same stack trace, but I think > it's worth a try. BUG_ON(__vcpu_on_runq(CSCHED_VCPU(vc))); (XEN) grant_table.c:1769:d15v18 Expanding d15 grant table from 12 to 13 frames (XEN) grant_table.c:1769:d15v20 Expanding

[Xen-devel] bug in _shadow_prealloc during migration of PV domU

I was testing 'virsh migrate domU host' and did some libvirtd debugging on 'host'. This means the migration was attempted a few times, but did not actually start because libvirtd was in gdb. Not sure if libvirt on the sender does anything with the domU before a connection to the remote host is

[Xen-devel] [PATCH v2 2/2] x86: correct ordering of operations during S3 resume

From: Jan Beulich Microcode loading needs to happen before re-enabling interrupts, in case only updated microcode allows the use of e.g. the SPEC_{CTRL,CMD} MSRs. Otoh it doesn't need to happen at all when we didn't suspend in the first place. It needs to happen before

Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

On Wed, Apr 11, 2018 at 12:39 AM, Razvan Cojocaru wrote: > On 04/09/2018 05:12 PM, George Dunlap wrote: >> The obvious place to look is the logdirtyvram functionality, which is >> used to make it easier for QEMU to figure out which bits of the display >> buffer have

[Xen-devel] [PATCH 2/2] x86: correct ordering of operations during S3 resume

Microcode loading needs to happen before re-enabling interrupts, in case only updated microcode allows the use of e.g. the SPEC_{CTRL,CMD} MSRs. Otoh it doesn't need to happen at all when we didn't suspend in the first place. It needs to happen before spin_debug_enable() though, as it acquires a

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes

On 04/11/2018 08:10 PM, Lars Kurth wrote: > ### [PATCH RFC 00/14] EPT-Based Sub-page Write Protection Support > > ### (​Zhang Yi) > > RFC posted by Zhang Yi Oct 19, 2017 > https://marc.info/?l=xen-devel= > https://xen.markmail.org/thread/m75h6b2aiwk5h7fx > > > No acks, reviews only by

Re: [Xen-devel] [PATCH for-4.11 v2 0/9] Provide support matrix generator

On 11/04/2018, 16:36, "Ian Jackson" wrote: This series provides code to generate a feature support matrix, to replace the one on the wiki. You can see an example of the output here:

[Xen-devel] [distros-debian-squeeze test] 74577: trouble: broken/fail/pass

flight 74577 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74577/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, 2018-04-11 at 17:27 +0200, Olaf Hering wrote: > On Wed, Apr 11, Olaf Hering wrote: > > > That was with sched=credit2, sorry for that. > > Now with just that second patch ... > > Still BUG in csched_load_balance. > > (XEN) Xen BUG at sched_credit.c:1694 > (XEN) [

Re: [Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

Hi Julien, On Wed, Apr 11, 2018 at 6:02 PM, Julien Grall wrote: > Hi, > > On 11/04/18 16:58, Mirela Simonovic wrote: > >> On 04/11/2018 05:07 PM, Julien Grall wrote: >> >>> On 11/04/18 14:19, Mirela Simonovic wrote: >>> >> Migrating interrupts when turning off a CPU

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

Hi Stefano On 06.04.18 23:47, Stefano Stabellini wrote: On Fri, 6 Apr 2018, Artem Mygaiev wrote: 2) Create a subset of functions that need to go through certifications Next step: create a small Kconfig. We could use the Renesas Rcar as reference. We need a discussion about the features we

Re: [Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

Hi, On 11/04/18 16:58, Mirela Simonovic wrote: On 04/11/2018 05:07 PM, Julien Grall wrote: On 11/04/18 14:19, Mirela Simonovic wrote: Migrating interrupts when turning off a CPU already works. However, when a CPU is turned back on there is no interrupt migration back to the hotplugged CPU -

Re: [Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

Hi Julien, Thank you for the feedback. On 04/11/2018 05:07 PM, Julien Grall wrote: Hi Mirela, Thank you for sending the series. On 11/04/18 14:19, Mirela Simonovic wrote: This patch set contains fixes required to enable CPU hotplug for secondary CPUs. CPU hotplug of secondary CPUs will be

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

Am Wed, 11 Apr 2018 09:38:59 -0600 schrieb "Jan Beulich" : > And till now I had assumed we've taken care of them with earlier > fixes (all 4.7 reports were with old packages, like 4.7.2 based > ones). Can you repro this with a debug hypervisor (so we can > both trust the stack

Re: [Xen-devel] [PATCH 3/9] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

George Dunlap writes ("Re: [PATCH 3/9] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section"): > On 04/11/2018 04:35 PM, Ian Jackson wrote: > > I tested feeding the document to markdown(1) on Debian jessie and it > > reproduced the % line as if it were simple text. I guess

Re: [Xen-devel] [PATCH 9/9] docs: Provide support-matrix-generate, to generate a support matrix in HTML

On 11/04/18 17:35, Ian Jackson wrote: > This archaeology script: > - figures out what the current and previous Xen versions were > - looks for appropriate git branches for them > - finds SUPPORT.md for each one > - feeds its findings to parse-support-md > > We do not intend to integrate this

Re: [Xen-devel] [PATCH 8/9] docs: Provide parse-support-md

On 11/04/18 17:35, Ian Jackson wrote: > This utility reads json format pandoc output, from parsing one or more > SUPPORT.md files, and generates an HTML table element containing the > principal version and feature information. > > This is rather hairier than I anticipated when I started out;

[Xen-devel] [PATCH 4/9] docs/gen-html-index: Extract titles from HTML documents

Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- docs/gen-html-index | 13 + 1 file changed, 13 insertions(+) diff --git a/docs/gen-html-index b/docs/gen-html-index index e9792bf..5b43b42 100644 --- a/docs/gen-html-index +++

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

>>> On 11.04.18 at 17:03, wrote: > On Wed, Apr 11, Olaf Hering wrote: > >> On Wed, Apr 11, Dario Faggioli wrote: >> >> > Olaf, can you give it a try? It should be fine to run it on top of the >> > last debug patch (the one that produced this crash). >> >> Yes, with both changes

Re: [Xen-devel] [PATCH 3/9] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

On 04/11/2018 04:35 PM, Ian Jackson wrote: > This commits (more or less) this file to be processed with pandoc, > rather than other markdown processors. There is, unfortunately, no > widely-accepted way to declare a title for the document. > > I tested feeding the document to markdown(1) on

[Xen-devel] [PATCH 1/9] SUPPORT.md: Syntax: Fix some bullet lists

Continuations of bullet list items must be indented by exactly 4 spaces (according to pandoc_markdown(5) on Debian jessie). This is most easily achieved by making the bullet list items have two spaces before the `*'. Signed-off-by: Ian Jackson Release-acked-by:

[Xen-devel] [PATCH for-4.11 v2 0/9] Provide support matrix generator

This series provides code to generate a feature support matrix, to replace the one on the wiki. You can see an example of the output here: http://xenbits.xen.org/people/iwj/2018/support-matrix-example-v2/t.html There is also an accompanying SUPPORT.html to make the links for 4.11 work. Patches

[Xen-devel] [PATCH 7/9] docs/Makefile: Format SUPPORT.md into the toplevel

Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- docs/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/Makefile b/docs/Makefile index d82463f..b300bb6 100644 --- a/docs/Makefile +++ b/docs/Makefile @@

[Xen-devel] [PATCH 3/9] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

This commits (more or less) this file to be processed with pandoc, rather than other markdown processors. There is, unfortunately, no widely-accepted way to declare a title for the document. I tested feeding the document to markdown(1) on Debian jessie and it reproduced the % line as if it were

[Xen-devel] [PATCH 5/9] docs/gen-html-index: Support documents at the toplevel

There are none yet. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross --- docs/gen-html-index | 4 1 file changed, 4 insertions(+) diff --git a/docs/gen-html-index b/docs/gen-html-index index 5b43b42..8258e2b 100644 ---

[Xen-devel] [PATCH 8/9] docs: Provide parse-support-md

This utility reads json format pandoc output, from parsing one or more SUPPORT.md files, and generates an HTML table element containing the principal version and feature information. This is rather hairier than I anticipated when I started out; hence the 400-odd-line Perl script. Machinery to

[Xen-devel] [PATCH 2/9] SUPPORT.md: Syntax: Fix a typo "States"

Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George Dunlap --- SUPPORT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index 1c5220b..e447069 100644 ---

[Xen-devel] [PATCH 9/9] docs: Provide support-matrix-generate, to generate a support matrix in HTML

This archaeology script: - figures out what the current and previous Xen versions were - looks for appropriate git branches for them - finds SUPPORT.md for each one - feeds its findings to parse-support-md We do not intend to integrate this into docs/Makefile, because it relies on the git

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

>>> On 11.04.18 at 17:05, wrote: > On 11/04/18 15:49, Konrad Rzeszutek Wilk wrote: >> On Wed, Apr 11, 2018 at 01:12:51PM +0100, Andrew Cooper wrote: >>> On 11/04/18 13:01, Simon Gaiser wrote: Andrew Cooper: > On 11/04/18 12:48, Simon Gaiser wrote: >> Hi,

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Olaf Hering wrote: > On Wed, Apr 11, Olaf Hering wrote: > > On Wed, Apr 11, Dario Faggioli wrote: > > > Olaf, can you give it a try? It should be fine to run it on top of the > > > last debug patch (the one that produced this crash). > > Yes, with both changes it did >4k

Re: [Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

Hi, I forgot to mention that the title of most of the patch gives the impression you fixes hotplug for both Arm32 and Arm64. After a deeper look, it is only arm64. Please make clear over commit message and cover letter. Cheers, On 11/04/18 14:19, Mirela Simonovic wrote: This patch set

Re: [Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario

Hi, On 11/04/18 14:19, Mirela Simonovic wrote: In existing code the paging for secondary CPUs is setup only in boot flow. The setup is triggered from start_xen function after all CPUs are brought online. In other words, the initialization of VTCR_EL2 register is done out of the

Re: [Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

Hi Mirela, Thank you for sending the series. On 11/04/18 14:19, Mirela Simonovic wrote: This patch set contains fixes required to enable CPU hotplug for secondary CPUs. CPU hotplug of secondary CPUs will be used for suspend to RAM support for ARM. With these patches calling

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

On 11/04/18 15:49, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 11, 2018 at 01:12:51PM +0100, Andrew Cooper wrote: >> On 11/04/18 13:01, Simon Gaiser wrote: >>> Andrew Cooper: On 11/04/18 12:48, Simon Gaiser wrote: > Hi, > > when I use early microcode loading with the microcode

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Olaf Hering wrote: > On Wed, Apr 11, Dario Faggioli wrote: > > > Olaf, can you give it a try? It should be fine to run it on top of the > > last debug patch (the one that produced this crash). > > Yes, with both changes it did >4k iterations already. Thanks. That was with

Re: [Xen-devel] [PATCH 7/7] xen/arm: Restore IRQ affinity after hotplugging a CPU

Hi, Please CC relevant maintainers for the code you modify. You can use scripts/get_maintainers.pl for that. I have CCed them for you this time. Cheers, On 11/04/18 14:19, Mirela Simonovic wrote: Secondary pCPUs will be offlined on system suspend and hotplugged on resume. When offlining

Re: [Xen-devel] [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly

Hi, On 11/04/18 14:19, Mirela Simonovic wrote: Freeing percpu area is done when a non-boot CPU is disabled upon suspend. This use to be scheduled for execution after a period of time, what caused the following racing issues. If CPU is enabled after it is disabled and before the freeing of

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

On Wed, Apr 11, 2018 at 01:12:51PM +0100, Andrew Cooper wrote: > On 11/04/18 13:01, Simon Gaiser wrote: > > Andrew Cooper: > >> On 11/04/18 12:48, Simon Gaiser wrote: > >>> Hi, > >>> > >>> when I use early microcode loading with the microcode update with the > >>> BTI mitigations, resuming from

Re: [Xen-devel] [PATCH 3/7] xen/arm/psci: Implement CPU_OFF PSCI call (physical interface)

Hi, On 11/04/18 14:19, Mirela Simonovic wrote: This patch adds the PSCI CPU_OFF call to the EL3 in order to trigger powering down of the calling CPU when the CPU is stopped. If CPU_OFF call fails for some reason, e.g. EL3 does not implement the PSCI CPU_OFF function, the calling CPU will loop

Re: [Xen-devel] [PATCH 2/7] xen/arm/vgic-v2: Ignore write to GICD_ISACTIVERn registers

Hi, On 11/04/18 14:19, Mirela Simonovic wrote: Guests attempt to write into these registers on resume (for example Linux). Without this patch a data abort exception will be raised to the guest. This patch handles the write access by ignoring it. This should be fine for now because reading these

Re: [Xen-devel] [PATCH 1/7] xen/arm: Added handling of the trapped access to OSLSR register

Hi, You seem to have used a wrong address for me. Title: This patch is only adding the arm64 side. Please make it clear in it. Cheers, On 04/11/2018 02:19 PM, Mirela Simonovic wrote: Linux/dom0 accesses OSLSR register when saving CPU context during the suspend procedure. Xen traps access to

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

Hi, On 04/06/2018 09:37 AM, Manish Jaggi wrote: On 04/05/2018 03:10 PM, Julien Grall wrote: Hi, On 02/04/18 12:17, Manish Jaggi wrote: On 04/02/2018 04:33 PM, Manish Jaggi wrote: On 03/27/2018 03:48 PM, Marc Zyngier wrote: On 27/03/18 10:07, Manish Jaggi wrote: This patch is ported

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

>>> On 11.04.18 at 14:46, wrote: > Jan Beulich: > On 11.04.18 at 14:11, wrote: >> On 11.04.18 at 14:01, wrote: Andrew Cooper: > On 11/04/18 12:48, Simon Gaiser wrote: >> Hi, >> >> when I

[Xen-devel] [PATCH 5/7] xen/arm: Remove __initdata and __init to enable CPU hotplug

CPU up flow is currently used during the initial boot to start secondary CPUs. However, the same flow should be used for CPU hotplug, e.g. when hotplugging secondary CPUs within the resume procedure (resume from the suspend to RAM). Therefore, prefixes __initdata and __init had to be removed from

[Xen-devel] [PATCH 3/7] xen/arm/psci: Implement CPU_OFF PSCI call (physical interface)

This patch adds the PSCI CPU_OFF call to the EL3 in order to trigger powering down of the calling CPU when the CPU is stopped. If CPU_OFF call fails for some reason, e.g. EL3 does not implement the PSCI CPU_OFF function, the calling CPU will loop in the infinite while/wfi, as it was looping before

[Xen-devel] [PATCH 1/7] xen/arm: Added handling of the trapped access to OSLSR register

Linux/dom0 accesses OSLSR register when saving CPU context during the suspend procedure. Xen traps access to this register, but has no handling for it. Consequently, Xen injects undef exception to linux, causing it to crash. This patch adds handling of the trapped access to OSLSR as ro/raz.

[Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

This patch set contains fixes required to enable CPU hotplug for secondary CPUs. CPU hotplug of secondary CPUs will be used for suspend to RAM support for ARM. With these patches calling disable_nonboot_cpus() from the boot CPU will cause all secondary CPUs to be stopped. When a CPU is stopped it

[Xen-devel] [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly

Freeing percpu area is done when a non-boot CPU is disabled upon suspend. This use to be scheduled for execution after a period of time, what caused the following racing issues. If CPU is enabled after it is disabled and before the freeing of percpu area is performed, Xen would crash upon

[Xen-devel] [PATCH 6/7] xen/arm: Setup virtual paging for secondary CPUs in non-boot scenario

In existing code the paging for secondary CPUs is setup only in boot flow. The setup is triggered from start_xen function after all CPUs are brought online. In other words, the initialization of VTCR_EL2 register is done out of the cpu_up/start_secondary control flow. However, the cpu_up flow

[Xen-devel] [PATCH 7/7] xen/arm: Restore IRQ affinity after hotplugging a CPU

Secondary pCPUs will be offlined on system suspend and hotplugged on resume. When offlining secondary CPUs all interrupts targeted to those CPUs will be routed to the boot CPU. The boot CPU is responsible for finalizing suspend procedure. All wake-up interrupts are therefore targeted to the boot

[Xen-devel] [PATCH 2/7] xen/arm/vgic-v2: Ignore write to GICD_ISACTIVERn registers

Guests attempt to write into these registers on resume (for example Linux). Without this patch a data abort exception will be raised to the guest. This patch handles the write access by ignoring it. This should be fine for now because reading these registers is already handled as 'read as zero'.

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Dario Faggioli wrote: > If you're interested in figuring out, I'd like to see: > - full output of `xl info -n' > - output of `xl debug-key u' > - xl vcpu-list > - xl list -n Logs for this .cfg attached: name='fv_sles12sp1.0' vif=[ 'mac=00:18:3e:58:00:c1,bridge=br0' ] memory=

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

Jan Beulich: On 11.04.18 at 14:11, wrote: > On 11.04.18 at 14:01, wrote: >>> Andrew Cooper: On 11/04/18 12:48, Simon Gaiser wrote: > Hi, > > when I use early microcode loading with the microcode update with the > BTI

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

>>> On 11.04.18 at 13:02, wrote: > On 04/11/2018 11:17 AM, Dario Faggioli wrote: >> On Wed, 2018-04-11 at 12:00 +0200, Olaf Hering wrote: >>> On Wed, Apr 11, Dario Faggioli wrote: >>> Olaf, can you give it a try? It should be fine to run it on top of the

[Xen-devel] [RFC PATCH 1/3] xen: Introduce vcpu_sleep_nosync_locked()

There are a lot of places which release a lock before calling vcpu_sleep_nosync(), which then just grabs the lock again. This is not only a waste of time, but leads to more code duplication (since you have to copy-and-paste recipes rather than calling a unified function), which in turn leads to

[Xen-devel] [RFC PATCH 0/3] vcpu migration improvements

Some compile-tested-only sketches of what I'm talking about. Let me know what you think. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [RFC PATCH 3/3] sched/credit: Avoid doing cpu_pick calculation twice when deciding to move

In vcpu_acct(), we call _csched_cpu_pick() in order to decide whether to consider migrating; but then we throw that result away and do it again in context_saved() if we decide we do need to move. Instead, just initiate the migration and let the vcpu_migrate_finish() in context_saved() determine

[Xen-devel] [RFC PATCH 2/3] xen: Refactor migration

The current sequence to initiate vcpu migration is inefficent and error-prone: - The initiator sets VPF_migraging with the lock held, then drops the lock and calls vcpu_sleep_nosync(), which immediately grabs the lock again - A number of places unnecessarily check for v->pause_flags in

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

flight 122161 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122161/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 121291

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

>>> On 11.04.18 at 14:11, wrote: On 11.04.18 at 14:01, wrote: >> Andrew Cooper: >>> On 11/04/18 12:48, Simon Gaiser wrote: Hi, when I use early microcode loading with the microcode update with the BTI mitigations, resuming

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

On 11/04/18 13:01, Simon Gaiser wrote: > Andrew Cooper: >> On 11/04/18 12:48, Simon Gaiser wrote: >>> Hi, >>> >>> when I use early microcode loading with the microcode update with the >>> BTI mitigations, resuming from suspend to RAM is broken. >>> >>> Based on added logging to enter_state() (from

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

>>> On 11.04.18 at 14:01, wrote: > Andrew Cooper: >> On 11/04/18 12:48, Simon Gaiser wrote: >>> Hi, >>> >>> when I use early microcode loading with the microcode update with the >>> BTI mitigations, resuming from suspend to RAM is broken. >>> >>> Based on added

[Xen-devel] [ovmf baseline-only test] 74576: all pass

This run is configured for baseline tests only. flight 74576 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74576/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 13d909f89a3cee1c1f6b851a4cda7bd1a44e90ae baseline

Re: [Xen-devel] Resume from suspend to RAM broken when using early microcode updates

>>> On 11.04.18 at 13:51, wrote: > On 11/04/18 12:48, Simon Gaiser wrote: >> Hi, >> >> when I use early microcode loading with the microcode update with the >> BTI mitigations, resuming from suspend to RAM is broken. >> >> Based on added logging to enter_state() (from

[Xen-devel] [PATCH v5] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

My recent Xen patch series introduces a new HYPERVISOR_memory_op to support direct priv-mapping of certain guest resources (such as ioreq pages, used by emulators) by a tools domain, rather than having to access such resources via the guest P2M. This patch adds the necessary infrastructure to the

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 11.04.18 at 13:53, wrote: > * Jan Beulich wrote: > >> Additionally, x86 maintainers: is there a particular reason this (or >> any functionally equivalent patch) isn't upstream yet? As indicated >> before, I had not been able to find any discussion,

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

* Jan Beulich wrote: > Additionally, x86 maintainers: is there a particular reason this (or > any functionally equivalent patch) isn't upstream yet? As indicated > before, I had not been able to find any discussion, and hence I > see no reason why this is a patch we

[Xen-devel] Resume from suspend to RAM broken when using early microcode updates

Hi, when I use early microcode loading with the microcode update with the BTI mitigations, resuming from suspend to RAM is broken. Based on added logging to enter_state() (from power.c) it doesn't survive the local_irq_restore(flags) call (at least a printk() after the call doesn't output

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On 04/11/2018 11:17 AM, Dario Faggioli wrote: > On Wed, 2018-04-11 at 12:00 +0200, Olaf Hering wrote: >> On Wed, Apr 11, Dario Faggioli wrote: >> >>> Olaf, can you give it a try? It should be fine to run it on top of >>> the >>> last debug patch (the one that produced this crash). >> >> Yes, with

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, 2018-04-11 at 11:37 +0100, George Dunlap wrote: > On 04/10/2018 11:59 PM, Dario Faggioli wrote: > > > > So, basically, the race is between context_saved() and > > vcpu_set_affinity(). Basically, vcpu_set_affinity() sets the > > VPF_migrating pause flags on a vcpu in a runqueue, with the

Re: [Xen-devel] [PATCH 3/7] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

On Wed, Apr 11, 2018 at 11:37 AM, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH 3/7] SUPPORT.md: Syntax: > Provide a title rather than a spurious empty section"): >> On Tue, Apr 10, 2018 at 6:22 PM, Ian Jackson >> wrote:

Re: [Xen-devel] [PATCH 1/7] SUPPORT.md: Syntax: Fix some bullet lists

George Dunlap writes ("Re: [Xen-devel] [PATCH 1/7] SUPPORT.md: Syntax: Fix some bullet lists"): > You forgot to CC "THE REST". Rather, I decided not to. There are no meaningful changes here, just build system and formatting syntax changes. Feel free to CC them if you think they will want to

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On 04/10/2018 11:59 PM, Dario Faggioli wrote: > [Adding Andrew, not because I expect anything, but just because we've > chatted about this issue on IRC :-) ] > > On Tue, 2018-04-10 at 22:37 +0200, Olaf Hering wrote: >> On Tue, Apr 10, Dario Faggioli wrote: >> >>

Re: [Xen-devel] [PATCH 3/7] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

George Dunlap writes ("Re: [Xen-devel] [PATCH 3/7] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section"): > On Tue, Apr 10, 2018 at 6:22 PM, Ian Jackson > wrote: > > -# Support statement for this release > > +% Support statement for this release >

Re: [Xen-devel] [PATCH v4] x86/setup: disallow any src/dst overlaps when relocating Xen image

On Wed, Apr 11, 2018 at 02:58:01AM -0600, Jan Beulich wrote: > >>> On 11.04.18 at 10:54, wrote: > > On Tue, Apr 03, 2018 at 05:54:14PM +0200, Daniel Kiper wrote: > >> Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image > >> placement) disallowed src/dst

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, 2018-04-11 at 10:48 +0200, Olaf Hering wrote: > On Wed, Apr 11, Dario Faggioli wrote: > > So, now, when you say 'does not work', do you mean 'domain creation > > is > > aborted with errors' or 'domain is created, but memory is not where > > it > > should be'. > > domU can not be created

Re: [Xen-devel] crash in csched_load_balance after xl vcpu-pin

On Wed, Apr 11, Dario Faggioli wrote: > Olaf, can you give it a try? It should be fine to run it on top of the > last debug patch (the one that produced this crash). Yes, with both changes it did >4k iterations already. Thanks. Olaf signature.asc Description: PGP signature

[Xen-devel] [xen-unstable-coverity test] 122173: all pass - PUSHED

flight 122173 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/122173/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 50f8ba84a50ebf80dd22067a04062dbaaf2621ff baseline version: xen

Re: [Xen-devel] [PATCH 3/7] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section

On Tue, Apr 10, 2018 at 6:22 PM, Ian Jackson wrote: > Signed-off-by: Ian Jackson > --- > SUPPORT.md | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/SUPPORT.md b/SUPPORT.md > index e447069..264b23f 100644 > ---

Re: [Xen-devel] [PATCH v4] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 11 April 2018 10:46 > To: Paul Durrant ; xen-devel@lists.xenproject.org; > linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org > Cc: Juergen Gross ;

Re: [Xen-devel] [PATCH v4] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

Hi, On 10/04/18 08:58, Paul Durrant wrote: +static long privcmd_ioctl_mmap_resource(struct file *file, void __user *udata) +{ + struct privcmd_data *data = file->private_data; + struct mm_struct *mm = current->mm; + struct vm_area_struct *vma; + struct

Re: [Xen-devel] [PATCH 2/7] SUPPORT.md: Syntax: Fix a typo "States"

On Tue, Apr 10, 2018 at 6:22 PM, Ian Jackson wrote: > Signed-off-by: Ian Jackson Acked-by: George Dunlap > --- > SUPPORT.md | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/SUPPORT.md

Re: [Xen-devel] [PATCH 1/7] SUPPORT.md: Syntax: Fix some bullet lists

On Tue, Apr 10, 2018 at 6:22 PM, Ian Jackson wrote: > Continuations of bullet list items must be indented by exactly 4 > spaces (according to pandoc_markdown(5) on Debian jessie). > > This is most easily achieved by making the bullet list items have two > spaces before

[Xen-devel] [qemu-mainline baseline-only test] 74574: trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 74574 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74574/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64

  1   2   >