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
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
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
>
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
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.
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=
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
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
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
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,
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
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.
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
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
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
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
>
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
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
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
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
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
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
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:
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
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) [
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
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
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 -
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
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
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
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
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;
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
+++
>>> 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
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
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:
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
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
@@
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
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
---
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
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
---
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
>>> 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,
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
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
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
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
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
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
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
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
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
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
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
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
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
>>> 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
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
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
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.
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
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
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
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
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'.
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=
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
>>> 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
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
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
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
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
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
>>> 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
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
>>> 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
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
>>> 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
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
>>> 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,
* 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
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
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
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
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:
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
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:
>>
>>
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
>
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
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
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
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
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
> ---
> -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 ;
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
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
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
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 - 100 of 115 matches
Mail list logo