>>> On 18.05.19 at 00:31, wrote:
> Don't hardcode old versions of configure in the source code, instead
> let's just use autoconf to generate them.
>
> Signed-off-by: Alistair Francis
For the record - I strongly disagree to this unless there's a general
movement in GNU projects towards such a m
>>> On 17.05.19 at 20:50, wrote:
> 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
Acked-by: Jan Beulich
_
flight 136477 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136477/
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 17.05.19 at 21:17, wrote:
> 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 wit
>>> On 17.05.19 at 20:58, wrote:
> Reflow the ZynqMP message for grepability, and fix the omission of a newline.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with two remarks:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -105,6 +105,17 @@ debugtrace_printk(con
>>> On 17.05.19 at 20:58, wrote:
> 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 li
On Fri, May 17, 2019 at 06:05:55PM +0100, Wei Liu wrote:
> 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 fi
> > Mean that result of "(int64_t)vaddr >> 63" can be 0 or 1.
> > So the next code may not work properly in case of another 'implementations'.
> > With another compiler (i.e. clang, etc) this code may introduce bugs
> > which are hard to find.
> >
> > ((int64_t)vaddr >> 47) == ((int64_t)vaddr >> 63
On 20/05/2019 10:14, Roger Pau Monné wrote:
>
>> diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
>> index 448a2af8fd..fe1f9c2ff8 100644
>> --- a/tools/libxl/libxl_mem.c
>> +++ b/tools/libxl/libxl_mem.c
>> @@ -457,6 +457,24 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
>> libxl
On 20/05/2019 10:17, Viktor Mitin wrote:
>>> Mean that result of "(int64_t)vaddr >> 63" can be 0 or 1.
>>> So the next code may not work properly in case of another 'implementations'.
>>> With another compiler (i.e. clang, etc) this code may introduce bugs
>>> which are hard to find.
>>>
>>> ((int6
On Mon, May 20, 2019 at 10:19:26AM +0100, Andrew Cooper wrote:
> On 20/05/2019 10:14, Roger Pau Monné wrote:
> >
> >> diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
> >> index 448a2af8fd..fe1f9c2ff8 100644
> >> --- a/tools/libxl/libxl_mem.c
> >> +++ b/tools/libxl/libxl_mem.c
> >> @@
>>> On 20.05.19 at 11:17, wrote:
>> > Mean that result of "(int64_t)vaddr >> 63" can be 0 or 1.
>> > So the next code may not work properly in case of another
> 'implementations'.
>> > With another compiler (i.e. clang, etc) this code may introduce bugs
>> > which are hard to find.
>> >
>> > ((in
On Mon, May 20, 2019 at 12:22 PM Andrew Cooper
wrote:
>
> On 20/05/2019 10:17, Viktor Mitin wrote:
> >>> Mean that result of "(int64_t)vaddr >> 63" can be 0 or 1.
> >>> So the next code may not work properly in case of another
> >>> 'implementations'.
> >>> With another compiler (i.e. clang, etc)
On 20/05/2019 10:37, Viktor Mitin wrote:
> On Mon, May 20, 2019 at 12:22 PM Andrew Cooper
> wrote:
>> On 20/05/2019 10:17, Viktor Mitin wrote:
> Mean that result of "(int64_t)vaddr >> 63" can be 0 or 1.
> So the next code may not work properly in case of another
> 'implementations'.
>
Hi Viktor,
Is there any specific reason I ended up to be CCed in a middle of an x86 thread?
Cheers,
On 20/05/2019 10:17, Viktor Mitin wrote:
Mean that result of "(int64_t)vaddr >> 63" can be 0 or 1.
So the next code may not work properly in case of another 'implementations'.
With another compi
> > For this reason it is better to avoid implementation-defined code.
> Well, ideally we'd like to get away without using implementation
> defined behavior. But I'm afraid we're quite far from that, and
> we'd not always be willing to accept the worse source and/or
> binary
Hi Julien,
Added by mistake, sorry about that.
Thanks
On Mon, May 20, 2019 at 12:49 PM Julien Grall wrote:
>
> Hi Viktor,
>
> Is there any specific reason I ended up to be CCed in a middle of an x86
> thread?
>
> Cheers,
>
> On 20/05/2019 10:17, Viktor Mitin wrote:
> >>> Mean that result of "(
Hi Alistair,
On 17/05/2019 23:01, Alistair Francis wrote:
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 archit
On 5/20/19 9:05 AM, Jan Beulich wrote:
On 18.05.19 at 00:31, wrote:
>> Don't hardcode old versions of configure in the source code, instead
>> let's just use autoconf to generate them.
>>
>> Signed-off-by: Alistair Francis
>
> For the record - I strongly disagree to this unless there's a ge
flight 136480 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
136321
Tests which did n
Lightweight Profiling was introduced in Bulldozer (Fam15h), but was dropped
from Zen (Fam17h) processors. Furthermore, LWP was dropped from Fam15/16 CPUs
when IBPB for Spectre v2 was introduced in microcode, owing to LWP not being
used in practice.
As a result, CPUs which are operating within spe
This started out as just patch 3, trying to clean up the remains of the
pv-l1tf debugging, and expanded a little upon reading the surrounding code.
Andrew Cooper (4):
x86/pv: Fix error handling in dom0_construct_pv()
x86/boot: Rename dom0_{pvh,verbose} variables to have an opt_ prefix
x86/bo
We currently have an asymmetric setup where CONFIG_VERBOSE_DEBUG controls
extra diagnostics for a PV dom0, and opt_dom0_verbose controls extra
diagnostics for a PVH dom0.
Default opt_dom0_verbose to CONFIG_VERBOSE_DEBUG and use opt_dom0_verbose
consistently.
Signed-off-by: Andrew Cooper
---
CC:
This would have been very handy when debugging some pv-l1tf issues. As there
is no cost to supporting it, wire it up.
Due to the way dom0 is constructed, switching into shadow mode must be done
after the pagetables are written, and because of partially being in dom0
context, shadow_enable() doesn
For consistency with other command line options.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/dom0_build.c | 12 ++--
xen/arch/x86/hvm/dom0_build.c | 2 +-
xen/arch/x86/setup.c | 2 +-
xen/inclu
One path in dom0_construct_pv() returns -1 unlike all other error paths.
Switch it to returning -EINVAL.
This was last modified by c/s c84481fb XSA-55, but the bug predates that
series. However, this patch did (for no obvious reason) introduce a
bifurcated tail to the function with two subtly dif
osstest service owner writes ("[xen-4.11-testing test] 136385: regressions -
FAIL"):
> flight 136385 xen-4.11-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/136385/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
On 17/05/2019 07:47, Viktor Mitin wrote:
On Thu, May 16, 2019 at 06:40:14PM +0100, Julien Grall wrote:
No need to resend the patch, I can do the modification when I will commit the
patch.
Hi Julien,
Hi,
Thank you for detailed description provided.
Will take into consideration all the
This has been true for some time. osstest has been sending automatic
mails including bisection reports like the one below, for about a
month.
osstest's "tested and good" branch of linux-3.18 is 190 days behind
the upstream tip.
Do we care about this at all ?
Note that the Xen Project does not h
On 19/05/2019 19:46, Eitan Kaplan wrote:
> Hi all,
>
> I am a computer engineering student at Columbia University. This is my
> first time writing to this list (please let me know if this isn't the
> place for this type of question!).
This is indeed the correct place for this kind of question.
>
On 19/05/2019 19:46, Eitan Kaplan wrote:
> Hi all,
>
> I am a computer engineering student at Columbia University. This is my
> first time writing to this list (please let me know if this isn't the
> place for this type of question!).
(Apologies for the repost - I accidentally dropped the CC list
Hi,
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Linux 5.1 uses a completely different implementation for
of_count_phandle_with_args. So which version of Linux did you
> > Thank you for detailed description provided.
> > Will take into consideration all the notes.
>
> Does it mean you are happy with the commit message I suggested?
Yes, I'm happy with the commit message you suggested.
Please let me know if I should resend the updated patch.
Thanks
_
On 20/05/2019 12:46, Ian Jackson wrote:
> This has been true for some time. osstest has been sending automatic
> mails including bisection reports like the one below, for about a
> month.
>
> osstest's "tested and good" branch of linux-3.18 is 190 days behind
> the upstream tip.
>
> Do we care a
>>> On 20.05.19 at 12:30, wrote:
> osstest service owner writes ("[xen-4.11-testing test] 136385: regressions -
> FAIL"):
>> flight 136385 xen-4.11-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/136385/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are bl
On Fri, May 17, 2019 at 04:48:21AM -0600, Jan Beulich wrote:
> 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 interrup
>>> On 20.05.19 at 12:13, wrote:
> Lightweight Profiling was introduced in Bulldozer (Fam15h), but was dropped
> from Zen (Fam17h) processors. Furthermore, LWP was dropped from Fam15/16 CPUs
> when IBPB for Spectre v2 was introduced in microcode, owing to LWP not being
> used in practice.
>
> As
On Mon, May 20, 2019 at 11:46:16AM +0100, Ian Jackson wrote:
> This has been true for some time. osstest has been sending automatic
> mails including bisection reports like the one below, for about a
> month.
>
> osstest's "tested and good" branch of linux-3.18 is 190 days behind
> the upstream t
On Fri, May 17, 2019 at 04:51:50AM -0600, Jan Beulich wrote:
> 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
Reviewed-by: Roger Pau Monné
I think a macro or helper wou
On 20/05/2019 07:55, Jan Beulich wrote:
On 17.05.19 at 18:50, wrote:
>> 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 f
On 18/03/2019 09:55, Jan Beulich wrote:
On 15.03.19 at 19:21, wrote:
>> On 15/03/2019 10:41, Jan Beulich wrote:
>>> @@ -6681,6 +6681,12 @@ x86_emulate(
>>> case X86EMUL_OPC_EVEX_66(0x0f, 0xf6): /* vpsadbw
>>> [xyz]mm/mem,[xyz]mm,[xyz]mm */
>>> generate_exception_if(evex.opmsk,
Hi,
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good example here is arch timer node for R-Ca
Hi,
On 20/05/2019 12:09, Viktor Mitin wrote:
Thank you for detailed description provided.
Will take into consideration all the notes.
Does it mean you are happy with the commit message I suggested?
Yes, I'm happy with the commit message you suggested.
Please let me know if I should resend th
On 20/05/2019 12:40, Jan Beulich wrote:
On 20.05.19 at 12:13, wrote:
>> Lightweight Profiling was introduced in Bulldozer (Fam15h), but was dropped
>> from Zen (Fam17h) processors. Furthermore, LWP was dropped from Fam15/16
>> CPUs
>> when IBPB for Spectre v2 was introduced in microcode, ow
Jan Beulich writes ("Re: [xen-4.11-testing test] 136385: regressions - FAIL"):
> On 20.05.19 at 12:30, wrote:
> > osstest service owner writes ("[xen-4.11-testing test] 136385: regressions
> > -
> >> test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail
> >> REGR. vs. 135683
> >
Thiis is done so hvmemul_linear_to_phys() can be called from
hvmemul_send_vm_event().
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/emulate.c | 181 ++---
1 file changed, 90 insertions(+), 91 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/
This patch aims to have mem access vm events sent from the emulator.
This is useful in the case of emulated instructions that cause
page-walks on access protected pages.
We use hvmemul_map_linear_addr() ro intercept r/w access and
hvmemul_insn_fetch() to intercept exec access.
First we try to sen
Hi,
First of all, please add a cover letter when you send a series. This help for
threading and also a place to commend on general feedback.
Furthermore, please use scripts/{add, get}_maintainers.pl to find the correct
maintainers. While I agree that CCing REST is a good idea, you haven't CCe
Ian Jackson writes ("Re: [xen-4.11-testing test] 136385: regressions - FAIL"):
> You are right. Hrrrm. I will investigate further.
This seems to be Debian mirror skew. I hope it's an isolated
incident, or I'll have to change which Debian mirror we use.
Ian.
___
Hi Julien,
Julien Grall writes:
> Hi,
>
> First of all, please add a cover letter when you send a series. This
> help for threading and also a place to commend on general feedback.
Oh, okay. That was quite simple change and I didn't wanted to spam with
extra emails. I will include cover letter n
On 20.05.19 14:03, Julien Grall wrote:
Hi,
Hi, Julien
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Linux 5.1 uses a completely different implementation for
of_co
Wei Liu writes ("[PATCH] libxl: fix libxl_domain_need_memory after
899433f149d"):
> 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_s
>>> On 20.05.19 at 13:41, wrote:
> On Mon, May 20, 2019 at 11:46:16AM +0100, Ian Jackson wrote:
>> This has been true for some time. osstest has been sending automatic
>> mails including bisection reports like the one below, for about a
>> month.
>>
>> osstest's "tested and good" branch of linux
On Fri, May 17, 2019 at 04:52:32AM -0600, Jan Beulich wrote:
> Use valid_irq_vector() rather than "> 0".
>
> Also replace an open-coded use of IRQ_VECTOR_UNASSIGNED.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
The question I have below is not directly related to the usage of
v
On Fri, May 17, 2019 at 04:52:54AM -0600, Jan Beulich wrote:
> 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
Reviewe
On 20/05/2019 14:50, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: fix libxl_domain_need_memory after
> 899433f149d"):
>> 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
On 17/05/2019 11:11, Jan Beulich wrote:
> 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.
>
> Fu
I looked into these changes after a while again. I will split this
larger commit into smaller ones, and address parts of the problem in
each of them separately.
On 3/29/19 18:11, Jan Beulich wrote:
On 14.03.19 at 13:50, wrote:
>> Guests can issue grant table operations and provide guest cont
Hi,
On 20/05/2019 14:41, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi,
First of all, please add a cover letter when you send a series. This
help for threading and also a place to commend on general feedback.
Oh, okay. That was quite simple change and I didn't wanted to spam with
extra em
Hi Ian,
On 20/05/2019 11:30, Ian Jackson wrote:
osstest service owner writes ("[xen-4.11-testing test] 136385: regressions -
FAIL"):
flight 136385 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136385/
Regressions :-(
Tests which did not succeed and are blockin
On 20/05/2019 14:48, Oleksandr wrote:
On 20.05.19 14:03, Julien Grall wrote:
Hi,
Hi, Julien
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Linux 5.1 uses a compl
Mostly due to x86 and acpi conversion, several documentation
links are still pointing to the old file. Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/acpi/dsd/leds.txt | 2 +-
Documentation/admin-guide/kernel-parameters.rst | 6 +++---
Documentation/admin-gu
flight 136484 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136484/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 124921
test-amd64-amd64-xl-qe
Julien Grall writes:
> Hi,
>
> On 20/05/2019 14:41, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>
>>> Hi,
>>>
>>> First of all, please add a cover letter when you send a series. This
>>> help for threading and also a place to commend on general feedback.
>> Oh, okay. That was quite simple c
Hi,
On 10/05/2019 14:25, Julien Grall wrote:
On 10/05/2019 14:24, Jan Beulich wrote:
On 10.05.19 at 15:02, wrote:
On 10/05/2019 12:35, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -474,7 +474,8 @@ static
On Mon, May 20, 2019 at 11:47:39AM -0300, Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Thanks, didn't notice that.
> Documentation/i2c/instantiating-dev
Hi Stefano,
On 17/04/2019 18:27, Stefano Stabellini wrote:
On Wed, 17 Apr 2019, Julien Grall wrote:
Hi,
On 17/04/2019 18:12, Stefano Stabellini wrote:
On Tue, 16 Apr 2019, Julien Grall wrote:
Hi Stefano,
On 4/16/19 10:51 PM, Stefano Stabellini wrote:
On Mon, 28 Jan 2019, Julien Grall wrote
>>> On 20.05.19 at 13:40, wrote:
> On Fri, May 17, 2019 at 04:48:21AM -0600, Jan Beulich wrote:
>> 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,
Common use of the CPUID instruction operates without side effects. Let the
compiler better optimise code by dropping the volatile qualifier.
The only place where order matters is for Intel microcode loading, where
executing a CPUID instruction is used for its side effect of updating
MSR_IA32_UCOD
>>> On 20.05.19 at 16:04, wrote:
> On Fri, May 17, 2019 at 04:52:32AM -0600, Jan Beulich wrote:
>> Use valid_irq_vector() rather than "> 0".
>>
>> Also replace an open-coded use of IRQ_VECTOR_UNASSIGNED.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Roger Pau Monné
Thanks.
> The questio
Ian Jackson (4):
mg-repro-setup: Do all builds in their own tasks, regardless
mg-transient-task: New utility
mg-repro-setup: Introduce `statictask' variable
mg-repro-setup: New mode --autoalloc
mg-repro-setup| 45 +
mg-transient-task | 32 ++
In case OSSTEST_TASK was set by the caller, unset it. Unsetting it
will cause each sg-run-job (inside mg-execute-task) to become its own
task.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mg-repro-setup b/mg-repro-setup
inde
We are going to make a mode where we don't set OSSTEST_TASK. The
result is that our subprocesses will do whatever they usually do.
Those are mg-allocate (which would allocate for our static task) and
mg-execute-flight which will make a dynamic task. We must therefore
prevent mg-allocate from run
Will be useful in combination with new mode(s) of mg-repro-setup.
Signed-off-by: Ian Jackson
---
mg-transient-task | 32
1 file changed, 32 insertions(+)
create mode 100755 mg-transient-task
diff --git a/mg-transient-task b/mg-transient-task
new file mode 10075
This just involves turning autoalloc on and statictask off.
It is most useful with mg-transient-task, as documented.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index b60389d8..e
>>> On 20.05.19 at 17:26, wrote:
> Common use of the CPUID instruction operates without side effects. Let the
> compiler better optimise code by dropping the volatile qualifier.
>
> The only place where order matters is for Intel microcode loading, where
> executing a CPUID instruction is used f
On 17/05/2019, 01:34, "Jan Beulich" wrote:
>>> 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
> > +# --
Julien Grall writes ("Re: [xen-4.11-testing test] 136385: regressions - FAIL"):
> Before the last 2 flights, the kernel was compiled natively. Now it is
> cross-compiled on x86 machine. So there are a difference in the way the
> kernel
> is built.
That is indeed suspicious.
> Could we try a fl
On 20.05.19 15:25, Julien Grall wrote:
Hi,
Hi, Julien.
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property i
On 20/05/2019 17:10, Oleksandr wrote:
On 20.05.19 15:25, Julien Grall wrote:
Hi,
Hi, Julien.
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes
This is going in the right direction IMO.
Lars Kurth writes ("Re: [PATCH] Add TRACKING.IMPORTS to xen.git to more easily
manage imported files that need to be kept in sync with an upstream"):
> That makes perfect sense now. In that case, I tend to agree that "auto" is
> probably not needed. Woul
On Mon, May 20, 2019 at 1:05 AM Jan Beulich wrote:
>
> >>> On 18.05.19 at 00:31, wrote:
> > Don't hardcode old versions of configure in the source code, instead
> > let's just use autoconf to generate them.
> >
> > Signed-off-by: Alistair Francis
>
> For the record - I strongly disagree to this
Hi, Julien
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good example here is arch timer
flight 136618 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136618/
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 20/05/2019, 10:37, "Ian Jackson" wrote:
This is going in the right direction IMO.
Lars Kurth writes ("Re: [PATCH] Add TRACKING.IMPORTS to xen.git to more
easily manage imported files that need to be kept in sync with an upstream"):
> That makes perfect sense now. In that c
Alistair Francis writes ("[PATCH v2 1/2] autotools: Updage config.guess and
config.sub"):
> The autoconf manual [1] specifies that as we define AC_CANONICAL_HOST we
> must supply config.guess and config.sub. In which case let's update them
> from [2] commit: b98424c24 "config.guess: Remove space a
Make the asm/vpl011.h dependent on the CONFIG_SBSA_VUART_CONSOLE define.
Signed-off-by: Alistair Francis
---
xen/drivers/char/console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9bbcb0f57a..24287e59cb 100644
Hi Alistair,
On 20/05/2019 18:13, Alistair Francis wrote:
Make the asm/vpl011.h dependent on the CONFIG_SBSA_VUART_CONSOLE define.
Your commit message wants a bit more explanation. In this case, you want to say
the only user of this include is protected by CONFIG_SBSA_VUART_CONSOLE, hence
it
@Adam and Fedora Testing & QA:
any views on my proposal?
Regards
Lars
> On 13 May 2019, at 16:29, Lars Kurth wrote:
>
> Hi all,
>
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a
Currently, the structure vcpu_guest_core_regs is part of the public API.
This implies that any change in the structure should be backward
compatible.
However, the structure is only needed by the tools and Xen. It is also
not expected to be ever used outside of that context. So we could save us
som
On Wed, 15 May 2019, Julien Grall wrote:
> The condition of the BUG_ON() in advance_pc() is pretty wrong because
> the bits [26:25] and [15:10] have a different meaning between AArch32
> and AArch64 state.
>
> On AArch32, they are used to store PSTATE.IT. On AArch64, they are RES0
> or used for ne
On Mon, May 20, 2019 at 11:13:36AM +0100, Andy Cooper wrote:
> Lightweight Profiling was introduced in Bulldozer (Fam15h), but was dropped
> from Zen (Fam17h) processors. Furthermore, LWP was dropped from Fam15/16 CPUs
> when IBPB for Spectre v2 was introduced in microcode, owing to LWP not being
On Tue, 14 May 2019, Julien Grall wrote:
> The AIVIVT is a type of instruction cache available on Armv7. This is
> the only cache not implementing the IVIPT extension and therefore
> requiring specific care.
>
> To simplify maintenance requirements, Xen will not boot on platform
> using AIVIVT cac
flight 136633 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136633/
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
Hi,
On 20/05/2019 19:56, Stefano Stabellini wrote:
> On Tue, 14 May 2019, Julien Grall wrote:
>> The AIVIVT is a type of instruction cache available on Armv7. This is
>> the only cache not implementing the IVIPT extension and therefore
>> requiring specific care.
>>
>> To simplify maintenance requ
flight 136485 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 136243
Tests which did not
On Tue, 14 May 2019, Julien Grall wrote:
> The function flush_xen_text_tlb_local() has been misused and will result
> to invalidate the instruction cache more than necessary.
>
> For instance, there is no need to invalidate the instruction cache if
> we are setting SCTLR_EL2.WXN.
>
> There is eff
On Fri, 10 May 2019, Julien Grall wrote:
> On 10/05/2019 18:57, Stefano Stabellini wrote:
> > On Fri, 10 May 2019, Julien Grall wrote:
> >> On 09/05/2019 22:46, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On 09/05/2019 21:32, Julien Grall wrote:
> Hi,
>
> On 09/05/2019 21:13, Stefano S
On Mon, 20 May 2019, Julien Grall wrote:
> On 17/04/2019 18:27, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 17/04/2019 18:12, Stefano Stabellini wrote:
> > > > On Tue, 16 Apr 2019, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > >
> > > > > On
On Sat, 11 May 2019, Julien Grall wrote:
> > > > But I am still not happy with the approach taken for the reserved-memory
> > > > regions in this series. As I pointed out before, they are just normal
> > > > memory
> > > > that was reserved for other purpose (CMA, framebuffer...).
> > > >
> > > >
1 - 100 of 116 matches
Mail list logo
