On 07.05.20 20:34, Dario Faggioli wrote:
On Thu, 2020-04-30 at 17:15 +0200, Juergen Gross wrote:
With RCU barriers moved from tasklets to normal RCU processing cpu
offlining in core scheduling might deadlock due to cpu
synchronization
required by RCU processing and core scheduling concurrently.
On 5/7/20 5:58 PM, Philippe Mathieu-Daudé wrote:
This code is not related to hardware emulation.
Move it under accel/ with the other hypervisors.
Signed-off-by: Philippe Mathieu-Daudé
---
We could also move the memory management functions from
hw/i386/xen/xen-hvm.c but it is not trivial.
Patchew URL: https://patchew.org/QEMU/20200507155813.16169-1-phi...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
flight 150067 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150067/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 150048
Tests which did not
flight 150064 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150064/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 149906
Tests which did not
We’re still ironing out all the details, but it’s absolutely confirmed that
XenSummit 2020 will be held virtually in June.
In addition, the new version of the Design Sessions website is now live:
https://design-sessions.xenproject.org
Make space on your calendars, and submit your design
flight 150080 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150080/
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
Hi Stefano,
On 07/05/2020 21:34, Stefano Stabellini wrote:
On Thu, 7 May 2020, Julien Grall wrote:
Hi,
On 07/05/2020 21:29, Stefano Stabellini wrote:
#define read_atomic(p) ({
\
-typeof(*p) __x; \
-switch ( sizeof(*p) ) {
On 05/05/2020 09:15, Jan Beulich wrote:
> In preparation for handling e.g. FLDENV or {F,FX,X}RSTOR here as well.
>
> Signed-off-by: Jan Beulich
> ---
> v8: New (could be folded into "x86emul: support MOVDIR{I,64B} insns",
> but would invalidate Paul's R-b there).
>
> ---
On Thu, 7 May 2020, Julien Grall wrote:
> Hi,
>
> On 07/05/2020 21:29, Stefano Stabellini wrote:
> > > #define read_atomic(p) ({
> > > \
> > > -typeof(*p) __x; \
> > > -switch ( sizeof(*p) ) {
Hi,
On 07/05/2020 21:29, Stefano Stabellini wrote:
#define read_atomic(p) ({ \
-typeof(*p) __x; \
-switch ( sizeof(*p) ) { \
-case 1: __x =
On Sat, 2 May 2020, Julien Grall wrote:
> From: Julien Grall
>
> The current implementation of read_atomic() on Arm will not allow to:
> 1) Read a value from a pointer to const because the temporary
> variable will be const and therefore it is not possible to assign
> any value. This
On Sat, 2 May 2020, Julien Grall wrote:
> From: Julien Grall
>
> The current implementation of write_atomic has two issues:
> 1) It cannot be used to write pointer value because the switch
> contains cast to other size than the size of the pointer.
> 2) It will happily allow to write
On 05/05/2020 09:14, Jan Beulich wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -284,6 +284,9 @@ def crunch_numbers(state):
> # as dependent features simplifies Xen's logic, and prevents the
> guest
> # from seeing implausible configurations.
>
On 05/05/2020 09:14, Jan Beulich wrote:
> ... enabling its use by all guest kinds at the same time.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> @@ -5660,6 +5661,18 @@ x86_emulate(
> goto done;
> break;
>
> +case 0xe8:
> +switch (
On 05/05/2020 09:13, Jan Beulich wrote:
> Note that the ISA extensions document revision 038 doesn't specify
> exception behavior for ModRM.mod == 0b11; assuming #UD here.
Stale.
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -11480,11
flight 150078 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150078/
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 Thu, 2020-04-30 at 17:15 +0200, Juergen Gross wrote:
> Commit cb563d7665f2 ("xen/sched: support core scheduling for moving
> cpus to/from cpupools") introduced a regression when trying to remove
> an offline cpu from a cpupool, as the system would crash in this
> situation.
>
> Fix that by
On Thu, 2020-04-30 at 17:15 +0200, Juergen Gross wrote:
> With RCU barriers moved from tasklets to normal RCU processing cpu
> offlining in core scheduling might deadlock due to cpu
> synchronization
> required by RCU processing and core scheduling concurrently.
>
> Fix that by bailing out from
On 05/05/2020 09:13, Jan Beulich wrote:
> Introduce a new blk() hook, paralleling the rmw() one in a certain way,
> but being intended for larger data sizes, and hence its HVM intermediate
> handling function doesn't fall back to splitting the operation if the
> requested virtual address can't be
On 05/05/2020 09:12, Jan Beulich wrote:
> In a pure PV environment (the PV shim in particular) we don't really
> need emulation of all these. To limit #ifdef-ary utilize some of the
> CASE_*() macros we have, by providing variants expanding to
> (effectively) nothing (really a label, which in turn
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 07 May 2020 16:58
> To: qemu-de...@nongnu.org
> Cc: Philippe Mathieu-Daudé ;
> xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Aleksandar Markovic
> ; Aurelien Jarno
> ; Paolo Bonzini ; Igor Mammedov
> ;
> Eduardo
On 05/05/2020 07:31, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> Andrew,
>
> On 21.04.2020 18:40, Roger Pau Monné wrote:
>> On Tue, Apr 21, 2020 at 11:11:03AM +0200, Jan
Julien Grall writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be
selected from the menuconfig directly"):
> On 04/05/2020 13:34, Ian Jackson wrote:
> > George Dunlap writes ("Re: [PATCH RESEND 2/2] xen: Allow EXPERT mode to be
> > selected from the menuconfig directly"):
> >> On Apr 30,
On Wed, 2020-05-06 at 11:00 +0100, Sergey Dyasli wrote:
> Currently it might be not obvious which scheduling mode (e.g. core-
> scheduling) is being used by the scheduler. Alleviate this by
> printing
> additional information about the selected granularity per-cpupool.
>
> Note: per-cpupool
On Thu, 2020-04-30 at 15:25 +0100, Julien Grall wrote:
> From: Julien Grall
>
> Since commit f80fe2b34f08 "xen: Update Kconfig to Linux v5.4" EXPERT
> can only have two values (enabled or disabled). So switch from a
> string
> to a bool.
>
> Take the opportunity to replace all "EXPERT = y" to
On Wed, 2020-05-06 at 17:16 +0200, Juergen Gross wrote:
> credit2 is currently modifying the pause flags of vcpus non-
> atomically
> via sched_set_pause_flags() and sched_clear_pause_flags(). This is
> dangerous as there are cases where the paus flags are modified
> without
> any lock held.
>
On 07.05.2020 17:50, Andrew Cooper wrote:
> On 07/05/2020 15:12, Jan Beulich wrote:
>> On 02.05.2020 00:58, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/x86_64/compat/entry.S
>>> +++ b/xen/arch/x86/x86_64/compat/entry.S
>>> @@ -198,7 +198,7 @@ ENTRY(cr4_pv32_restore)
>>>
>>> /* See lstar_enter
This code is not related to hardware emulation.
Move it under accel/ with the other hypervisors.
Signed-off-by: Philippe Mathieu-Daudé
---
We could also move the memory management functions from
hw/i386/xen/xen-hvm.c but it is not trivial.
Necessary step to remove "exec/ram_addr.h" in the next
On 07/05/2020 15:12, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> The SYSCALL/SYSEXIT paths need to use {SET,CLR}SSBSY.
> I take it you mean SYSRET, not SYSEXIT.
I do, sorry.
> I do think though that you
> also need to deal with the SYSENTER entry point we have.
Oh - so we
flight 150061 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150061/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150043
flight 150063 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150063/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8293e6766a884918a6b608c64543caab49870597
baseline version:
ovmf
flight 150069 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150069/
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 02.05.2020 00:58, Andrew Cooper wrote:
> --- a/xen/arch/x86/acpi/wakeup_prot.S
> +++ b/xen/arch/x86/acpi/wakeup_prot.S
> @@ -1,3 +1,8 @@
> +#include
Why is this needed? Afaics assembly files, just like C ones, get
xen/config.h included from the compiler command line.
> @@ -48,6 +59,48 @@
flight 150062 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 02.05.2020 00:58, Andrew Cooper wrote:
> The SYSCALL/SYSEXIT paths need to use {SET,CLR}SSBSY.
I take it you mean SYSRET, not SYSEXIT. I do think though that you
also need to deal with the SYSENTER entry point we have.
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++
On 02.05.2020 00:58, Andrew Cooper wrote:
> The current alternatives algorithm clears CR0.WP and writes into .text. This
> has a side effect of the mappings becoming shadow stacks once CET is active.
>
> Adjust _alternative_instructions() to clean up after itself. This involves
> extending the
On 02.05.2020 00:58, Andrew Cooper wrote:
> The logic is completely undocumented and almost impossible to follow. It
> actually uses return oriented programming. Rewrite it to conform to more
> normal call mechanics, and leave a big comment explaining thing. As well as
> the code being easier
On 07.05.2020 15:25, Andrew Cooper wrote:
> On 07/05/2020 14:22, Jan Beulich wrote:
>> On 02.05.2020 00:58, Andrew Cooper wrote:
>>> @@ -114,6 +114,16 @@
>>> sub $1, %ecx
>>> jnz .L\@_fill_rsb_loop
>>> mov %\tmp, %rsp /* Restore old %rsp */
>>> +
>>> +#ifdef
On Thu, May 07, 2020 at 11:00:30AM +0200, Roger Pau Monné wrote:
> On Wed, May 06, 2020 at 05:50:18PM +0100, Wei Liu wrote:
> > Use flex 2.6.4 that is shipped in Debian Buster.
> >
> > Signed-off-by: Wei Liu
> > ---
> > Do this because Roger posted a patch to fix clang build, which requires
> >
On 02.05.2020 00:58, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -778,6 +778,28 @@ static bool exception_fixup(struct cpu_user_regs *regs,
> bool print)
> vec_name(regs->entry_vector), regs->error_code,
> _p(regs->rip),
On 07/05/2020 14:22, Jan Beulich wrote:
> On 02.05.2020 00:58, Andrew Cooper wrote:
>> @@ -114,6 +114,16 @@
>> sub $1, %ecx
>> jnz .L\@_fill_rsb_loop
>> mov %\tmp, %rsp /* Restore old %rsp */
>> +
>> +#ifdef CONFIG_XEN_SHSTK
>> +mov $1, %ecx
>> +rdsspd %ecx
Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
May Be Dispatched Before an Interrupt of The Same Priority Completes".
It's not clear which models are affected, as the errata is listed in
the "Second Generation Intel Xeon Scalable Processors" specification
update, but the
On 02.05.2020 00:58, Andrew Cooper wrote:
> @@ -114,6 +114,16 @@
> sub $1, %ecx
> jnz .L\@_fill_rsb_loop
> mov %\tmp, %rsp /* Restore old %rsp */
> +
> +#ifdef CONFIG_XEN_SHSTK
> +mov $1, %ecx
> +rdsspd %ecx
> +cmp $1, %ecx
> +je .L\@_shstk_done
> +
On 02.05.2020 00:58, Andrew Cooper wrote:
> We need to unwind up to the supervisor token. See the comment for details.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> ---
> xen/include/asm-x86/current.h | 42
flight 150054 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150054/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 149905
Tests which did not
flight 150051 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 150038 REGR. vs.
149649
Tests
On 27.04.20 16:53, George Dunlap wrote:
On Apr 2, 2020, at 4:46 PM, Juergen Gross wrote:
Add the new library libxenhypfs for access to the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
Just a few questions...
+/* Returned buffer and dirent should be freed via
On 27.04.20 15:55, George Dunlap wrote:
On Apr 2, 2020, at 4:46 PM, Juergen Gross wrote:
[snip]
+* {VALUE, VALUE, ... } -- a list of possible values separated by "," and
+ enclosed in "{" and "}".
[snip]
+So an entry could look like this:
+
+/cpu-bugs/active-pv/xpti = ("No"|{"dom0",
flight 150048 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150048/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 149908
Tests which did not
Hi,
On 07/05/2020 09:58, Jan Beulich wrote:
On 07.05.2020 10:35, Julien Grall wrote:
On 07/05/2020 08:21, Jan Beulich wrote:
On 06.05.2020 18:44, Paul Durrant wrote:
+#define DOMAIN_SAVE_BEGIN(_x, _c, _v, _len) \
+ domain_save_begin((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_len))
On Wed, May 06, 2020 at 05:50:18PM +0100, Wei Liu wrote:
> Use flex 2.6.4 that is shipped in Debian Buster.
>
> Signed-off-by: Wei Liu
> ---
> Do this because Roger posted a patch to fix clang build, which requires
> updating the same files. I don't want bury his changes in unrelated
> ones.
On 07.05.2020 10:35, Julien Grall wrote:
>
>
> On 07/05/2020 08:21, Jan Beulich wrote:
>> On 06.05.2020 18:44, Paul Durrant wrote:
> +#define DOMAIN_SAVE_BEGIN(_x, _c, _v, _len) \
> + domain_save_begin((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_len))
In new code I'd like
On 07/05/2020 08:21, Jan Beulich wrote:
On 06.05.2020 18:44, Paul Durrant wrote:
+#define DOMAIN_SAVE_BEGIN(_x, _c, _v, _len) \
+domain_save_begin((_c), DOMAIN_SAVE_CODE(_x), #_x, (_v), (_len))
In new code I'd like to ask for no leading underscores on macro
parameters as well as no
On 05.05.2020 20:25, Andrew Cooper wrote:
> AMD Fam15h processors introduced the flush-by-asid feature, for more fine
> grain flushing purposes.
>
> Flushing everything including ASID 0 (i.e. Xen context) is an an unnecesserily
> large hammer, and never necessary in the context of guest TLBs
On 07.05.2020 09:45, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 07 May 2020 08:40
>> To: p...@xen.org
>> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
>> 'Andrew Cooper'
>> ; 'George Dunlap' ;
>> 'Ian Jackson'
>> ; 'Julien Grall' ; 'Stefano
>>
On 06.05.2020 05:23, Christopher Clark wrote:
> +It is with this understanding as presented that the DomB project used as the
> +basis for the development of its multiple domain boot capability for Xen.
> Within
> +the remainder of this document is a detailed explanation of the multiple
> domain
> -Original Message-
> From: Jan Beulich
> Sent: 07 May 2020 08:40
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Andrew Cooper'
> ; 'George Dunlap' ; 'Ian
> Jackson'
> ; 'Julien Grall' ; 'Stefano
> Stabellini'
> ; 'Wei Liu' ; 'Volodymyr Babchuk'
> ;
>
On 07.05.2020 09:34, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 07 May 2020 08:22
>>
>> On 06.05.2020 18:44, Paul Durrant wrote:
From: Jan Beulich
Sent: 29 April 2020 12:02
On 07.04.2020 19:38, Paul Durrant wrote:
> +int domain_load_begin(struct domain_context *c,
> -Original Message-
> From: Jan Beulich
> Sent: 07 May 2020 08:22
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Andrew Cooper'
> ; 'George Dunlap' ; 'Ian
> Jackson'
> ; 'Julien Grall' ; 'Stefano
> Stabellini'
> ; 'Wei Liu' ; 'Volodymyr Babchuk'
> ;
>
On 06.05.2020 18:44, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 29 April 2020 12:02
>>
>> On 07.04.2020 19:38, Paul Durrant wrote:
>>> +int domain_load_begin(struct domain_context *c, unsigned int tc,
>>> + const char *name, const struct vcpu *v, size_t len,
>>> +
On 06.05.2020 18:49, Andrew Cooper wrote:
> On 06/05/2020 16:10, Jan Beulich wrote:
>> On 05.05.2020 19:32, Andrew Cooper wrote:
>>> @@ -435,17 +435,13 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v,
>>> struct cpu_user_regs *regs)
>>> ASSERT(n2vmcb != NULL);
>>>
>>> /* Check if
flight 150044 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150044/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 149906
Regressions which
63 matches
Mail list logo
