flight 133183 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133183/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On 2/12/19 9:31 AM, Jan Beulich wrote:
On 11.02.19 at 18:21, wrote:
On 2/11/19 6:59 PM, Jan Beulich wrote:
Thanks for noticing, actually this appears to invalidate the whole
purpose of the patch (I should have tested this more before sumbitting
V3, sorry).
The whole point of the new boolean i
flight 133132 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On 2/11/19 6:59 PM, Jan Beulich wrote:
Plus I can't see p2m_switch_vcpu_altp2m_by_id() called for
any HVMOP_altp2m_* at all. One of the actual callers is guarded
by altp2m_active(), but the other isn't.
Actually I see that both places are guarded by altp2m_active().
In p2m.c we have:
2312 voi
On Mon, Feb 11, 2019 at 03:14:55PM +0100, Juergen Gross wrote:
> On 11/02/2019 14:07, Norbert Manthey wrote:
> > On 2/6/19 16:10, Jan Beulich wrote:
> > On 06.02.19 at 15:09, wrote:
> >>> From: Norbert Manthey
> >>>
> >>> In the early steps of compilation, the asm header files are created, su
On Mon, Feb 11, 2019 at 06:46:36PM +0100, Roger Pau Monne wrote:
> The p2m and iommu mapping code always had the requirement that
> addresses and orders must be aligned when populating the p2m or the
> iommu page tables.
>
> PVH dom0 builder didn't take this requirement into account, and can
> cal
On Mon, Feb 11, 2019 at 06:46:39PM +0100, Roger Pau Monne wrote:
> There have been several reports of the dom0 builder running out of
> memory when building a PVH dom0 without having specified a dom0_mem
> value. Print a warning message if dom0_mem is not set when booting in
> PVH mode.
>
> This i
On Mon, Jan 28, 2019 at 10:30:18PM +0100, Marek Marczykowski-Górecki wrote:
> Add documentation based on reverse-engineered toolstack-ioemu stubdomain
> protocol.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Wei Liu
This matches my (vague) understanding of how it works. Thanks for
w
flight 133136 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
>>> On 12.02.19 at 11:11, wrote:
> On 2/11/19 6:59 PM, Jan Beulich wrote:
>> Plus I can't see p2m_switch_vcpu_altp2m_by_id() called for
>> any HVMOP_altp2m_* at all. One of the actual callers is guarded
>> by altp2m_active(), but the other isn't.
>
> Actually I see that both places are guarded by
Ian Jackson writes ("arm64, laxton[01] (was Re: [Xen-devel] [xen-unstable-smoke
test] 133030: trouble: blocked/broken/pass)"):
> I have checked and there was no update to the osstest code. I don't
> think there have been updates to the infrastructure config but I
> haven't searched all the infras
Jan, are you investigating this regression ?
osstest service owner writes ("[linux-3.18 bisection] complete
test-amd64-amd64-pair"):
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-pair
> testid xen-boot/dst_host
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
SYMBOL"):
> On Thu, 7 Feb 2019, Ian Jackson wrote:
> > FAOD, I think you should expect people to declare the linker symbols
> > either as I suggested:
> >
> > extern const struct wombat _wombats_start[];
> > exter
>>> On 12.02.19 at 12:26, wrote:
> Jan, are you investigating this regression ?
No, I'm not. I've said what I can say in a reply to an earlier bisection
report (from Dec 12th), attached again here for reference.
Jan
> osstest service owner writes ("[linux-3.18 bisection] complete
> test-amd64-
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the vmx_vmexit_handler() code
that checks if the guest has the ability to sw
I would particularly welcome the opinion of hypervisor maintainers on
my type safety point, below.
Stefano Stabellini writes ("[Xen-devel] [PATCH v9 2/5] xen: introduce
SYMBOLS_SUBTRACT and SYMBOLS_COMPARE"):
> +/*
> + * Calculate (end - start), where start and/or end are linker symbols,
> + * r
flight 133192 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133192/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
>>> On 12.02.19 at 13:01, wrote:
> I would particularly welcome the opinion of hypervisor maintainers on
> my type safety point, below.
I agree with the requirements you put forward; I think I'd
prefer the inline function versions I had suggested (or
something similar) over macros though, not the
>>> On 28.01.19 at 08:06, wrote:
> @@ -213,21 +214,25 @@ static void microcode_fini_cpu(unsigned int cpu)
> bool save_patch(struct microcode_patch *new_patch)
> {
> struct microcode_patch *microcode_patch;
> +enum microcode_match_result result = MIS_UCODE;
> +bool ret;
> +unsign
>>> On 12.02.19 at 12:42, wrote:
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).
>
> This can lead to domain crashes in the vmx_vmexit_handler() code
>
On 2/12/19 2:57 PM, Jan Beulich wrote:
On 12.02.19 at 12:42, wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the
>>> On 08.02.19 at 14:44, wrote:
> @@ -813,6 +817,13 @@ int set_global_virq_handler(struct domain *d, uint32_t
> virq)
>
> if (virq >= NR_VIRQS)
> return -EINVAL;
> +
> + /*
> +* Make sure the guest controlled value virq is bounded even during
> +* speculative execution.
>>> On 08.02.19 at 14:44, wrote:
> When interacting with io apic, a guest can specify values that are used
> as index to structures, and whose values are not compared against
> upper bounds to prevent speculative out-of-bound accesses. This change
> prevents these speculative accesses.
>
> Furthe
flight 133141 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
> >>> On 28.01.19 at 08:06, wrote:
> > @@ -314,9 +310,7 @@ static int apply_microcode(unsigned int cpu)
> >
> > mc_intel = patch->data;
> > BUG_ON(!mc_intel);
> > -
> > -/* serialize access to the physical write to MSR 0x
>>> On 08.02.19 at 14:44, wrote:
> @@ -3453,7 +3456,8 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t
> *msr_content)
> if ( (index / 2) >=
> MASK_EXTR(v->arch.hvm.mtrr.mtrr_cap, MTRRcap_VCNT) )
> goto gp_fault;
> -*msr_content = var_range_base
flight 133142 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133142/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
>>> On 08.02.19 at 14:44, wrote:
> To control the runtime behavior on L1TF vulnerable platforms better, the
> command line option l1tf-barrier is introduced. This option controls
> whether on vulnerable x86 platforms the lfence instruction is used to
> prevent speculative execution from bypassing
>>> On 08.02.19 at 14:44, wrote:
> --- /dev/null
> +++ b/xen/include/asm-x86/nospec.h
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
> */
> +
> +#ifndef _ASM_X86_NOSPEC_H
> +#define _ASM_X86_NOSPEC_H
> +
>
Hi, George,
I found Credit2 can’t reach the throughput as expected under my test workload,
compared to Credit and CFS. It is easy to reproduce, and I think the problem is
really exist.
It really took me a long time to find out why due to my lack of knowledge, and
I cannot find a good way to sol
>>> On 12.02.19 at 14:25, wrote:
> On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
>> >>> On 28.01.19 at 08:06, wrote:
>> > @@ -314,9 +310,7 @@ static int apply_microcode(unsigned int cpu)
>> >
>> > mc_intel = patch->data;
>> > BUG_ON(!mc_intel);
>> > -
>> > -/* seria
On 2/12/19 14:25, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> @@ -3453,7 +3456,8 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t
>> *msr_content)
>> if ( (index / 2) >=
>> MASK_EXTR(v->arch.hvm.mtrr.mtrr_cap, MTRRcap_VCNT) )
>> goto gp_faul
>>> On 08.02.19 at 14:44, wrote:
> Checks of domain properties, such as is_hardware_domain or is_hvm_domain,
> might be bypassed by speculatively executing these instructions. A reason
> for bypassing these checks is that these macros access the domain
> structure via a pointer, and check a certai
>>> On 08.02.19 at 14:44, wrote:
> --- /dev/null
> +++ b/xen/include/asm-x86/nospec.h
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
> */
> +
> +#ifndef _ASM_X86_NOSPEC_H
> +#define _ASM_X86_NOSPEC_H
> +
>
>>> On 12.02.19 at 15:05, wrote:
> On 2/12/19 14:25, Jan Beulich wrote:
> On 08.02.19 at 14:44, wrote:
>>> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
>>> if ( a.index >= HVM_NR_PARAMS )
>>> return -EINVAL;
>>>
>>> +/*
>>> + * Make sure the guest controlled valu
>>> On 08.02.19 at 14:44, wrote:
> @@ -33,10 +34,11 @@ unsigned long __read_mostly pdx_group_valid[BITS_TO_LONGS(
>
> bool __mfn_valid(unsigned long mfn)
> {
> -return likely(mfn < max_page) &&
> - likely(!(mfn & pfn_hole_mask)) &&
> - likely(test_bit(pfn_to_pdx(mfn) /
flight 133144 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133144/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
Jan Beulich writes ("Re: [Xen-devel] [PATCH v9 2/5] xen: introduce
SYMBOLS_SUBTRACT and SYMBOLS_COMPARE"):
> On 12.02.19 at 13:01, wrote:
> > I would particularly welcome the opinion of hypervisor maintainers on
> > my type safety point, below.
>
> I agree with the requirements you put forward;
Summary:
7b8052e19304 which is a backport to linux-3.18 of be06998f96ec has
been found by the Xen CI auto-bisector to be responsible for a
regression booting under Xen.
Jan Beulich writes ("Re: [linux-3.18 bisection] complete
test-amd64-amd64-pair"):
> No, I'm not. I've said what I can say in
>>> On 12.02.19 at 02:13, wrote:
> --- a/xen/include/xen/types.h
> +++ b/xen/include/xen/types.h
> @@ -52,7 +52,8 @@ typedef __u32 __be32;
> typedef __u64 __le64;
> typedef __u64 __be64;
>
> -typedef unsigned int __attribute__((__mode__(__pointer__))) uintptr_t;
> +typedef unsigned long __attr
Jan Beulich writes ("Re: [PATCH v9 1/5] xen: introduce ptrdiff_t, fix
uintptr_t"):
> On 12.02.19 at 02:13, wrote:
> > -typedef unsigned int __attribute__((__mode__(__pointer__))) uintptr_t;
> > +typedef unsigned long __attribute__((__mode__(__pointer__))) uintptr_t;
>
> I don't understand this c
flight 133195 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133195/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On 12/02/2019 15:26, Ian Jackson wrote:
>
>> But if we really want to have ptrdiff_t, then I think we should either
>> follow the uintptr_t model and use attribute((mode())), or we should
>> leverage the compiler's __PTRDIFF_TYPE__ (and then also
>> __UINTPTR_TYPE__ for uintptr_t, at least if avail
>>> On 12.02.19 at 15:47, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v9 2/5] xen: introduce
> SYMBOLS_SUBTRACT and SYMBOLS_COMPARE"):
>> On 12.02.19 at 13:01, wrote:
>> > I would particularly welcome the opinion of hypervisor maintainers on
>> > my type safety point, below.
>>
>> I ag
>>> On 12.02.19 at 16:26, wrote:
> Jan Beulich writes ("Re: [PATCH v9 1/5] xen: introduce ptrdiff_t, fix
> uintptr_t"):
>> On 12.02.19 at 02:13, wrote:
>> > -typedef unsigned int __attribute__((__mode__(__pointer__))) uintptr_t;
>> > +typedef unsigned long __attribute__((__mode__(__pointer__)))
On Tue, Feb 12, 2019 at 02:54:41PM +, Ian Jackson wrote:
Summary:
7b8052e19304 which is a backport to linux-3.18 of be06998f96ec has
been found by the Xen CI auto-bisector to be responsible for a
regression booting under Xen.
Jan Beulich writes ("Re: [linux-3.18 bisection] complete
test-am
Jan Beulich writes ("Re: [Xen-devel] [PATCH v9 2/5] xen: introduce
SYMBOLS_SUBTRACT and SYMBOLS_COMPARE"):
> On 12.02.19 at 15:47, wrote:
> > I didn't see your proposed inline function, but don't think it can
> > work correctly because it won't be type-generic. Ie, the requirement
> > is to use
>>> On 12.02.19 at 16:32, wrote:
> On 12/02/2019 15:26, Ian Jackson wrote:
>>
>>> But if we really want to have ptrdiff_t, then I think we should either
>>> follow the uintptr_t model and use attribute((mode())), or we should
>>> leverage the compiler's __PTRDIFF_TYPE__ (and then also
>>> __UINTPT
flight 133143 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On Wed, 2019-01-09 at 11:11 +0200, Razvan Cojocaru wrote:
>
> On 1/8/19 6:47 PM, Jan Beulich wrote:
> > > > > On 08.01.19 at 17:37, wrote:
> > >
> > > On 1/8/19 6:27 PM, Jan Beulich wrote:
> > > > > > > On 19.12.18 at 19:52, wrote:
> > > > >
> > > > > Signed-off-by: Petre Pircalabu
> > > >
>
On Thu, Feb 7, 2019 at 9:06 AM Petre Ovidiu PIRCALABU
wrote:
>
> On Thu, 2019-02-07 at 11:46 +, George Dunlap wrote:
> > On 2/6/19 2:26 PM, Petre Ovidiu PIRCALABU wrote:
> > > On Wed, 2018-12-19 at 20:52 +0200, Petre Pircalabu wrote:
> > > > This patchset is a rework of the "multi-page ring bu
>>> On 12.02.19 at 17:57, wrote:
> On Wed, 2019-01-09 at 11:11 +0200, Razvan Cojocaru wrote:
>>
>> On 1/8/19 6:47 PM, Jan Beulich wrote:
>> > > > > On 08.01.19 at 17:37, wrote:
>> > >
>> > > On 1/8/19 6:27 PM, Jan Beulich wrote:
>> > > > > > > On 19.12.18 at 19:52, wrote:
>> > > > >
>> > > >
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov wrote:
>
> On 23.01.2019 14:03, Kees Cook wrote:
> > This adds a new plugin "stackinit" that attempts to perform unconditional
> > initialization of all stack variables
>
> Hello Kees! Hello everyone!
>
> I was curious about the performance impact of
On Tue, Jan 8, 2019 at 9:39 AM Razvan Cojocaru
wrote:
>
> On 1/8/19 6:27 PM, Jan Beulich wrote:
> On 19.12.18 at 19:52, wrote:
> >> Signed-off-by: Petre Pircalabu
> >
> > An empty description is not helpful. The immediate question is: Why?
> > We don't do this for other interface versions.
On 2/12/19 8:13 PM, Tamas K Lengyel wrote:
> On Tue, Jan 8, 2019 at 9:39 AM Razvan Cojocaru
> wrote:
>>
>> On 1/8/19 6:27 PM, Jan Beulich wrote:
>> On 19.12.18 at 19:52, wrote:
Signed-off-by: Petre Pircalabu
>>>
>>> An empty description is not helpful. The immediate question is: Why?
>>
Hello Julien,
On 07.02.19 12:59, Julien Grall wrote:
In that case I would prefer if we don't keep the runstate mapped.
Actually I'm going to see runstate update impact on the context switch time.
For that I will extend TBM with runstate setup.
I really do not like a bunch of `copy_to_guest()`
Hello Roger,
Sorry for a delayed response.
On 07.02.19 12:35, Roger Pau Monné wrote:
I've been thinking about this with other Citrix folks, and I'm not
sure the proposed patch is a good solution. It's not possible for us
to know whether there's a kernel somewhere relying on changing the
virtual
On Tue, Feb 12, 2019 at 11:20 AM Razvan Cojocaru
wrote:
>
> On 2/12/19 8:13 PM, Tamas K Lengyel wrote:
> > On Tue, Jan 8, 2019 at 9:39 AM Razvan Cojocaru
> > wrote:
> >>
> >> On 1/8/19 6:27 PM, Jan Beulich wrote:
> >> On 19.12.18 at 19:52, wrote:
> Signed-off-by: Petre Pircalabu
> >>>
flight 133200 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133200/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 133148 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133148/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3103389043bd7389fd7cef3eb291a2150af8b929
baseline version:
ovmf 2a784a2cc356df5a8958a
Hi,
Sorry for the formatting.
On Tue, Feb 12, 2019 at 12:26 PM Ian Jackson wrote:
> I don't have a good plan about what to do next. I guess one thing we
> could do would be to ask Yogesh to reflash the firmware on laxton0 and
> see if that helps.
>
> I think this issue is likely to be a protrac
Julien Grall writes ("Re: [Xen-devel] arm64, laxton[01] (was Re:
[xen-unstable-smoke test] 133030: trouble: blocked/broken/pass)"):
> On Tue, Feb 12, 2019 at 12:26 PM Ian Jackson wrote:
> > I don't have a good plan about what to do next. I guess one thing we
> > could do would be to ask Yogesh t
On Tue, 12 Feb 2019, 19:21 Andrii Anisov, wrote:
> Hello Julien,
>
Hi,
Sorry for the formatting.
> On 07.02.19 12:59, Julien Grall wrote:
> > In that case I would prefer if we don't keep the runstate mapped.
>
> Actually I'm going to see runstate update impact on the context switch
> time. Fo
Ian Jackson writes ("Re: [Xen-devel] arm64, laxton[01] (was Re:
[xen-unstable-smoke test] 133030: trouble: blocked/broken/pass)"):
> And that part works. It runs through d-i and thinks it has succeeded.
> But then when the host reboots it reboots into 3.16, not the backports
> kernel.
>
> Lookin
flight 133145 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133145/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On 2/4/19 5:19 AM, Paul Durrant wrote:
> The current use of get/set_field_from/in_reg_u32() is both inefficient and
> requires some ugly casting.
>
> This patch defines a new bitfield structure (amd_iommu_pte) and uses this
> structure in all PTE/PDE manipulation, resulting in much more readable
>
On 2/4/19 5:19 AM, Paul Durrant wrote:
> The current use of get/set_field_from/in_reg_u32() is both inefficient and
> requires some ugly casting.
>
> This patch defines a new bitfield structure (amd_iommu_dte) and uses this
> structure in all DTE manipulation, resulting in much more readable and
>
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/xen/xen-pciback/xenbus.c: In function ‘xen_pcibk_frontend_changed’:
drivers/xen/xen-pciback/xenbus.c:545:6: warning: this statement may fall
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/xen/xen-scsiback.c: In function ‘scsiback_frontend_changed’:
drivers/xen/xen-scsiback.c:1185:6: warning: this statement may fall through
[-
flight 133204 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133204/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 133147 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133147/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
On Tue, Feb 12, 2019 at 02:37:20PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/xen/xen-pciback/xenbus.c: In function ‘xen_pcibk_frontend_c
On Tue, 12 Feb 2019, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce
> SYMBOL"):
> > On Thu, 7 Feb 2019, Ian Jackson wrote:
> > > FAOD, I think you should expect people to declare the linker symbols
> > > either as I suggested:
> > >
> > > exter
On Tue, 12 Feb 2019, Jan Beulich wrote:
> >>> On 12.02.19 at 02:13, wrote:
> > --- a/xen/include/xen/types.h
> > +++ b/xen/include/xen/types.h
> > @@ -52,7 +52,8 @@ typedef __u32 __be32;
> > typedef __u64 __le64;
> > typedef __u64 __be64;
> >
> > -typedef unsigned int __attribute__((__mode__(_
flight 133207 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133207/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On 2/12/19 5:50 PM, Boris Ostrovsky wrote:
> On Tue, Feb 12, 2019 at 02:37:20PM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> This patch fixes the following warning:
>>
>> drivers/xen/xen-
On Tue, 12 Feb 2019, Jan Beulich wrote:
> >>> On 12.02.19 at 13:01, wrote:
> > I would particularly welcome the opinion of hypervisor maintainers on
> > my type safety point, below.
>
> I agree with the requirements you put forward; I think I'd
> prefer the inline function versions I had suggeste
> On Feb 11, 2019, at 05:05, Lars Kurth wrote:
>
> Hi all,
>
> we have the community call for February coming up this Wednesday. My sincere
> apologies, that I have not asked for agenda items last week. A current agenda
> (primarily a skeleton) is available at
> https://docs.google.com/docu
On Tue, Feb 12, 2019 at 06:55:20AM -0700, Jan Beulich wrote:
On 12.02.19 at 14:25, wrote:
>> On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
>>> >>> On 28.01.19 at 08:06, wrote:
>>> > @@ -314,9 +310,7 @@ static int apply_microcode(unsigned int cpu)
>>> >
>>> > mc_intel =
Greetings,
On the 11/14/18 Xen x86 community call a discussion was initiated about
using Kconfig to build minimized versions of Xen for security, safety
and other certification requirements. After some offline discussions
with Xen contributors I realized that a variety of efforts each with
their o
From: Wen Yang
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() functi
From: Wen Yang
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could be null
(see line 357)
drivers/xen/pvcalls-front.c
351 static int
From: Wen Yang
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() functi
From: Wen Yang
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could be null
(see line 357)
drivers/xen/pvcalls-front.c
351 static int
flight 133212 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133212/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
flight 133150 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133150/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
Konrad,
Starting w/ v4.17, I cannot log in to GNOME w/out getting the
following mess in dmesg and ending up back at the GDM login screen.
[ 28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
[ 31.219821] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[ 31.22
flight 133217 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133217/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
On 13/02/2019 00:50, Boris Ostrovsky wrote:
> On Tue, Feb 12, 2019 at 02:37:20PM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> This patch fixes the following warning:
>>
>> drivers/xen/xen-p
Hi Lars,
The title says "16:00 - 17:00 UTC" but the text below says "15:00 - 16:00
UTC". Can you confirm what time is the meeting?
Cheers,
On Mon, 11 Feb 2019, 11:07 Lars Kurth, wrote:
> Hi all,
>
>
> we have the community call for February coming up this Wednesday. My
> sincere apologies, th
Sorry the formatting.
On Tue, 12 Feb 2019, 20:26 Ian Jackson, wrote:
> Ian Jackson writes ("Re: [Xen-devel] arm64, laxton[01] (was Re:
> [xen-unstable-smoke test] 133030: trouble: blocked/broken/pass)"):
> > And that part works. It runs through d-i and thinks it has succeeded.
> > But then when
flight 133151 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133151/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On Wed, Feb 6, 2019 at 2:31 AM Roger Pau Monné wrote:
>
> On Wed, Feb 06, 2019 at 12:55:08AM -0800, Christopher Clark wrote:
> > Document provides a brief introduction to the Argo interdomain
> > communication mechanism and a detailed description of the granular
> > locking used within the Argo im
>>> On 13.02.19 at 03:30, wrote:
> On Tue, Feb 12, 2019 at 06:55:20AM -0700, Jan Beulich wrote:
> On 12.02.19 at 14:25, wrote:
>>> On Tue, Feb 12, 2019 at 05:51:41AM -0700, Jan Beulich wrote:
>>> On 28.01.19 at 08:06, wrote:
> @@ -314,9 +310,7 @@ static int apply_microcode(unsigned
flight 133219 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133219/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
Regressions wh
95 matches
Mail list logo
