On 17.12.2020 02:54, Stefano Stabellini wrote:
> On Tue, 15 Dec 2020, Stefano Stabellini wrote:
>> Hi all,
>>
>> I am building Xen tools for ARM32 using qemu-user. I am getting the
>> following error building tools/flask. Everything else works fine. It is
>> worth noting that make -j1 works fine, i
> -Original Message-
> From: Wei Liu
> Sent: 16 December 2020 10:44
> To: Andrew Cooper ; Paul Durrant
> Cc: osstest service owner ;
> xen-devel@lists.xenproject.org; Paul Durrant
> ; Wei Liu
> Subject: Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
>
> Paul, are you a
flight 157612 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
Xen PV guests don't use IST. For machine check interrupts switch to
the same model as debug interrupts.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Thomas Gleixner
---
arch/x86/include/asm/idtentry.h | 3 +++
arch/x86/xen/enlighten_pv.c | 16 +++-
USERGS_SYSRET64 is used to return from a syscall via sysret, but
a Xen PV guest will nevertheless use the iret hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just u
Xen PV guests don't use IST. For double fault interrupts switch to
the same model as NMI.
Correct a typo in a comment while copying it.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Thomas Gleixner
---
V2:
- fix typo (Andy Lutomirski)
---
arch/x86/include/asm/idte
This is a major cleanup of the paravirt infrastructure aiming at
eliminating all custom code patching via paravirt patching.
This is achieved by using ALTERNATIVE instead, leading to the ability
to give objtool access to the patched in instructions.
In order to remove most of the 32-bit special h
SWAPGS is used only for interrupts coming from user mode or for
returning to user mode. So there is no reason to use the PARAVIRT
framework, as it can easily be replaced by an ALTERNATIVE depending
on X86_FEATURE_XENPV.
There are several instances using the PV-aware SWAPGS macro in paths
which are
The central pvops call macros PVOP_CALL() and PVOP_VCALL() are
looking very similar now.
The main differences are using PVOP_VCALL_ARGS or PVOP_CALL_ARGS, which
are identical, and the return value handling.
So drop PVOP_VCALL_ARGS and instead of PVOP_VCALL() just use
(void)PVOP_CA
"popf" is a rather expensive operation, so don't use it for restoring
irq flags. Instead test whether interrupts are enabled in the flags
parameter and enable interrupts via "sti" in that case.
This results in the restore_fl paravirt op to be no longer needed.
Suggested-by: Andy Lutomirski
Signe
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this allows quite some simplification of the pvops implementation.
Due to include hell this requires to split out
PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.
This allows to remove the 32-bit definitions of those macros leading
to a substantial simplification of the paravirt macros, as those were
the only ones needing non-e
Instead of only supporting to modify instructions when a specific
feature is set, support doing so for the case a feature is not set.
As today a feature is specified using a 16 bit quantity and the highest
feature number in use is around 600, using a negated feature number for
specifying the inver
Instead of using paravirt patching for custom code sequences use
ALTERNATIVE for the functions with custom code replacements.
Instead of patching an ud2 instruction for unpopulated vector entries
into the caller site, use a simple function just calling BUG() as a
replacement.
Signed-off-by: Juerg
For being able to switch paravirt patching from special cased custom
code sequences to ALTERNATIVE handling some X86_FEATURE_* are needed
as new features. This enables to have the standard indirect pv call
as the default code and to patch that with the non-Xen custom code
sequence via ALTERNATIVE p
The iret paravirt op is rather special as it is using a jmp instead
of a call instruction. Switch it to ALTERNATIVE.
Signed-off-by: Juergen Gross
---
V3:
- use ALTERNATIVE_TERNARY
---
arch/x86/include/asm/paravirt.h | 6 +++---
arch/x86/include/asm/paravirt_types.h | 5 +
arch/x86/ke
Instead of using paravirt patching for custom code sequences add
support for using ALTERNATIVE handling combined with paravirt call
patching.
Signed-off-by: Juergen Gross
---
V3:
- drop PVOP_ALT_VCALL() macro
---
arch/x86/include/asm/paravirt_types.h | 49 +++
1 file
From: Peter Zijlstra
Alternatives pose an interesting problem for unwinders because from
the unwinders PoV we're just executing instructions, it has no idea
the text is modified, nor any way of retrieving what with.
Therefore the stance has been that alternatives must not change stack
state, as
There is no need any longer to have different paravirt patch functions
for native and Xen. Eliminate native_patch() and rename
paravirt_patch_default() to paravirt_patch().
Signed-off-by: Juergen Gross
---
V3:
- remove paravirt_patch_insns() (kernel test robot)
---
arch/x86/include/asm/paravirt_
On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
> Am 16.12.2020 um 15:55 hat Sergio Lopez geschrieben:
> > On Wed, Dec 16, 2020 at 01:35:14PM +0100, Kevin Wolf wrote:
> > > Am 15.12.2020 um 18:23 hat Sergio Lopez geschrieben:
> > > > On Tue, Dec 15, 2020 at 04:01:19PM +0100, Kevin Wolf
flight 157603 linux-5.4 real [real]
flight 157634 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157603/
http://logs.test-lab.xenproject.org/osstest/logs/157634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
> On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
> > Am 16.12.2020 um 15:55 hat Sergio Lopez geschrieben:
> > > On Wed, Dec 16, 2020 at 01:35:14PM +0100, Kevin Wolf wrote:
> > > > Am 15.12.2020 um 18:23 hat Sergio Lopez geschrieben:
On 09.12.2020 17:09, Juergen Gross wrote:
> @@ -158,6 +159,30 @@ static void node_exit_all(void)
> node_exit(*last);
> }
>
> +void *hypfs_alloc_dyndata_size(unsigned long size)
> +{
> +unsigned int cpu = smp_processor_id();
> +
> +ASSERT(per_cpu(hypfs_locked, cpu) != hypfs_unloc
On 17.12.20 12:01, Jan Beulich wrote:
On 09.12.2020 17:09, Juergen Gross wrote:
@@ -158,6 +159,30 @@ static void node_exit_all(void)
node_exit(*last);
}
+void *hypfs_alloc_dyndata_size(unsigned long size)
+{
+unsigned int cpu = smp_processor_id();
+
+ASSERT(per_cpu(hypfs_
On 09.12.2020 17:09, Juergen Gross wrote:
> +static const struct hypfs_entry *hypfs_dyndir_enter(
> +const struct hypfs_entry *entry)
> +{
> +const struct hypfs_dyndir_id *data;
> +
> +data = hypfs_get_dyndata();
> +
> +/* Use template with original enter function. */
> +return
On 17.12.20 12:28, Jan Beulich wrote:
On 09.12.2020 17:09, Juergen Gross wrote:
+static const struct hypfs_entry *hypfs_dyndir_enter(
+const struct hypfs_entry *entry)
+{
+const struct hypfs_dyndir_id *data;
+
+data = hypfs_get_dyndata();
+
+/* Use template with original enter fu
First of all don't open-code is_control_domain(), which is already
suitably using evaluate_nospec(). Then also apply this construct to the
other paths of xsm_default_action(). Also guard two paths not using this
function.
Signed-off-by: Jan Beulich
---
While the functions are always_inline I'm no
On 17.12.2020 12:32, Jürgen Groß wrote:
> On 17.12.20 12:28, Jan Beulich wrote:
>> On 09.12.2020 17:09, Juergen Gross wrote:
>>> +static const struct hypfs_entry *hypfs_dyndir_enter(
>>> +const struct hypfs_entry *entry)
>>> +{
>>> +const struct hypfs_dyndir_id *data;
>>> +
>>> +data =
17.12.2020 13:58, Kevin Wolf wrote:
Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
Am 16.12.2020 um 15:55 hat Sergio Lopez geschrieben:
On Wed, Dec 16, 2020 at 01:35:14PM +0100, Kevin Wolf wrote:
Am 15.12.2020 um 18:23 hat Serg
Am 17.12.2020 um 13:50 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 17.12.2020 13:58, Kevin Wolf wrote:
> > Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
> > > On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
> > > > Am 16.12.2020 um 15:55 hat Sergio Lopez geschrieben:
> > > >
On Thu, Dec 17, 2020 at 11:58:30AM +0100, Kevin Wolf wrote:
> Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
> > Do you think it's safe to re-enter backup-top, or should we look for a
> > way to avoid this?
>
> I think it should be avoided, but I don't understand why putting all
> children o
Hi Juergen,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.10]
[cannot apply to xen-tip/linux-next tip/x86/core tip/x86/asm next-20201217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Thu, Dec 17, 2020 at 02:06:02PM +0100, Kevin Wolf wrote:
> Am 17.12.2020 um 13:50 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > 17.12.2020 13:58, Kevin Wolf wrote:
> > > Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
> > > > On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
>
17.12.2020 16:06, Kevin Wolf wrote:
Am 17.12.2020 um 13:50 hat Vladimir Sementsov-Ogievskiy geschrieben:
17.12.2020 13:58, Kevin Wolf wrote:
Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben:
On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote:
Am 16.12.2020 um 15:55 hat Sergio Lopez
Hi Julien,
Thanks for taking a look at the patches and providing feedback. I've seen your
other comments and will reply to those separately when I get a chance (maybe at
the weekend or over the Christmas break).
RE the differences in ordering semantics between Xen's and Linux's atomics
helpers, p
The goal of this serie is to emulate coprocessor ID registers so that
Xen only publish to guest features that are supported by Xen and can
actually be used by guests.
One practical example where this is required are SVE support which is
forbidden by Xen as it is not supported, but if Linux is compi
flight 157613 qemu-mainline real [real]
flight 157642 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157613/
http://logs.test-lab.xenproject.org/osstest/logs/157642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Modify identify_cpu function to use READ_SYSREG instead of READ_SYSREG32
or READ_SYSREG64.
The aarch32 versions of the registers are 64bit on an aarch64 processor
so it was wrong to access them as 32bit registers.
Signed-off-by: Bertrand Marquis
---
Change in V4:
This patch was introduced in v4
Add definition and entries in cpuinfo for ID registers introduced in
newer Arm Architecture reference manual:
- ID_PFR2: processor feature register 2
- ID_DFR1: debug feature register 1
- ID_MMFR4 and ID_MMFR5: Memory model feature registers 4 and 5
- ID_ISA6: ISA Feature register 6
Add more bitfie
Create a cpuinfo structure for guest and mask into it the features that
we do not support in Xen or that we do not want to publish to guests.
Modify some values in the cpuinfo structure for guests to mask some
features which we do not want to allow to guests (like AMU) or we do not
support (like S
Add coprocessor registers definitions for all ID registers trapped
through the TID3 bit of HSR.
Those are the one that will be emulated in Xen to only publish to guests
the features that are supported by Xen and that are accessible to
guests.
Signed-off-by: Bertrand Marquis
---
Changes in V2: Reb
Add vsysreg emulation for registers trapped when TID3 bit is activated
in HSR.
The emulation is returning the value stored in cpuinfo_guest structure
for know registers and is handling reserved registers as RAZ.
Signed-off-by: Bertrand Marquis
---
Changes in V2: Rebase
Changes in V3:
Fix commit
Add support for emulation of cp15 based ID registers (on arm32 or when
running a 32bit guest on arm64).
The handlers are returning the values stored in the guest_cpuinfo
structure for known registers and RAZ for all reserved registers.
In the current status the MVFR registers are no supported.
Sig
Add support for cp10 exceptions decoding to be able to emulate the
values for MVFR0, MVFR1 and MVFR2 when TID3 bit of HSR is activated.
This is required for aarch32 guests accessing MVFR registers using
vmrs and vmsr instructions.
Signed-off-by: Bertrand Marquis
---
Changes in V2: Rebase
Changes
Activate TID3 bit in HCR register when starting a guest.
This will trap all coprecessor ID registers so that we can give to guest
values corresponding to what they can actually use and mask some
features to guests even though they would be supported by the underlying
hardware (like SVE or MPAM).
S
On 09.12.2020 17:09, Juergen Gross wrote:
> Add /cpupool/ directories to hypfs. Those are completely
> dynamic, so the related hypfs access functions need to be implemented.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 09.12.2020 17:09, Juergen Gross wrote:
> @@ -1080,6 +1092,56 @@ static struct hypfs_entry *cpupool_dir_findentry(
> return hypfs_gen_dyndir_id_entry(&cpupool_pooldir, id, cpupool);
> }
>
> +static int cpupool_gran_read(const struct hypfs_entry *entry,
> + XEN_
On Thu, 2020-12-17 at 16:54 +0100, Jan Beulich wrote:
> On 09.12.2020 17:09, Juergen Gross wrote:
> > Add /cpupool/ directories to hypfs. Those are
> > completely
> > dynamic, so the related hypfs access functions need to be
> > implemented.
> >
> > Signed-off-by: Juergen Gross
>
> Reviewed-by:
On 12/17/20 2:40 AM, Jan Beulich wrote:
> On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote:
> I think this is acceptable as a workaround, albeit we may want to
> consider further restricting this (at least on staging), like e.g.
> requiring a guest config setting to enable the workaround.
Hi Juergen,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to xen-tip/linux-next tip/x86/core tip/x86/asm v5.10
next-20201217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Juergen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.10]
[cannot apply to xen-tip/linux-next tip/x86/core tip/x86/asm next-20201217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 17/12/2020 16:25, boris.ostrov...@oracle.com wrote:
> On 12/17/20 2:40 AM, Jan Beulich wrote:
>> On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote:
>> I think this is acceptable as a workaround, albeit we may want to
>> consider further restricting this (at least on staging), like e.g.
>> re
From: Juergen Gross Sent: Thursday, December 17, 2020 1:31 AM
> The time pvops functions are the only ones left which might be
> used in 32-bit mode and which return a 64-bit value.
>
> Switch them to use the static_call() mechanism instead of pvops, as
> this allows quite some simplification of
On Mon, Dec 14, 2020 at 5:25 PM Phillip Susi wrote:
> The regular xen cosole should work for this shouldn't it? So
> earlyprintk=hvc0 I guess? I also threw in console=hvc0 and loglevel=7:
>
> [ 184.734810] systemd-shutdown[1]: Syncing filesystems and block
> devices.
> [ 185.772511] systemd-sh
On 12/17/20 11:46 AM, Andrew Cooper wrote:
> On 17/12/2020 16:25, boris.ostrov...@oracle.com wrote:
>> On 12/17/20 2:40 AM, Jan Beulich wrote:
>>> On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote:
>>> I think this is acceptable as a workaround, albeit we may want to
>>> consider further rest
Hi Julien,
> On 15 Dec 2020, at 13:11, Julien Grall wrote:
>
> Hi Juergen,
>
> On 15/12/2020 11:31, Jürgen Groß wrote:
>> On 15.12.20 12:26, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> So far, our implementation of WARN_ON() cannot be used in the following
>>> situation:
>>>
>>> if (
On 16/12/2020 08:21, Jürgen Groß wrote:
> On 15.12.20 21:59, Andrew Cooper wrote:
>> On 15/12/2020 11:10, Juergen Gross wrote:
>>> In case a process waits for any Xenstore action in the xenbus driver
>>> it should be interruptible by signals.
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> V2:
>>
flight 157649 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157649/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 15/12/2020 16:25, Jan Beulich wrote:
> Drop a bogus ASSERT() - we don't typically assert incoming domain
> pointers to be non-NULL, and there's no particular reason to do so here.
>
> Replace the open-coded DOMID_SELF check by use of
> rcu_lock_remote_domain_by_id(), at the same time covering th
On 15/12/2020 16:26, Jan Beulich wrote:
> This is together with its only caller, xenmem_add_to_physmap_one().
I can't parse this sentence. Perhaps "... as is it's only caller," as a
follow-on from the subject sentence.
> Move
> the latter next to p2m_add_foreign(), allowing this one to become s
flight 157624 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
On 15/12/2020 16:26, Jan Beulich wrote:
> Extend a respective #ifdef from inside set_typed_p2m_entry() to around
> all three functions. Add ASSERT_UNREACHABLE() to the latter one's safety
> check path.
>
> Signed-off-by: Jan Beulich
As the code currently stands, yes. However, I'm not sure I agre
flight 157617 xen-unstable real [real]
flight 157652 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157617/
http://logs.test-lab.xenproject.org/osstest/logs/157652/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Guilherme G. Piccoli writes:
> Hm..not many prints, either earlyprintk didn't work, or it's a really
> early boot issue. Might worth to investigate if it's not a purgatory
> issue too - did you try to use the ""new"" kexec syscall, by running
> "kexec -s -l" instead of just "kexec -l" ?
> Also,
On 29/09/2020 07:18, Jan Beulich wrote:
> On 28.09.2020 17:47, Andrew Cooper wrote:
>> Various paths in vcpu_create() end up calling paging_update_paging_modes(),
>> which eventually allocate a monitor pagetable if one doesn't exist.
>>
>> However, an error in vcpu_create() results in the vcpu bein
Actually it passed. It was just a transient internet issue.
On Thu, 17 Dec 2020, no-re...@patchew.org wrote:
> Hi,
>
> Patchew automatically ran gitlab-ci pipeline with this patch (series)
> applied, but the job failed. Maybe there's a bug in the patches?
>
> You can find the link to the pipel
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Modify identify_cpu function to use READ_SYSREG instead of READ_SYSREG32
> or READ_SYSREG64.
> The aarch32 versions of the registers are 64bit on an aarch64 processor
> so it was wrong to access them as 32bit registers.
This sentence is a bit confusin
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Add definition and entries in cpuinfo for ID registers introduced in
> newer Arm Architecture reference manual:
> - ID_PFR2: processor feature register 2
> - ID_DFR1: debug feature register 1
> - ID_MMFR4 and ID_MMFR5: Memory model feature registers 4
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Add coprocessor registers definitions for all ID registers trapped
> through the TID3 bit of HSR.
> Those are the one that will be emulated in Xen to only publish to guests
> the features that are supported by Xen and that are accessible to
> guests.
>
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Create a cpuinfo structure for guest and mask into it the features that
> we do not support in Xen or that we do not want to publish to guests.
>
> Modify some values in the cpuinfo structure for guests to mask some
> features which we do not want to
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Add vsysreg emulation for registers trapped when TID3 bit is activated
> in HSR.
> The emulation is returning the value stored in cpuinfo_guest structure
> for know registers and is handling reserved registers as RAZ.
>
> Signed-off-by: Bertrand Marqu
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Add support for emulation of cp15 based ID registers (on arm32 or when
> running a 32bit guest on arm64).
> The handlers are returning the values stored in the guest_cpuinfo
> structure for known registers and RAZ for all reserved registers.
> In the c
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Add support for cp10 exceptions decoding to be able to emulate the
> values for MVFR0, MVFR1 and MVFR2 when TID3 bit of HSR is activated.
> This is required for aarch32 guests accessing MVFR registers using
> vmrs and vmsr instructions.
>
> Signed-off
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> Activate TID3 bit in HCR register when starting a guest.
> This will trap all coprecessor ID registers so that we can give to guest
> values corresponding to what they can actually use and mask some
> features to guests even though they would be suppor
On Thu, 17 Dec 2020, Bertrand Marquis wrote:
> The goal of this serie is to emulate coprocessor ID registers so that
> Xen only publish to guest features that are supported by Xen and can
> actually be used by guests.
> One practical example where this is required are SVE support which is
> forbidd
On Tue, 15 Dec 2020, Jan Beulich wrote:
> On 15.12.2020 14:19, Julien Grall wrote:
> > On 15/12/2020 11:46, Jan Beulich wrote:
> >> On 15.12.2020 12:26, Julien Grall wrote:
> >>> --- a/xen/include/xen/lib.h
> >>> +++ b/xen/include/xen/lib.h
> >>> @@ -23,7 +23,13 @@
> >>> #include
> >>>
> >>>
On Thu, 17 Dec 2020 at 23:54, Stefano Stabellini wrote:
>
> On Tue, 15 Dec 2020, Jan Beulich wrote:
> > On 15.12.2020 14:19, Julien Grall wrote:
> > > On 15/12/2020 11:46, Jan Beulich wrote:
> > >> On 15.12.2020 12:26, Julien Grall wrote:
> > >>> --- a/xen/include/xen/lib.h
> > >>> +++ b/xen/inclu
branch xen-4.13-testing
xenbranch xen-4.13-testing
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 157619 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157619/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 157656 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157656/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 157633 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157633/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
flight 157627 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157627/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow219 guest-localmigrate/x10 fail like 157134
test-amd64-i386-xl-qemuu-win7-am
On 17.12.20 19:25, Andrew Cooper wrote:
On 16/12/2020 08:21, Jürgen Groß wrote:
On 15.12.20 21:59, Andrew Cooper wrote:
On 15/12/2020 11:10, Juergen Gross wrote:
In case a process waits for any Xenstore action in the xenbus driver
it should be interruptible by signals.
Signed-off-by: Juergen
On 18.12.2020 01:32, osstest service owner wrote:
> branch xen-4.13-testing
> xenbranch xen-4.13-testing
> job test-amd64-amd64-xl-qemuu-ovmf-amd64
> testid debian-hvm-install
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.g
flight 157629 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs.
157135
Tests which
On 18.12.2020 00:54, Stefano Stabellini wrote:
> On Tue, 15 Dec 2020, Jan Beulich wrote:
>> On 15.12.2020 14:19, Julien Grall wrote:
>>> On 15/12/2020 11:46, Jan Beulich wrote:
On 15.12.2020 12:26, Julien Grall wrote:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@
86 matches
Mail list logo
