>>> On 11.04.18 at 22:14, wrote:
> Make it possible to distinguish between a failure to load a microcode
> update and a failure to find any matching microcode update by returning
> -ENOENT (instead of -EIO) in the later case.
>
> Signed-off-by: Simon Gaiser
> ---
> xen/arch/x86/microcode.c | 2
>>> On 12.04.18 at 08:31, wrote:
> Ping...
>
> Can someone help to review these two patches?
Sure, they're on my list of things to look at. Too many other things
going on.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
Ping...
Can someone help to review these two patches?
On Fri, Mar 30, 2018 at 02:59:00PM +0800, Chao Gao wrote:
>From: Gao Chao
>
>This patch is to backport microcode improvement patches from linux
>kernel. Below are the original patches description:
>
>commit a5321aec6412b20b5ad15db2d6b916c
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 maili
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
test-amd64-i386-libvirt
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
> Subject: Re: [Xen-devel] [RFC v2] xen/arm: Suspend to R
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
>
> Hell
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.
GFP_A
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&m=
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 whi
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 13d909f89a3cee1c1f6b8
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 wak
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, pr
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 after
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. Th
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 Simonovic wrote:
> > Linu
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 host-bui
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
test-amd64-i386-xl-
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
> (XEN) [ Xen-4.
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 full
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 spin_debug_enable() though,
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 been modified. One of the big
Make it possible to distinguish between a failure to load a microcode
update and a failure to find any matching microcode update by returning
-ENOENT (instead of -EIO) in the later case.
Signed-off-by: Simon Gaiser
---
xen/arch/x86/microcode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
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 lo
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&m=
> https://xen.markmail.org/thread/m75h6b2aiwk5h7fx
>
>
> No acks, reviews only by memacce
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:
http://xenbits.xen.org/people/iwj/2018/support-matrix-example-v2/t.html
There is also an
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
build-ar
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) [ Xen-4.11.20180410T125
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 already works. However, when
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 need,
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 - a
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 trace and know wheth
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 man
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 i
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; hence
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
+++ b/docs/gen-html-index
@@ -10,6 +10,7 @@ use
>>> 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 it did >4k itera
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 Debia
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: Juergen Gross
Acked-by: George Du
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
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 s
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
@@ -28,7 +28,8 @@ DOC_MAN7 := $(patsubst man/%.
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
--- a/docs/gen-html-index
+++ b/docs/gen-html-index
@@ -137,6 +1
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 ass
We are going to want to format SUPPORT.md which does not match the
filename patterns in docs/. So provide a way to make an ad-hoc rule
using pandoc with the standard options.
No functional change in this patch.
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
---
docs/Makefile | 11
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 hist
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
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -360,7 +360,7 @@ Guest-side driver cap
>>> 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,
>>
>> when I use early
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 iterations
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 cont
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 cpu_up/start_seco
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 disable_nonboot_cpu
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 updat
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 sched=
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 seco
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 percpu
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 sus
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 in
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 t
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 to
>>> 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 use early microcode loading with the microcode update with the
>> BTI mitiga
flight 122174 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122174/
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 1
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 f
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.
Signed
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
initializ
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
shoul
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 CP
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'.
S
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 mitigations, resuming from suspend to RAM is broke
>>> 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
last debug patch (the one th
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 an
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 if
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 betwee
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
test-amd64-amd64-xl-qemuu-ws16-am
>>> 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 from suspend to RAM is broken.
Based on
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 logging to enter_state() (from power
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 v
>>> 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 power.c) it doesn't
>> surviv
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
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 power.c) it doesn't
>> survive the local_irq_res
>>> 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, and hence I
>> see no reason why this is
* 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 effectively carry privately i
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 power.c) it doesn't
> survive the local_irq_restore(flags) call (at lea
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 anythin
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 b
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 in
flight 122171 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122171/
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 1
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:
>> > -# Support statement for this release
>> > +% Su
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 both changes it did >4k iterations already. Thanks.
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 hav
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:
>>
>> BUG_ON(__vcpu_on_runq(CSCHED_
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
>
> By doing this we're more
1 - 100 of 125 matches
Mail list logo
