flight 150410 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150410/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 150294
Tests which did not
flight 150406 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 7 xen-boot fail REGR. vs. 150391
Tests which did
On Wed, 2020-05-27 at 15:34 -0700, Boris Ostrovsky wrote:
> On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
> > @@ -155,8 +157,8 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
> > offset, int size,
> > u32 value = 0, tmp_val;
> >
> > if (unlikely(verbose_request))
> > -
On Mon, May 25, 2020 at 6:36 PM Jason Andryuk wrote:
>
> On Sun, May 24, 2020 at 10:50 PM Jason Andryuk wrote:
> >
> > This series addresses some Coverity reports. To handle closing FDs, a
> > state struct is introduced to track FDs closed in both main() and
> > data_loop().
>
> I've realized
flight 150416 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150416/
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 5/27/20 6:50 PM, Bjorn Helgaas wrote:
> On Wed, May 27, 2020 at 03:34:26PM -0700, Boris Ostrovsky wrote:
>> On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
>>> @@ -155,8 +157,8 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
>>> offset, int size,
>>> u32 value = 0, tmp_val;
>>>
>>> if
On Wed, May 27, 2020 at 03:34:26PM -0700, Boris Ostrovsky wrote:
> On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
> > @@ -155,8 +157,8 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
> > offset, int size,
> > u32 value = 0, tmp_val;
> >
> > if (unlikely(verbose_request))
> > -
On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Use dev_printk() when possible to include device and driver information in
> the conventional format.
>
> Add "#define dev_fmt" to preserve KBUILD_MODNAME in messages.
>
> No functional change intended.
>
> Signed-off-by: Bjorn
On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
> @@ -155,8 +157,8 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
> offset, int size,
> u32 value = 0, tmp_val;
>
> if (unlikely(verbose_request))
> - printk(KERN_DEBUG DRV_NAME ": %s: read %d bytes at 0x%x\n",
> -
On 5/27/20 3:53 PM, Roman Kagan wrote:
---
v5 -> v6:
- add prop_size32 instead of going with 64bit
Would it be worth adding prop_size32 as its own patch, before using it here?
I've no strong opinion on this. Should I better split it out when
respinning?
Patch splitting is an art-form.
On Wed, May 27, 2020 at 09:50:39AM -0500, Eric Blake wrote:
> On 5/27/20 7:45 AM, Roman Kagan wrote:
> > Several BlockConf properties represent respective sizes in bytes so it
> > makes sense to accept size suffixes for them.
> >
> > Turn them all into uint32_t and use size-suffix-capable
When adjusting an IRET frame to recover from a fault, and equivalent
adjustment needs making in the shadow IRET frame.
The adjustment in exception_with_ints_disabled() could in principle be an
alternative block rather than an ifdef, as the only two current users of
_PRE_EXTABLE() are
The SYSCALL/SYSENTER/SYSRET paths need to use {SET,CLR}SSBSY. The IRET to
guest paths must not. In the SYSRET path, re-position the mov which loads rip
into %rcx so we can use %rcx for CLRSSBSY, rather than spilling another
register to the stack.
While we can in principle detect shadow stack
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 set of bits modify_xen_mappings() to include Dirty
With all other plumbing in place, activate shadow stacks when possible. Note
that this requires prohibiting the use of PV32. Compatibility can be
maintained if necessary via PV-Shim.
The BSP needs to wait until alternatives have run (to avoid interaction with
CR0.WP), and after the first
See code for details
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
Semi-RFC - I can't actually test this path. Currently attempting to arrange
for someone else to.
v2:
* New, split out of "x86/shstk: Activate Supervisor Shadow Stacks"
* Drop
This series implements Shadow Stack support for Xen to use.
You'll need a CET-capable toolchain (Binutils >= 2.29 or LLVM >= 7), but no
specific compiler support required.
CET-SS makes PV32 unusable, so using shadow stacks prevents the use of 32bit
PV guests. Compatibilty can be obtained using
flight 150394 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150394/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150389
test-armhf-armhf-libvirt 14
When executing an IRET-to-self, the shadow stack must agree with the regular
stack. We can't manipulate SSP directly, so have to fake a shadow IRET frame
by executing 3 CALLs, then editing the result to look correct.
This is not a fastpath, is called on the BSP long before CET can be set up,
and
For one, they render the vector in a different base.
Introduce X86_EXC_* constants and vec_name() to refer to exceptions by their
mnemonic, which starts bringing the code/diagnostics in line with the Intel
and AMD manuals.
Provide constants for every archtiecturally defined exception, even those
Introduce HYPERVISOR_SHSTK pagetable constants, which are Read-Only + Dirty.
Use these in place of _PAGE_NONE for memguard_guard_stack().
Supervisor shadow stacks need a token written at the top, which is most easily
done before making the frame read only.
Allocate the shadow IST stack block in
We need to unwind up to the supervisor token. See the comment for details.
The use of UNLIKELY_END_SECTION in this case highlights that it isn't safe
when it isn't the final statement of an asm(). Adjust all declarations with a
newline.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
For now, any #CP exception or shadow stack #PF indicate a bug in Xen, but
attempt to recover from #CP if taken in guest context.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* Rebase over #PF[Rsvd] rework.
* Alignment for PFEC_shstk.
* Use more
Introduce CONFIG_HAS_AS_CET to determine whether CET instructions are
supported in the assembler, and CONFIG_XEN_SHSTK as the main build option.
Introduce cet={no-,}shstk to for a user to select whether or not to use shadow
stacks at runtime, and X86_FEATURE_XEN_SHSTK to determine Xen's overall
UD faults never had any diagnostics printed, and the others were inconsistent.
Don't use dprintk() because identifying traps.c is actively unhelpful in the
message, as it is the location of the fixup, not the fault. Use the new
vec_name() infrastructure, rather than leaving raw numbers for the
We have two free pages in the current stack. A useful property of shadow
stacks and regular stacks is that they act as each others guard pages as far
as OoB writes go.
Move the regular IST stacks up by one page, to allow their shadow stack page
to be in slot 0. The primary shadow stack uses
The 32 calls need dropping from the shadow stack as well as the regular stack.
To shorten the code, we can use the 32bit forms of RDSSP/INCSSP, but need to
double up the input to INCSSP to counter the operand size based multiplier.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC:
flight 150407 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150407/
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 Wed, May 27, 2020 at 02:01:48AM +0100, Igor Druzhinin wrote:
> If a recalculation NPT fault hasn't been handled explicitly in
> hvm_hap_nested_page_fault() then it's potentially safe to retry -
> US bit has been re-instated in PTE and any real fault would be correctly
> re-raised next time. Do
Hi Stefano,
On 26/05/2020 17:46, Stefano Stabellini wrote:
On Sun, 24 May 2020, Julien Grall wrote:
On 30/04/2020 14:01, Julien Grall wrote:
On 29/04/2020 21:47, Stefano Stabellini wrote:
On Wed, 15 Apr 2020, Julien Grall wrote: But doesn't it make sense to give
domU permission if it is
From: Bjorn Helgaas
Use dev_printk() when possible to include device and driver information in
the conventional format.
Add "#define dev_fmt" when needed to preserve DRV_NAME or KBUILD_MODNAME in
messages.
No functional change intended.
Signed-off-by: Bjorn Helgaas
---
From: Bjorn Helgaas
Use dev_printk() when possible to include device and driver information in
the conventional format.
Add "#define dev_fmt" to preserve KBUILD_MODNAME in messages.
No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/xen/xenbus/xenbus_probe.c | 11
From: Bjorn Helgaas
Use dev_printk() when possible to include device and driver information in
the conventional format.
Bjorn Helgaas (2):
xen-pciback: Use dev_printk() when possible
xenbus: Use dev_printk() when possible
drivers/xen/xen-pciback/conf_space.c| 16 +
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: The domain may or may not be using the embedded vcpu_info array so
ultimately separate context records will be added for vcpu_info when
this becomes necessary.
Signed-off-by: Paul
This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
Acked-by: Ian Jackson
---
Cc: Andrew Cooper
Cc: Wei Liu
NOTE: Ian requested ack from Andrew
v3:
- Re-worked to avoid
From: Paul Durrant
Paul Durrant (5):
xen/common: introduce a new framework for save/restore of 'domain'
context
xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
tools/misc: add xen-domctx to present domain context
common/domain: add a domain context record for
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via the hvm_save/load() functions)
that allows a
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
Reviewed-by: Julien Grall
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Stefano Stabellini
v4:
- Add missing
... in the save/restore code.
This patch replaces direct mapping of the shared_info_frame (retrieved
using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
SHARED_INFO record.
No modifications are made to the definition of the migration stream at
this point. Subsequent patches will
The 2nd of the assertions as well as the macro's return value have been
assuming we're on the primary stack. While for most IST exceptions we
switch back to the main one when user mode was interrupted, for #DF we
intentionally never do, and hence a #DF actually triggering on a user
mode insn
> On May 27, 2020, at 4:41 PM, Ian Jackson wrote:
>
> The Xen tools build system builds a FLASK policy by default. It does
> this even if the hypervisor build for XSM is disabled.
>
> I recently sent patches upstream to grub to support XSM in
> update-grub. update-grub is the program which
The Xen tools build system builds a FLASK policy by default. It does
this even if the hypervisor build for XSM is disabled.
I recently sent patches upstream to grub to support XSM in
update-grub. update-grub is the program which examines your /boot and
generates appropriate bootloader entries.
On 27/05/2020 14:19, Jan Beulich wrote:
> On 27.05.2020 15:06, Andrew Cooper wrote:
>> @@ -720,30 +721,26 @@ void load_system_tables(void)
>> .limit = (IDT_ENTRIES * sizeof(idt_entry_t)) - 1,
>> };
>>
>> -*tss = (struct tss64){
>> -/* Main stack for
On 27.05.2020 16:40, Andrew Cooper wrote:
> On 27/05/2020 15:00, Jan Beulich wrote:
>> You can have the descriptor map
>> only the [base,XenBase] part or the [0,base) one. Hence Xen, from its
>> #GP handler, flipped the descriptor between the two options depending
>> on whether the current access
On Wed, 2020-05-20 at 12:09 +0200, Jan Beulich wrote:
> On 24.04.2020 16:09, Hongyan Xia wrote:
> > --- a/xen/arch/x86/smpboot.c
> > +++ b/xen/arch/x86/smpboot.c
> > @@ -815,7 +815,7 @@ static int setup_cpu_root_pgt(unsigned int cpu)
> > if ( !opt_xpti_hwdom && !opt_xpti_domu )
> >
On Tue, May 26, 2020 at 03:55:39PM +0200, Jan Beulich wrote:
> On 26.05.2020 12:56, Roger Pau Monné wrote:
> > On Fri, May 22, 2020 at 02:00:22PM +0200, Jan Beulich wrote:
> >> On 22.05.2020 12:48, Roger Pau Monné wrote:
> >>> On Fri, May 22, 2020 at 11:52:42AM +0200, Jan Beulich wrote:
> On
flight 150391 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150391/
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 150386
test-armhf-armhf-libvirt 14
On Wed, May 27, 2020 at 04:57:02PM +0200, Martin Lucina wrote:
> On Wednesday, 27.05.2020 at 16:41, Roger Pau Monné wrote:
> > > > > If I make this simple change:
> > > > >
> > > > > --- a/bindings/xen/boot.S
> > > > > +++ b/bindings/xen/boot.S
> > > > > @@ -32,7 +32,7 @@
> > > > > #define
On Wed, May 27, 2020 at 10:00:08AM +0200, Martin Lucina wrote:
> On Tuesday, 26.05.2020 at 18:30, Roger Pau Monné wrote:
> > > Turns out that the .note.solo5.xen section as defined in boot.S was not
> > > marked allocatable, and that was doing that was confusing our
> > > linker script[1] (?).
>
On Wed, 2020-05-20 at 11:46 +0200, Jan Beulich wrote:
> On 24.04.2020 16:08, Hongyan Xia wrote:
> > @@ -493,22 +494,28 @@ void __init paging_init(void)
> > if ( !(l4e_get_flags(idle_pg_table[l4_table_offset(va)]) &
> >_PAGE_PRESENT) )
> > {
> > -
On Wednesday, 27.05.2020 at 16:41, Roger Pau Monné wrote:
> > > > If I make this simple change:
> > > >
> > > > --- a/bindings/xen/boot.S
> > > > +++ b/bindings/xen/boot.S
> > > > @@ -32,7 +32,7 @@
> > > > #define ENTRY(x) .text; .globl x; .type x,%function; x:
> > > > #define END(x) .size x,
On 5/27/20 7:45 AM, Roman Kagan wrote:
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessary tight, and we've seen bigger block sizes handy
unnecessarily
at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches
On 5/27/20 7:45 AM, Roman Kagan wrote:
Several BlockConf properties represent respective sizes in bytes so it
makes sense to accept size suffixes for them.
Turn them all into uint32_t and use size-suffix-capable setters/getters
on them; introduce DEFINE_PROP_SIZE32 and adjust
On 27/05/2020 15:00, Jan Beulich wrote:
> On 27.05.2020 15:39, Andrew Cooper wrote:
>> On 27/05/2020 14:03, Florian Weimer wrote:
>>> I'm about to remove nosegneg support from upstream glibc, special builds
>>> that use -mno-tls-direct-seg-refs, and the ability load different
>>> libraries built
On 5/27/20 7:45 AM, Roman Kagan wrote:
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
---
Reviewed-by: Eric Blake
--
Eric Blake,
On 5/27/20 7:45 AM, Roman Kagan wrote:
Several block device properties related to blocksize configuration must
be in certain relationship WRT each other: physical block must be no
smaller than logical block; min_io_size, opt_io_size, and
discard_granularity must be a multiple of a logical block.
* Andrew Cooper:
> Oh, so the i386 TLS model relies on the calculation wrapping (modulo 4G)
> when the segment limit is 4G, instead of taking a fault?
That's about it.
> Intel states this is behaviour is implementation specific (SDM Vol3
> 5.3.1) and may fault, while AMD doesn't discuss it at
On 27/05/2020 14:44, Samuel Thibault wrote:
> Hello,
>
> Andrew Cooper via Libc-alpha, le mer. 27 mai 2020 14:39:00 +0100, a ecrit:
>> Why does the MSB make any difference? %gs still needs to remain intact
>> so the thread pointer can be pulled out, so there is nothing that Xen or
>> Linux can do
On 27.05.2020 15:39, Andrew Cooper wrote:
> On 27/05/2020 14:03, Florian Weimer wrote:
>> I'm about to remove nosegneg support from upstream glibc, special builds
>> that use -mno-tls-direct-seg-refs, and the ability load different
>> libraries built in this mode automatically, when the Linux
Hello,
Andrew Cooper via Libc-alpha, le mer. 27 mai 2020 14:39:00 +0100, a ecrit:
> Why does the MSB make any difference? %gs still needs to remain intact
> so the thread pointer can be pulled out, so there is nothing that Xen or
> Linux can do in the way of lazy loading.
>
> Beyond that, its
On 27/05/2020 14:03, Florian Weimer wrote:
> I'm about to remove nosegneg support from upstream glibc, special builds
> that use -mno-tls-direct-seg-refs, and the ability load different
> libraries built in this mode automatically, when the Linux kernel tells
> us to do that. I think the intended
On 27.05.2020 15:06, Andrew Cooper wrote:
> @@ -720,30 +721,26 @@ void load_system_tables(void)
> .limit = (IDT_ENTRIES * sizeof(idt_entry_t)) - 1,
> };
>
> - *tss = (struct tss64){
> - /* Main stack for interrupts/exceptions. */
> - .rsp0 =
During boot, load_system_tables() is used in reinit_bsp_stack() to switch the
virtual addresses used from their .data/.bss alias, to their directmap alias.
The structure assignment is implemented as a memset() to zero first, then a
copy-in of the new data. This causes the NMI/#MC stack pointers
I'm about to remove nosegneg support from upstream glibc, special builds
that use -mno-tls-direct-seg-refs, and the ability load different
libraries built in this mode automatically, when the Linux kernel tells
us to do that. I think the intended effect is that these special builds
do not use
BlockConf includes several properties counted in bytes.
Enhance their handling in a some aspects, specifically
- accept common size suffixes (k, m)
- perform consistency checks on the values
- lift the upper limit on physical_block_size and logical_block_size
Also fix the accessor for
Several BlockConf properties represent respective sizes in bytes so it
makes sense to accept size suffixes for them.
Turn them all into uint32_t and use size-suffix-capable setters/getters
on them; introduce DEFINE_PROP_SIZE32 and adjust DEFINE_PROP_BLOCKSIZE
for that. (Making them uint64_t and
Several block device properties related to blocksize configuration must
be in certain relationship WRT each other: physical block must be no
smaller than logical block; min_io_size, opt_io_size, and
discard_granularity must be a multiple of a logical block.
To ensure these requirements are met,
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessary tight, and we've seen bigger block sizes handy
at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
---
v4 -> v5:
- split out into separate patch [Philippe]
hw/core/qdev-properties.c | 21
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
On Wed, May 27, 2020 at 11:43:16AM +0100, Anthony PERARD wrote:
> On Tue, May 26, 2020 at 11:16:10PM +0100, George Dunlap wrote:
> > This fixes the following build error in hvmloader:
> >
> > usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or
> > directory
> >
> >
flight 150390 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150390/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 150362
test-amd64-amd64-xl-qemuu-win7-amd64
flight 150396 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150396/
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 Tue, May 26, 2020 at 11:16:10PM +0100, George Dunlap wrote:
> This fixes the following build error in hvmloader:
>
> usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or
> directory
>
> Signed-off-by: George Dunlap
> ---
> automation/build/archlinux/current.dockerfile
flight 150392 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150392/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 568eee7cf319fa95183c8d3b5e8dcf6e078ab8b3
baseline version:
ovmf
On 27/05/2020 11:17, Manuel Bouyer wrote:
> Hello,
> I got Xen 4.13 working with NetBSD. Now I'd like to get the patches back
> in the Xen sources. What is the best way to submit the patches ?
Ideally, git-send-email to this list, from a branch based on
xen.git#staging.
On 27.05.2020 12:17, Manuel Bouyer wrote:
> I got Xen 4.13 working with NetBSD. Now I'd like to get the patches back
> in the Xen sources. What is the best way to submit the patches ?
Patches generally need to be submitted against the staging tree;
backporting to older trees occurs on an
Hello,
I got Xen 4.13 working with NetBSD. Now I'd like to get the patches back
in the Xen sources. What is the best way to submit the patches ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
flight 150397 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150397/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen d89e5e65f305740b2f7bd56e6f3b6c9c52ee0707
baseline version:
xen
On Tuesday, 26.05.2020 at 18:30, Roger Pau Monné wrote:
> > Turns out that the .note.solo5.xen section as defined in boot.S was not
> > marked allocatable, and that was doing that was confusing our
> > linker script[1] (?).
>
> Hm, I would have said there was no need to load notes into memory,
flight 150393 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150393/
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 26.05.2020 20:06, Andrew Cooper wrote:
> On 12/05/2020 14:05, 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.
>>
>> On 11.05.2020 17:14, Andrew Cooper wrote:
>>> On 04/05/2020
On 26.05.2020 17:38, Andrew Cooper wrote:
> On 19/05/2020 09:50, Jan Beulich wrote:
>> On 18.05.2020 18:54, Andrew Cooper wrote:
>>> On 11/05/2020 16:09, Jan Beulich wrote:
On 11.05.2020 17:01, Andrew Cooper wrote:
> On 04/05/2020 14:08, Jan Beulich wrote:
>> On 02.05.2020 00:58,
flight 150389 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150389/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150370
test-armhf-armhf-libvirt 14
On 26.05.2020 23:18, Dario Faggioli wrote:
> On Thu, 2020-04-30 at 14:52 +0200, Jürgen Groß wrote:
>> On 30.04.20 14:28, Dario Faggioli wrote:
>>> That being said, I can try to make things a bit more fair, when
>>> CPUs
>>> come up and are added to the pool. Something around the line of
>>> adding
On 27.05.2020 00:00, Dario Faggioli wrote:
> On Thu, 2020-04-30 at 08:45 +0200, Jan Beulich wrote:
>> On 29.04.2020 19:36, Dario Faggioli wrote:
>>> @@ -852,14 +862,61 @@ cpu_runqueue_match(const struct
>>> [...]
>>> +ASSERT(rcpu != cpu);
>>> +if ( !cpumask_test_cpu(rcpu,
usbback_portid_add() leaks the error when qdev_device_add() fails.
Fix that. While there, use the error to improve the error message.
The qemu_opts_from_qdict() similarly leaks on failure. But any
failure there is a programming error. Pass _abort.
Fixes:
87 matches
Mail list logo
