flight 136307 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 136116
test-amd64
flight 136315 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136315/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134
flight 136321 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136321/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 136021
test-armhf-armhf-libvirt-raw 13 saveresto
flight 136311 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136311/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133734
Test
flight 136320 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136320/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 135251
build-arm64
On Fri, May 17, 2019 at 9:38 AM Wei Liu wrote:
>
> On Thu, May 16, 2019 at 12:27:19PM -0700, Alistair Francis wrote:
> > On Thu, May 16, 2019 at 6:30 AM Wei Liu wrote:
> > >
> > > On Thu, May 16, 2019 at 03:18:19PM +0200, Olaf Hering wrote:
> > > > Am Thu, 16 May 2019 12:39:02 +0100
> > > > schri
On Thu, May 16, 2019 at 11:26 PM Jan Beulich wrote:
>
> >>> On 16.05.19 at 21:30, wrote:
> > On Thu, May 16, 2019 at 3:32 AM Jan Beulich wrote:
> >>
> >> >>> On 16.05.19 at 02:02, wrote:
> >> > Make the asm/vpl011.h dependent on the ARM architecture.
> >>
> >> But we only have x86 and Arm right
On Fri, May 17, 2019 at 1:46 AM Julien Grall wrote:
>
>
>
> On 16/05/2019 20:30, Alistair Francis wrote:
> > On Thu, May 16, 2019 at 3:32 AM Jan Beulich wrote:
> >>
> > On 16.05.19 at 02:02, wrote:
> >>> Make the asm/vpl011.h dependent on the ARM architecture.
> >>
> >> But we only have x86
flight 136463 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136463/
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
flight 136306 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136306/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a11d371ef660db42c70a00f7e4297367ae5afec5
baseline version:
ovmf 96ef5a8e30a8da33eaab0
On Fri, May 17, 2019 at 1:21 AM Jan Beulich wrote:
>
> >>> On 16.05.19 at 23:37, wrote:
> > --- a/xen/include/asm-x86/mm.h
> > +++ b/xen/include/asm-x86/mm.h
> > @@ -356,24 +356,15 @@ struct platform_bad_page {
> > const struct platform_bad_page *get_platform_badpages(unsigned int
> > *array_si
During initcalls is ok, but is a rather random place to find the build-id:
(XEN) Parked 2 CPUs
(XEN) build-id: 7ff05f78ebc8141000b9feee4370a408bd935dec
(XEN) Running stub recovery selftests...
Logically, it is version information, so print with the changeset information
in console_init_prei
Hi,
On 5/17/19 6:23 PM, Anthony PERARD wrote:
On Thu, May 16, 2019 at 10:38:54PM +0100, Julien Grall wrote:
Hi Anthony,
Thank you for CCing me.
On 5/16/19 11:37 AM, Anthony PERARD wrote:
On Wed, May 15, 2019 at 07:48:17PM +, osstest service owner wrote:
flight 136184 qemu-upstream-4.11-
When you boot Xen with the default 256 NR_CPUS, on a box with rather more
processors, the resulting spew is unnecesserily verbose. Instead, print the
message once, e.g:
(XEN) ACPI: X2APIC (apic_id[0x115] uid[0x115] enabled)
(XEN) WARNING: NR_CPUS limit of 256 reached - ignoring further processo
Reflow the ZynqMP message for grepability, and fix the omission of a newline.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/cpuerrata.c | 18 ++
xen/arch/arm/platforms/x
They are both Airmont-based and should have been included in c/s 17f74242ccf
"x86/spec-ctrl: Extend repoline safey calcuations for eIBRS and Atom parts".
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/spec_ctrl.c | 2 ++
1 file changed, 2 ins
flight 136293 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 135859
Test
flight 136453 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136453/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 136442
Tests which
On Thu, May 16, 2019 at 10:38:54PM +0100, Julien Grall wrote:
> Hi Anthony,
>
> Thank you for CCing me.
>
> On 5/16/19 11:37 AM, Anthony PERARD wrote:
> > On Wed, May 15, 2019 at 07:48:17PM +, osstest service owner wrote:
> > > flight 136184 qemu-upstream-4.11-testing real [real]
> > > http:/
After 899433f149d libxl needs to know the content of d_config to
determine which QEMU is used. The code is changed such that
libxl__domain_set_device_model needs to be called before
libxl__domain_build_info_setdefault.
This is fine for libxl code, but it is problematic for
libxl_domain_need_memory
On 15/03/2019 10:44, Jan Beulich wrote:
> Test various of the insns which have been implemented already.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mail
On 15/03/2019 10:43, Jan Beulich wrote:
> Test various of the insns which have been implemented already.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mail
On 15/03/2019 10:43, Jan Beulich wrote:
> Entries to the tables in evex-disp8.c are added despite these insns not
> allowing for memory operands, with the goal of the tables giving a
> complete picture of the supported EVEX-encoded insns in the end.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew
On 15/03/2019 10:43, Jan Beulich wrote:
> Also include vshuff{32x4,64x2} as being very similar to vshufi{32x4,64x2}.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproj
On 15/03/2019 10:41, Jan Beulich wrote:
> Take the liberty and also correct the (public interface) name of the
> AVX512_VBMI feature flag, on the assumption that no external consumer
> has actually been using that flag so far.
I've been giving this some thought, and I think putting these in the
pu
On Fri, May 17, 2019 at 10:24:45AM +0200, Olaf Hering wrote:
> Am Thu, 16 May 2019 14:30:13 +0100
> schrieb Wei Liu :
>
> > @@ -457,6 +457,12 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
> > +if (!b_info->device_model_version)
> > + b_info->device_model_version = LIBXL_DEVICE_MODEL_XX
On Thu, May 16, 2019 at 12:27:19PM -0700, Alistair Francis wrote:
> On Thu, May 16, 2019 at 6:30 AM Wei Liu wrote:
> >
> > On Thu, May 16, 2019 at 03:18:19PM +0200, Olaf Hering wrote:
> > > Am Thu, 16 May 2019 12:39:02 +0100
> > > schrieb Wei Liu :
> > >
> > > > autotools shipped in all the distro
On Thu, May 16, 2019 at 12:25:36PM -0700, Alistair Francis wrote:
> On Thu, May 16, 2019 at 3:31 AM Jan Beulich wrote:
> >
> > >>> On 16.05.19 at 02:02, wrote:
> > > Signed-off-by: Alistair Francis
> >
> > At least to me it is far from obvious why we would want/need to
> > do this update, or whe
Julien Grall writes ("qcom_scm: Incompatible pointer type build failure"):
> Thank you for the report.
...>
> On 30/04/2019 13:44, Ian Jackson wrote:
> > osstest service owner writes ("[linux-4.19 test] 135420: regressions -
> > FAIL"):
> >drivers/firmware/qcom_scm.c: In function ‘qcom_scm_
Jan Beulich writes ("Re: preparations for 4.11.2"):
> Okay - as also indicated on irc, with the weekend in between and
> with the most recent flight having failed anyway it shouldn't be
> too much of an extra delay.
Right. OK, I have pushed my queue now.
> Yet to be honest - most or all of these
Ian Jackson writes ("Re: [Xen-devel] preparations for 4.11.2"):
> Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> > On 16/05/2019 17:17, Ian Jackson wrote:
> > > Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> > >> 129025fe3093 "oxenstored: Don't re-open a xe
flight 136287 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136287/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not
Julien Grall writes ("Re: [Xen-devel] [qemu-upstream-4.11-testing test] 136184:
regressions - FAIL"):
> On 5/16/19 11:37 AM, Anthony PERARD wrote:
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >> test-arm64-arm64-libvirt-xsm 7 xen-boot
On 17/05/2019 13:21, Jan Beulich wrote:
> While I've also already coded up the patch to actually support
> the new BFloat16 insns, there's little point in submitting this
> without having tested it. But the two preparatory patches may
> turn out useful earlier on. They're based on the full AVX512
>
> On 16. May 2019, at 15:50, Graf, Alexander wrote:
>
> On 14.05.19 08:16, Filippo Sironi wrote:
>> Start populating /sys/hypervisor with KVM entries when we're running on
>> KVM. This is to replicate functionality that's available when we're
>> running on Xen.
>>
>> Start with /sys/hypervisor/
On Fri, May 17, 2019 at 02:36:41AM -0400, Rich Persaud wrote:
> > On May 13, 2019, at 11:34, Wei Liu wrote:
> >
> > Hello
> >
> > Seeing that you were the last people who changed blktap2 in a meaningful
> > way: do you use it at all?
>
> As discussed F2F in a Xen Summit 2017 design session: Ope
flight 136442 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136442/
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 17/05/2019 16:00, Jan Beulich wrote:
> While clang supposedly supports -mstack-alignment= instead, I'm not
> using that alternative here due to being uncertain whether that's indeed
> an exact equivalent of the gcc option. Only make use of the option
> entirely conditional for now.
>
> Reported-
>>> On 17.05.19 at 16:10, wrote:
> Hi Jan and Andrew, All
>
> From standard:
> The result of E1 >> E2 is E1 right-shifted E2 bit positions.
> If E1 has an unsigned type or if E1 has a signed type and a nonnegative
> value,
> the value of the result is the integral part of the quotient of E1 / 2E
While clang supposedly supports -mstack-alignment= instead, I'm not
using that alternative here due to being uncertain whether that's indeed
an exact equivalent of the gcc option. Only make use of the option
entirely conditional for now.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
Hi Jan and Andrew, All
From standard:
The result of E1 >> E2 is E1 right-shifted E2 bit positions.
If E1 has an unsigned type or if E1 has a signed type and a nonnegative value,
the value of the result is the integral part of the quotient of E1 / 2E2.
If E1 has a signed type and a negative value,
flight 136297 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136297/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 5834f8720468762959497218a313013802c5499d
baseline version:
freebsd e45876ac9f0
The presence of cron causes leak check failures, since cron may run
processes that the leak checker detects. Disable it, since none of
our installs live long enough for this to matter.
Do this in host_install_postboot_complete since it seems to me like we
don't want this in guests any more than w
On 17/05/2019 15:36, Jan Beulich wrote:
On 17.05.19 at 15:24, wrote:
>> On 17/05/2019 15:17, Jan Beulich wrote:
>> On 08.05.19 at 13:31, wrote:
Commit 753ba43d6d16e688 ("xen/sched: fix credit2 smt idle handling")
introduced a regression when switching cpus between cpupools.
>>>
>>> On 17.05.19 at 15:24, wrote:
> On 17/05/2019 15:17, Jan Beulich wrote:
> On 08.05.19 at 13:31, wrote:
>>> Commit 753ba43d6d16e688 ("xen/sched: fix credit2 smt idle handling")
>>> introduced a regression when switching cpus between cpupools.
>>>
>>> When assigning a cpu to a cpupool with c
On 17/05/2019 15:17, Jan Beulich wrote:
On 08.05.19 at 13:31, wrote:
>> Commit 753ba43d6d16e688 ("xen/sched: fix credit2 smt idle handling")
>> introduced a regression when switching cpus between cpupools.
>>
>> When assigning a cpu to a cpupool with credit2 being the default
>> scheduler csc
>>> On 08.05.19 at 13:31, wrote:
> Commit 753ba43d6d16e688 ("xen/sched: fix credit2 smt idle handling")
> introduced a regression when switching cpus between cpupools.
>
> When assigning a cpu to a cpupool with credit2 being the default
> scheduler csched2_deinit_pdata() is called for the credit2
>>> On 17.05.19 at 13:25, wrote:
> Hi All,
>
> While looking at code in tools/libxc/xc_sr_save_x86_pv.c,
> we see that there is casting of xen virtual address type xen_vaddr_t
> to signed int64 type.
> In commit: 7bf74582b343603cb0826d808cd7da43326452a5
>
> +/* Check a 64 bit virtual address for
(Apologies for the use of outlook - I'm having email problems atm).
A canonical address in x86 is one which is correctly sign extended from bit 47
to bit 63.
What is undefined about shifting int64_t by 63 bits? The answer is -1 or 0,
preserving the sign bit alone (which is the point of the com
flight 136273 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136273/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 23 leak-check/check fail REGR. vs. 136156
test-amd64-amd64-x
The AVX512_BF16 feature flag resides in leaf 7 sub-leaf 1. Expand
infrastructure accordingly before enabling support for those insns.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1845,6 +1845,7 @@ in_protmode(
static
The AVX512_BF16 feature flag resides in this so far blank sub-leaf.
Expand infrastructure accordingly.
Signed-off-by: Jan Beulich
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -218,6 +218,8 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"arch-caps",0x0007, 0,
(Apologies for use of outlook - I'm having email problems atm).
There is no memory leak at all.
x = memcpy(y, ...);
is an "x = y;" assignment in disguise. Recall that memcpy() returns y, and
isn't a void function.
~Andrew
From: Viktor Mitin
Sent: 17 M
While I've also already coded up the patch to actually support
the new BFloat16 insns, there's little point in submitting this
without having tested it. But the two preparatory patches may
turn out useful earlier on. They're based on the full AVX512
emulator series, but shouldn't be overly difficul
There is no memory leak in case when handle_hvm_context function is
called next time.
So the code seems ok, please ignore the mail, sorry for confusion.
Thanks
On Fri, May 17, 2019 at 2:49 PM Viktor Mitin wrote:
>
> Hi All,
>
> It seems there is a memory leak in libxc function handle_hvm_context
Hi All,
It seems there is a memory leak in libxc function handle_hvm_context
(in file tools/libxc/xc_sr_restore_x86_hvm.c.). There is a malloc of
variable p without free.
Please take a look.
+/*
+ * Process an HVM_CONTEXT record from the stream.
+ */
+static int handle_hvm_context(struct xc_sr_co
This was probably useful as a sanity check when the "__xen_guest"
section were not legacy. But now ELF notes are prefered and
"should live in a PT_NOTE segment" (elfnote.h).
This check is unnecessary as elf_xen_parse() from xen/common/libelf
will do the right thing and look for ELFNOTEs in the di
Hi All,
While looking at code in tools/libxc/xc_sr_save_x86_pv.c,
we see that there is casting of xen virtual address type xen_vaddr_t
to signed int64 type.
In commit: 7bf74582b343603cb0826d808cd7da43326452a5
+/* Check a 64 bit virtual address for being canonical. */
+static inline bool is_canoni
This is largely to drop a forward declaration. There's one functional
change - clear_irq_vector() gets marked __init, as its only caller is
check_timer(). Beyond this only a few stray blanks get removed.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@
Use valid_irq_vector() rather than "> 0".
Also replace an open-coded use of IRQ_VECTOR_UNASSIGNED.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -342,7 +342,7 @@ void clear_irq_vector(int irq)
int irq_to_vector(int irq)
{
-int vector = -1;
Use scratch_cpumask where possible, to avoid creating these possibly
large stack objects. We can't use it in _assign_irq_vector() and
set_desc_affinity(), as these get called in IRQ context.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -285,14 +285
The setup for calling trace_var() (which itself checks tb_init_done) is
non-negligible, and hence a separate outer-most check is warranted.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -121,8 +121,8 @@ static void release_old_vec(struct irq_d
Its only caller already has the IRQ descriptor in its hands, so there's
no need for the function to re-obtain it. As a result the leading p of
its name is no longer appropriate and hence gets dropped.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v2: New.
--- a/xen/arch/x86/irq.c
The subsequent cpumask_intersects() covers the "empty" case quite fine.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -650,9 +650,6 @@ void move_masked_irq(struct irq_desc *de
desc->status &= ~IRQ_MOVE_PENDING;
-if
Since the "Cannot set affinity ..." warning is a one time one, avoid
triggering it already at boot time when parking secondary threads and
the serial console uses a (still unconnected at that time) PCI IRQ.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/irq.c
+++ b/x
If any particular value was to be checked against, it would need to be
IRQ_VECTOR_UNASSIGNED.
Reported-by: Roger Pau Monné
Be more strict though and use valid_irq_vector() instead.
Take the opportunity and also convert local variables to unsigned int.
Signed-off-by: Jan Beulich
Reviewed-by: R
All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
fields, and hence ought to be called with the descriptor lock held in
addition to vector_lock. This is currently the case for only
set_desc_affinity() (in the common case) and destroy_irq(), which also
clarifies what the nesting b
fixup_irqs() skips interrupts without action. Hence such interrupts can
retain affinity to just offline CPUs. With "noirqbalance" in effect,
pirq_guest_bind() so far would have left them alone, resulting in a non-
working interrupt.
Signed-off-by: Jan Beulich
---
v3: New.
---
I've not observed th
Mixed meaning was implied so far by different pieces of code -
disagreement was in particular about whether to expect offline CPUs'
bits to possibly be set. Switch to a mostly consistent meaning
(exception being high priority interrupts, which would perhaps better
be switched to the same model as w
Don't log a stray trailing comma. Shorten a few fields.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2334,7 +2334,7 @@ static void dump_irqs(unsigned char key)
spin_lock_irqsave(&desc->lock, flags);
-printk("
desc->arch.cpu_mask reflects the actual set of target CPUs. Don't ever
fiddle with desc->affinity itself, except to store caller requested
values. Note that assign_irq_vector() now takes a NULL incoming CPU mask
to mean "all CPUs" now, rather than just "all currently online CPUs".
This way no furth
The flag being set may prevent affinity changes, as these often imply
assignment of a new vector. When there's no possible destination left
for the IRQ, the clearing of the flag needs to happen right from
fixup_irqs().
Additionally _assign_irq_vector() needs to avoid setting the flag when
there's
The cleanup IPI may get sent immediately before a CPU gets removed from
the online map. In such a case the IPI would get handled on the CPU
being offlined no earlier than in the interrupts disabled window after
fixup_irqs()' main loop. This is too late, however, because a possible
affinity change m
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-debianhvm-amd64
testid xen-boot
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: ovmf git://xenbits.xen.org/osstest/
First and foremost this series is trying to deal with CPU offlining
issues, which have become more prominent with the recently
added SMT enable/disable operation in xen-hptool. Later patches
in the series then carry out more or less unrelated changes
(hopefully improvements) noticed while looking a
Don't log the same global information once per CPU. Don't log the same
information (here: the currently active state) twice. Don't prefix
decimal numbers with zeros (giving the impression they're octal). Use
format specifiers matching the type of the corresponding expressions.
Don't split printk()-
When the mwait-idle driver isn't used, C-state information becomes
available only in the course of Dom0 starting up. Use the provided data
to allow parked CPUs to sleep in a more energy efficient way, by waking
them briefly (via NMI) once the data has been recorded.
This involves re-arranging how/
In order to be able to wake parked CPUs from default_dead_idle() (for
them to then enter a different dead-idle routine), the function should
not itself loop. Move the loop into play_dead(), and use play_dead() as
well on the AP boot error path.
Furthermore, not the least considering the comment in
When putting CPUs to sleep permanently, we should try to put them into
the most power conserving state possible. For now it is unclear whether,
especially in a deep C-state, the P-state also matters, so this series only
arranges for the C-state side of things (plus some cleanup).
1: x86/idle: re-a
A hard to trigger race with another unrelated systemd service and
xenstored.service unveiled a bug in the way how xenstored is launched
with systemd.
launch-xenstore may start either a daemon or a domain. In case a domain
is used, systemd-notify was called. If another service triggered a
restart o
Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> On 16/05/2019 17:17, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> >> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
> >> domain introduction"
> > Can you justify how
On 17/05/2019 10:22, Jan Beulich wrote:
On 17.05.19 at 09:48, wrote:
>> On 17/05/2019 08:57, Jan Beulich wrote:
>> On 17.05.19 at 07:13, wrote:
On 16/05/2019 16:41, Jan Beulich wrote:
On 16.05.19 at 15:51, wrote:
>> As with core scheduling we can be sure the other thre
On 16/05/2019 20:30, Alistair Francis wrote:
On Thu, May 16, 2019 at 3:32 AM Jan Beulich wrote:
On 16.05.19 at 02:02, wrote:
Make the asm/vpl011.h dependent on the ARM architecture.
But we only have x86 and Arm right now. A word more about
your motivation would help.
As the code curre
Am Thu, 16 May 2019 14:30:13 +0100
schrieb Wei Liu :
> @@ -457,6 +457,12 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
> +if (!b_info->device_model_version)
> + b_info->device_model_version = LIBXL_DEVICE_MODEL_XXX;
I think this will work and should be applied to unbreak staging.
The
>>> On 17.05.19 at 09:48, wrote:
> On 17/05/2019 08:57, Jan Beulich wrote:
> On 17.05.19 at 07:13, wrote:
>>> On 16/05/2019 16:41, Jan Beulich wrote:
>>> On 16.05.19 at 15:51, wrote:
> As with core scheduling we can be sure the other thread is active
> (otherwise we would schedul
On 17/05/2019 08:57, Jan Beulich wrote:
On 17.05.19 at 07:13, wrote:
>> On 16/05/2019 16:41, Jan Beulich wrote:
>> On 16.05.19 at 15:51, wrote:
On 16/05/2019 15:05, Jan Beulich wrote:
On 06.05.19 at 08:56, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86
flight 136243 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 11 debian-fixup fail REGR. vs. 133580
test-amd64-amd64-li
flight 136249 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136249/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 136132
test-amd64-amd64-xl-qemuu-win7-amd64 17
>>> On 16.05.19 at 17:54, wrote:
>
> On 16/05/2019, 04:47, "Jan Beulich" wrote:
>
> >>> On 16.05.19 at 00:18, wrote:
> > +# Mappings to track files are of the following format
> > +# ---
> > +# manual|auto xen-file name-of-origi
>>> On 16.05.19 at 23:37, wrote:
> Disable it by default as it is only an experimental subsystem.
>
> Signed-off-by: Tamas K Lengyel
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm
>>> On 16.05.19 at 23:37, wrote:
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -356,24 +356,15 @@ struct platform_bad_page {
> const struct platform_bad_page *get_platform_badpages(unsigned int
> *array_size);
>
> /* Per page locks:
> - * page_lock() is used for two p
>>> On 16.05.19 at 15:52, wrote:
> On Wed, May 08, 2019 at 06:48:16AM -0600, Jan Beulich wrote:
>> @@ -1114,19 +1114,18 @@ static void irq_guest_eoi_timer_fn(void
>>
>> action = (irq_guest_action_t *)desc->action;
>>
>> +ASSERT(action->ack_type != ACKTYPE_NONE);
>> +
>> if ( !act
92 matches
Mail list logo
