On Wed, Jun 05, 2019 at 06:37:27AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> During late microcode update, apply_microcode() is invoked in
>> cpu_request_microcode(). To make late microcode update more reliable,
>> we want to put the apply_microcode() into stop_machine
flight 137492 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137492/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 137222
'struct scheduler' already has member 'opt_name' and 'sched_id',
thus 'name' is a little redundant, so remove it.
Signed-off-by: Baodong Chen
---
xen/common/sched_arinc653.c | 1 -
xen/common/sched_credit.c | 1 -
xen/common/sched_credit2.c | 1 -
xen/common/sched_null.c | 1 -
flight 137503 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137503/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f0718d1d6b47745a4249f4006807a45f2245dba1
baseline version:
ovmf
flight 137485 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 10 debian-install fail REGR. vs. 125575
On 6/11/19 04:11, Julien Grall wrote:
Hi,
Thank you for the patch. The title should be at max 80 characters. So
how about the following title?
"xen/arm: domain: Remove redundant memset for v->arch.saved_context"
Max 80 characters, roger that.
On 6/10/19 6:15 AM, Baodong Chen wrote:
On 6/11/19 04:16, Julien Grall wrote:
Hi,
NIT: I would use "change" instead of "fix". I feel "fix" is more when
there are an actual bug.
Sound good to me.
On 6/10/19 6:07 AM, Baodong Chen wrote:
The original type is int and not used at all so fix to void.
The commit message is a bit
flight 137587 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137587/
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
flight 137484 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
133580
On Mon, 10 Jun 2019, Julien Grall wrote:
> On 6/10/19 9:40 PM, Stefano Stabellini wrote:
> > Hi Julien,
>
> Hi Stefano,
>
> >
> > I expressed my preference below. We don't agree. Is there anything else
> > you would like me to add to this thread? Do you have a specific
> > question? The only
Hi Stefano,
On 6/10/19 9:51 PM, Stefano Stabellini wrote:
On Mon, 20 May 2019, Julien Grall wrote:
On 20/05/2019 22:01, Stefano Stabellini wrote:
On Fri, 10 May 2019, Julien Grall wrote:
Feel free to suggest an in-code comment so we can discuss on the worthiness.
I suggest something like
On Mon, 10 Jun 2019, Julien Grall wrote:
> Hi Steano,
>
> On 6/10/19 9:28 PM, Stefano Stabellini wrote:
> > On Wed, 5 Jun 2019, Julien Grall wrote:
> > > On 05/06/2019 00:11, Stefano Stabellini wrote:
> > > > On Tue, 14 May 2019, Julien Grall wrote:
> > > > > The page-table walker is configured
On 6/10/19 9:40 PM, Stefano Stabellini wrote:
Hi Julien,
Hi Stefano,
I expressed my preference below. We don't agree. Is there anything else
you would like me to add to this thread? Do you have a specific
question? The only question I see below is "Users of what?" but I take
it was just
On Mon, 20 May 2019, Julien Grall wrote:
> On 20/05/2019 22:01, Stefano Stabellini wrote:
> > On Fri, 10 May 2019, Julien Grall wrote:
> >> Feel free to suggest an in-code comment so we can discuss on the
> >> worthiness.
> >
> > I suggest something like the following:
> >
> > /*
> >*
Hi Julien,
I expressed my preference below. We don't agree. Is there anything else
you would like me to add to this thread? Do you have a specific
question? The only question I see below is "Users of what?" but I take
it was just rhetorical.
On Mon, 10 Jun 2019, Julien Grall wrote:
> (+
Hi Steano,
On 6/10/19 9:28 PM, Stefano Stabellini wrote:
On Wed, 5 Jun 2019, Julien Grall wrote:
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed
On Wed, 5 Jun 2019, Julien Grall wrote:
> On 05/06/2019 00:11, Stefano Stabellini wrote:
> > On Tue, 14 May 2019, Julien Grall wrote:
> > > The page-table walker is configured to use the same shareability and
> > > cacheability as the access performed when updating the page-tables. This
> > >
Hi,
NIT: I would use "change" instead of "fix". I feel "fix" is more when
there are an actual bug.
On 6/10/19 6:07 AM, Baodong Chen wrote:
The original type is int and not used at all so fix to void.
The commit message is a bit unclear, you mention the type whereas the
key point is none
Hi,
Thank you for the patch. The title should be at max 80 characters. So
how about the following title?
"xen/arm: domain: Remove redundant memset for v->arch.saved_context"
On 6/10/19 6:15 AM, Baodong Chen wrote:
Already done by clear_page() in alloc_vcpu_struct()
Please try to make
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wrote:
Julien,
On 16.05.19 at 15:37, wrote:
As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with
make tiny64_defconfig
command.
Signed-off-by: Volodymyr
Hello,
I've tested the scenario with restoring too many domains having lock
commented out. It turns out that in case when there is no memory left
for XEN to allocate, all pending /xl restore/ commands will simply fail
with an internal error.
As far as I understand, it's not going to do any
On 6/10/19 4:49 PM, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
On 31.05.19 20:11, Julien Grall wrote:
Here my take on the commit message:
gic_interrupt() was implemented using a loop to limit the cost of the
trap if there are multiple interrupts pending.
At the moment, interrupts
Hi,
On 5/29/19 7:18 PM, Julien Grall wrote:
On 29/05/2019 18:58, Oleksandr wrote:
On 29.05.19 20:44, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 21/05/2019 18:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "interrupts-extended" property is a special form for
putn() and puts() are two subroutines. Add ENDPROC for the benefits of
static analysis tools and the reader.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index
setup_fixmap() will setup the fixmap in the boot page tables in order to
use earlyprintk and also update the register x23 holding the address to
the UART.
However, secondary CPUs are switching to the runtime page tables before
using the earlyprintk again. So settting up the fixmap in the boot
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 7b92c1c8eb..d673f7c0d8 100644
---
After the recent rework, the CPUID is only used at the very beginning of
the secondary CPUs boot path. So there is no need to "reserve" x24 for
he CPUID.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The ID map may clash with other parts of the Xen virtual memory layout.
At the moment, Xen is handling the clash by only creating a mapping to
the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, the
At the moment BSS is zeroed before the MMU and D-Cache is turned on.
In other words, the cache will be bypassed when zeroing the BSS section.
Per the Image protocol [1], the state of the cache for BSS region is not
known because it is not part of the "loaded kernel image".
This means that the
At the moment, the user should save x30/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should also move the value to register x0
if it was stored in a different register.
For convenience, a new
The assembly switch to the runtime PT is only necessary for the
secondary CPUs. So move the code in the secondary CPUs path.
While this is definitely not compliant with the Arm Arm as we are
switching between two differents set of page-tables without turning off
the MMU. Turning off the MMU is
The current implementation of the macro PRINT will clobber x30/lr. This
means the user should save lr if it cares about it.
Follow-up patches will introduce more use of PRINT in place where lr
should be preserved. Rather than requiring all the users to preserve lr,
the macro PRINT is modified to
Hi all,
This is part of the boot/memory rework for Xen on Arm, but not sent as
MM-PARTx as this is focusing on the boot code.
Similar to the memory code, the boot code is not following the Arm Arm and
could lead to memory corruption/TLB conflict abort. I am not aware
of any platforms where Xen
The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.
In an attempt to make the boot code easier to follow, each parts of the
boot are now in separate
On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
zeroed once at boot. So the call in the secondary CPUs path can be
removed. It also means that x26 does not need to set and is now only
used by the boot CPU.
Lastly, document the behavior and the main registers usage within
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime page-tables.
In the future, the boot CPU will not switch between page-tables to avoid
TLB conflict.
Adjust the coding style used in the comments within create_pages_tables()
Lastly, document the behavior and the main registers usage within the
function. Note that x25 is now only used within the function, so it does
not need to be part of the common register.
Signed-off-by: Julien Grall
---
Adjust the coding style used in the comments within cpu_init(). Take the
opportunity to alter the early print to match the function name.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 19
Anything executed after the label common_start can be executed on all
CPUs. However most of the instructions executed between the label
common_start and init_uart are not executed on the boot CPU.
The only instructions executed are to lookup the CPUID so it can be
printed on the console (if
A branch in the success case can be avoided by inverting the branch
condition. At the same time, remove a pointless comment as Xen can only
run at EL2.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 15
Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().
In order to avoid a branch for the decision and make the code clearer,
launch() is reworked to take in parameters the entry point and its
arguments.
On 6/10/19 12:23 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
On 02.06.19 13:26, Julien Grall wrote:
+ * This should only be called with interrupt routed to guest. The flow
+ * of interrupt routed to Xen any software change of the state.
Sorry I can't parse the last sentence. It seems to
On 6/10/19 7:20 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
Julien Grall writes:
Hi,
On 21/05/2019 22:25, Volodymyr Babchuk wrote:
This header files describes protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcoming OP-TEE mediator, which
is added in the
Hi Julien,
Julien Grall writes:
> Hi,
>
> On 21/05/2019 22:25, Volodymyr Babchuk wrote:
>> This header files describes protocol between OP-TEE and OP-TEE client
>> driver in Linux. They are needed for upcoming OP-TEE mediator, which
>> is added in the next patch.
>> Reason to add those headers
flight 137477 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137477/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 137094
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Doug Goldstein
---
automation/build/Makefile | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/automation/build/Makefile b/automation/build/Makefile
index 773b160..7c7612b 100644
--- a/automation/build/Makefile
+++
On Mon, Jun 10, 2019 at 06:32:46PM +0200, Roger Pau Monne wrote:
> Using clang and lld 8 requires installing the packages from the
> official llvm apt repositories, so modify the Debian Docker files for
> stretch and unstable to add the llvm repo and install clang and lld
> from it.
>
> Also add
flight 137586 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137586/
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
On 23/05/2019 13:19, Jan Beulich wrote:
> From: Ross Lagerwall
>
> Signed-off-by: Ross Lagerwall
>
> Make handling in do_pm_op() more homogeneous: Before interpreting
> op->cpuid as such, handle all operations not acting on a particular
> CPU. Also expose the setting via xenpm.
>
>
On 23/05/2019 13:18, Jan Beulich wrote:
> From: Ross Lagerwall
>
> Allow limiting the max C-state sub-state by appending to the max_cstate
> command-line parameter. E.g. max_cstate=1,0
> The limit only applies to the highest legal C-state. For example:
> max_cstate = 1, max_csubstate = 0 ==> C0,
Using clang and lld 8 requires installing the packages from the
official llvm apt repositories, so modify the Debian Docker files for
stretch and unstable to add the llvm repo and install clang and lld
from it.
Also add some jobs to test building Xen with clang 8 and lld.
Signed-off-by: Roger
On 23/05/2019 13:18, Jan Beulich wrote:
> At least for more recent CPUs, following what BKDG / PPR suggest for the
> BIOS to surface via ACPI we can make ourselves independent of Dom0
> uploading respective data.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: Can we set local_apic_timer_c2_ok to
Hello Julien,
On 31.05.19 20:11, Julien Grall wrote:
Here my take on the commit message:
gic_interrupt() was implemented using a loop to limit the cost of the trap if
there are multiple interrupts pending.
At the moment, interrupts are unmasked by gic_interrupt() before calling do_{IRQ,
On 23/05/2019 13:16, Jan Beulich wrote:
> While the MWAIT idle driver already takes it to mean an actual C state,
> the ACPI idle driver so far used it as a list index. The list index,
> however, is an implementation detail of Xen and affected by firmware
> settings (i.e. not necessarily uniform
On 31.05.19 16:24, Dario Faggioli wrote:
Weather or not the main reason is that one, it fixes an (albeit not too
terrible) layering/encapsulation violation, as things used only by
Credit, should live in Credit code.
Encapsulation violation was the main reason to have this patch though ;)
On 15/03/2019 10:56, Jan Beulich wrote:
> +#if __GNUC__ > 7 /* can't check for __AVX512VBMI2__ here */
Why not?
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -266,10 +266,10 @@ def crunch_numbers(state):
>AVX512BW, AVX512VL, AVX512_4VNNIW, AVX512_4FMAPS,
Hello George,
On 31.05.19 13:26, George Dunlap wrote:
This seems like a useful change, and the commit message has a lot of good
detail, thanks. But I’m left wondering: Is the main idea here just to
generally reduce code and data usage when not running the credit scheduler, or
is there
On 15/03/2019 10:56, Jan Beulich wrote:
> This completes support of AVX512DQ in the insn emulator.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 15/03/2019 10:56, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 29/05/2019 14:15, Jan Beulich wrote:
On 29.05.19 at 14:51, wrote:
>> On 15/03/2019 10:56, Jan Beulich wrote:
>>> @@ -9681,6 +9696,21 @@ x86_emulate(
>>> op_bytes = 4;
>>> goto simd_imm8_zmm;
>>>
>>> +case X86EMUL_OPC_EVEX_66(0x0f3a, 0x26): /* vgetmantp{s,d}
>>>
On 10/06/2019 14:36, Roger Pau Monne wrote:
> Using clang and lld 8 requires installing the packages from the
> official llvm apt repositories, so modify the Debian Docker files for
> stretch and unstable to add the llvm repo and install clang and lld
> from it.
>
> Also add some jobs to test
Using clang and lld 8 requires installing the packages from the
official llvm apt repositories, so modify the Debian Docker files for
stretch and unstable to add the llvm repo and install clang and lld
from it.
Also add some jobs to test building Xen with clang 8 and lld.
Signed-off-by: Roger
flight 137475 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 136728
Tests which
(+ Committers)
Ping again... I have some upcoming patches that are blocked on this work...
Cheers,
On 29/05/2019 18:23, Julien Grall wrote:
Hi,
Gentle ping...
Cheers,
On 14/05/2019 13:31, Julien Grall wrote:
Hi all,
This is the third part of the boot/memory rework for Xen on Arm. At the
(+ Committers)
Ping again... I have quite a few patches blocked on this work.
There was a discussion on v2 (see [1]) and pointed out that the comment
suggested was out-of-context. I am still waiting on input from Stefano to
clarify the relation...
Cheers,
[1]
(+ Committers)
Ping again... I have quite a few patches blocked on this work.
Cheers,
On 29/05/2019 17:44, Julien Grall wrote:
Gentle ping.
On 20/05/2019 20:53, Julien Grall wrote:
Hi,
On 20/05/2019 19:56, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The AIVIVT is a
On 10/06/2019 10:17, George Dunlap wrote:
> On 6/10/19 2:01 AM, Baodong Chen wrote:
>> Xen internal running status(trace event at pre-defined trace point)
>> will be saved to trace memory when enabled.
>> Trace event data and config params can be read/changed
>> by system control hypercall at run
On 6/10/19 2:01 AM, Baodong Chen wrote:
> Xen internal running status(trace event at pre-defined trace point)
> will be saved to trace memory when enabled.
> Trace event data and config params can be read/changed
> by system control hypercall at run time.
>
> Can be disabled for smaller code
flight 137470 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137470/
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 are
From: Zhang Chen
Xen COLO and KVM COLO shared lots of code in Qemu.
KVM COLO has added the iothread support, so we add it on Xen.
Detail:
https://wiki.qemu.org/Features/COLO
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_dm.c | 14 +++---
tools/libxl/libxl_types.idl | 2 ++
On Tue, Jun 04, 2019 at 09:29:34AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> --- a/xen/arch/x86/microcode_amd.c
>> +++ b/xen/arch/x86/microcode_amd.c
>> @@ -78,8 +78,9 @@ struct mpbhdr {
>> static DEFINE_SPINLOCK(microcode_update_lock);
>>
>> /* See comment in
71 matches
Mail list logo
