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
>>> 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
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
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
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
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,
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:
>>
>>
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
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)
[
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
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
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
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()
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
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()
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
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 =
> 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
>
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
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:
>>
>>
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
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
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:
> > >
> > >
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
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
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
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
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
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
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
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
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.
>
>
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.
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
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
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
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
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
> >>>
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
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
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?
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 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
>>> 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 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
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
> > > >
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 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
>>>
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 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
>>> 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 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
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
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
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
>>> 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
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
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;
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
>>> 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) /
>>> 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
>>> 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 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
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
>>> 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);
>> > -
>> > -/*
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
>>> 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 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
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:
> @@ -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 =
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
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 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.
>
>
>>> 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
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 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 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;
> +
>>> 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
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
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,
> + *
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
>>> 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
>
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[];
> >
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
>
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
>>> 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
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 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
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
>
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
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,
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
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/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
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
95 matches
Mail list logo
