On 1/28/19 8:36 AM, Oleksandr Andrushchenko wrote:
> On 1/26/19 2:05 PM, YueHaibing wrote:
>> There is no need to have the 'struct drm_framebuffer *fb' variable
>> static since new value always be assigned before use it.
>>
>> Signed-off-by: YueHaibing
> Good catch, thank you!
> Reviewed-by:
>>> On 31.01.19 at 21:02, wrote:
> On 31/01/2019 16:19, Jan Beulich wrote:
>>
>>> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
>>> if ( a.index >= HVM_NR_PARAMS )
>>> return -EINVAL;
>>>
>>> +/*
>>> + * Make sure the guest controlled value a.index is bounded even
On 1/30/19 11:09 AM, Oleksandr Andrushchenko wrote:
> On 1/29/19 9:07 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> When GEM backing storage is allocated those are normal pages,
>>> so there is no point
>>> On 31.01.19 at 23:39, wrote:
> On 25/01/2019 10:14, Jan Beulich wrote:
> On 24.01.19 at 22:29, wrote:
>>> Worse is the "evaluate condition, stash result, fence, use variable"
>>> option, which is almost completely useless. If you work out the
>>> resulting instruction stream, you'll
On Fri, Feb 01, 2019 at 08:38:43AM +, Oleksandr Andrushchenko wrote:
> On 2/1/19 10:27 AM, Christoph Hellwig wrote:
> > On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote:
> >> The alternative would be to turn xenmem_reservation_scrub_page into a
> >> regular function (not a
On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote:
> The alternative would be to turn xenmem_reservation_scrub_page into a
> regular function (not a static inline)?
All that is a moot point until said currently out of tree module gets
submitted for inclusion anyway.
On 2/1/19 10:27 AM, Christoph Hellwig wrote:
> On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote:
>> The alternative would be to turn xenmem_reservation_scrub_page into a
>> regular function (not a static inline)?
> All that is a moot point until said currently out of tree module
On 1/31/19 11:44 PM, Stefano Stabellini wrote:
> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>> Hello,
>>
>> I am working on porting an out-of-tree kernel driver to the kernel
>> 5.0 and that driver uses functionality provided by
>> drivers/xen/mem-reservation.c
>> module. Since commit
On 01/02/2019 10:40, Andrew Cooper wrote:
> On 01/02/2019 07:26, Juergen Gross wrote:
>> While working on my core scheduling series I stumbled over the periodic
>> timer. Could it be this timer never worked correctly?
>>
>> When the vcpu with an active periodic timer is running everything seems
>>
On 01/02/2019 10:50, Jan Beulich wrote:
On 01.02.19 at 08:26, wrote:
>> While working on my core scheduling series I stumbled over the periodic
>> timer. Could it be this timer never worked correctly?
>>
>> When the vcpu with an active periodic timer is running everything seems
>> to be
Hi,
On 2/1/19 10:02 AM, Andrii Anisov wrote:
On 01.02.19 01:14, Julien Grall wrote:
With the current interface workaround, we are still playing with devil
(see [2]). So it would be nice to get a new interface that does not
use virtual address.
I'm sorry for my ignorance, I know nearly
On 01.02.19 12:16, Julien Grall wrote:
The thing is the presence of the printk is not the real problem.
It is the problem when the intention is to play in a sandbox with different
things.
It only tells you the mapping is inexistent. The problem is if in debug build
you don't see at all
Hi,
We spoke about SPIs in the previous version. Why aren't they
de-activated here?
On 1/30/19 2:00 PM, Peng Fan wrote:
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because we also need
On 01/02/2019 12:14, Jan Beulich wrote:
> All,
>
> both releases would have been due last week. Please point out
> backports you find missing from their respective staging branches,
> but which you consider relevant.
For 4.10.3:
>>> On 01.02.19 at 12:23, wrote:
> On 01/02/2019 12:14, Jan Beulich wrote:
>> All,
>>
>> both releases would have been due last week. Please point out
>> backports you find missing from their respective staging branches,
>> but which you consider relevant.
>
> For 4.10.3:
>
>
On 01/02/2019 09:39, Oleksandr Andrushchenko wrote:
> On 1/31/19 11:44 PM, Stefano Stabellini wrote:
>> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>>> Hello,
>>>
>>> I am working on porting an out-of-tree kernel driver to the kernel
>>> 5.0 and that driver uses functionality provided by
>>> On 31.01.19 at 19:24, wrote:
> Passing a 32-bit integer index into an array with entries containing less
> than
> 32 bits of data is wasteful, and creates an unnecessary error condition of
> passing an out-of-range index.
>
> The width of the X86EMUL_OPC() encoding is currently 20 bits for
On 31.01.19 23:56, Stefano Stabellini wrote:
I ran into this problem as well not too long ago too. It is very
annoying and it is basically impossible to work-around, the only thing
possible would be to suppress the warning, but that doesn't even count
as a work-around :-)
Well, yet it is
All,
both releases would have been due last week. Please point out
backports you find missing from their respective staging branches,
but which you consider relevant.
Please note that 4.9.4 is expected to be the last xenproject.org
managed release from its branch.
Jan
>>> On 31.01.19 at 20:31, wrote:
> On 23/01/2019 11:51, Norbert Manthey wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -37,6 +37,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -2102,7 +2103,7 @@ int
>>> On 01.02.19 at 00:45, wrote:
> flight 132630 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/132630/
>
> Failures :-/ but no regressions.
>
> Tests which are failing intermittently (not blocking):
> test-amd64-amd64-xl-qemuu-debianhvm-amd64 16
>>> On 01.02.19 at 08:26, wrote:
> While working on my core scheduling series I stumbled over the periodic
> timer. Could it be this timer never worked correctly?
>
> When the vcpu with an active periodic timer is running everything seems
> to be fine. But when not running the timer is stopped
On 01.02.19 01:14, Julien Grall wrote:
With the current interface workaround, we are still playing with devil (see
[2]). So it would be nice to get a new interface that does not use virtual
address.
I'm sorry for my ignorance, I know nearly nothing about runstate areas
implementation, but
On 2/1/19 10:07 AM, Andrii Anisov wrote:
On 31.01.19 23:56, Stefano Stabellini wrote:
I ran into this problem as well not too long ago too. It is very
annoying and it is basically impossible to work-around, the only thing
possible would be to suppress the warning, but that doesn't even
On 2/1/19 11:14 AM, Juergen Gross wrote:
> On 01/02/2019 09:39, Oleksandr Andrushchenko wrote:
>> On 1/31/19 11:44 PM, Stefano Stabellini wrote:
>>> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
Hello,
I am working on porting an out-of-tree kernel driver to the kernel
5.0
On 01/02/2019 07:26, Juergen Gross wrote:
> While working on my core scheduling series I stumbled over the periodic
> timer. Could it be this timer never worked correctly?
>
> When the vcpu with an active periodic timer is running everything seems
> to be fine. But when not running the timer is
Hello,
On 01.02.19 12:12, Julien Grall wrote:
This is actually a shared page, the page is allocated by the domain and shared
with Xen. So what do you mean?
I'm curious if it can be allocated on hypervisor side.
That's not a link but a Message-ID. You can either use your favorite client for
Hi Andrii,
On 2/1/19 10:35 AM, Andrii Anisov wrote:
On 01.02.19 12:16, Julien Grall wrote:
The thing is the presence of the printk is not the real problem.
It is the problem when the intention is to play in a sandbox with
different things.
I don't consider polluting your log a real
On 2/1/19 10:35 AM, Andrii Anisov wrote:
Hello,
Hi,
On 01.02.19 12:12, Julien Grall wrote:
This is actually a shared page, the page is allocated by the domain
and shared with Xen. So what do you mean?
I'm curious if it can be allocated on hypervisor side.
There are very limited case
>>> On 01.02.19 at 15:06, wrote:
> On 2/1/19 09:23, Jan Beulich wrote:
> On 31.01.19 at 21:02, wrote:
>>> On 31/01/2019 16:19, Jan Beulich wrote:
> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
> if ( a.index >= HVM_NR_PARAMS )
> return -EINVAL;
>
> +
c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
ICEBP debug exceptions, but didn't account for the fact that
svm_get_insn_len() (previously __get_instruction_length) can fail and may
already raise #GP for the guest.
If svm_get_insn_len() fails, return back to guest
On 01/02/2019 16:02, Wei Liu wrote:
> On Fri, Feb 01, 2019 at 03:59:58PM +0100, Juergen Gross wrote:
>> On 01/02/2019 14:42, Doug Goldstein wrote:
>>> On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote:
Make qemu-smoke-x86-64.sh take a variant argument. Make two new tests
in
On Fri, Feb 01, 2019 at 04:06:13PM +0100, Juergen Gross wrote:
> On 01/02/2019 16:02, Wei Liu wrote:
> > On Fri, Feb 01, 2019 at 03:59:58PM +0100, Juergen Gross wrote:
> >> On 01/02/2019 14:42, Doug Goldstein wrote:
> >>> On Thu, Jan 24, 2019 at 03:24:11PM +, Wei Liu wrote:
> Make
On 2/1/19 4:49 PM, Andrew Cooper wrote:
c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
ICEBP debug exceptions, but didn't account for the fact that
svm_get_insn_len() (previously __get_instruction_length) can fail and may
already raise #GP for the guest.
If
On Fri, Feb 1, 2019 at 7:49 AM Andrew Cooper wrote:
>
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for
Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
IOMMU hook accesses") declared the AMD and INTEL variants of struct
iommu_ops as __initconstrel, but those are needed for system resume,
too.
Fix that by modifying them to be not located in the init data segment.
On 01/02/2019 15:13, Juergen Gross wrote:
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
> IOMMU hook accesses") declared the AMD and INTEL variants of struct
> iommu_ops as __initconstrel, but those are needed for system resume,
> too.
>
> Fix that by modifying them to be
On 01/02/2019 14:52, Tamas K Lengyel wrote:
> On Fri, Feb 1, 2019 at 7:49 AM Andrew Cooper
> wrote:
>> c/s 9338a37d "x86/svm: implement debug events" added support for
>> introspecting
>> ICEBP debug exceptions, but didn't account for the fact that
>> svm_get_insn_len() (previously
On 01/02/2019 15:49, Andrew Cooper wrote:
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
>
Enabling and disabling one of the two isn't tested in OSSTest yet.
Signed-off-by: Wei Liu
---
We need to sort this out for 4.12 release.
On the one hand, exposing them seems risky.
On the other hand, if there are bugs which cause xen to wander into a
path which hits BUG or ASSERT, they are
>>> On 01.02.19 at 16:13, wrote:
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -570,7 +570,7 @@ static void amd_dump_p2m_table(struct domain *d)
> amd_dump_p2m_table_level(hd->arch.root_table, hd->arch.paging_mode, 0,
> 0);
> }
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
SCIF and SCIFA have lot in common, though SCIFA has different
offsets and bits for some registers.
The "data" field in struct dt_device_match is used for recognizing
what interface is present on a
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.
Actually existing SCIF UART support (debug-scif.inc) and
newly added SCIFA UART support (debug-scifa.inc) differ only
in registers offsets.
Signed-off-by:
On 1/31/19 17:19, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> There are multiple arrays in the HVM interface that are accessed
>> with indices that are provided by the guest. To avoid speculative
>> out-of-bound accesses, we use the array_index_nospec macro.
>>
>> When blocking
flight 132702 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132702/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 1/31/19 16:05, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind,
>> evtchn_port_t port)
>> if ( (virq < 0) || (virq >=
On 1/31/19 17:05, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> When interacting with io apic, a guest can specify values that are used
>> as index to structures, and whose values are not compared against
>> upper bounds to prevent speculative out-of-bound accesses. This change
>>
On 2/1/19 09:23, Jan Beulich wrote:
On 31.01.19 at 21:02, wrote:
>> On 31/01/2019 16:19, Jan Beulich wrote:
@@ -4104,6 +4108,12 @@ static int hvmop_set_param(
if ( a.index >= HVM_NR_PARAMS )
return -EINVAL;
+/*
+ * Make sure the guest
From: Oleksandr Tyshchenko
Current sentence is not entirely correct. Since SCIF0 interface is
applicable for Lager board, but is not applicable for all R-Car H2
based boards. For example, Stout board uses SCIFA0 interface.
Signed-off-by: Oleksandr Tyshchenko
---
docs/misc/arm/early-printk.txt
On Thu, Jan 31, 2019 at 6:04 PM Heiko Stuebner wrote:
>
> Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder:
> > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote:
> > >
> > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> > > > Previouly drivers
On 31. 01. 19, 17:00, Borislav Petkov wrote:
>> Documentation/asm-annotations.rst | 217 ++
>
> I guess you wanna integrate that into the doc hierarchy. Hunk ontop:
>
> ---
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index c858c2e66e36..754055d9565c
>>> On 01.02.19 at 14:45, wrote:
> On 1/31/19 16:05, Jan Beulich wrote:
> On 29.01.19 at 15:43, wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind,
>>> evtchn_port_t port)
>>> if (
>>> On 01.02.19 at 16:43, wrote:
> Enabling and disabling one of the two isn't tested in OSSTest yet.
While I'm not opposed to the addition, I intentionally didn't ask
for doing so when the options got introduced, not the least
because of ...
> @@ -68,7 +69,7 @@ config PV_LINEAR_PT
>
>
On 01/02/2019 15:58, Jan Beulich wrote:
On 01.02.19 at 15:49, wrote:
>> c/s 9338a37d "x86/svm: implement debug events" added support for
>> introspecting
>> ICEBP debug exceptions, but didn't account for the fact that
>> svm_get_insn_len() (previously __get_instruction_length) can fail and
>>> On 01.02.19 at 17:29, wrote:
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
> IOMMU hook accesses") introduced iommu_ops initialized at boot time
> with data declared as __initconstrel.
>
> On Intel systems there is another path where iommu_ops is initialized
> and
>>> On 01.02.19 at 17:25, wrote:
> On 01/02/2019 15:58, Jan Beulich wrote:
> On 01.02.19 at 15:49, wrote:
>>> c/s 9338a37d "x86/svm: implement debug events" added support for
>>> introspecting
>>> ICEBP debug exceptions, but didn't account for the fact that
>>> svm_get_insn_len()
>>> On 01.02.19 at 15:49, wrote:
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
>
> If
On Fri, Feb 01, 2019 at 09:01:57AM -0700, Jan Beulich wrote:
> >>> On 01.02.19 at 16:43, wrote:
> > Enabling and disabling one of the two isn't tested in OSSTest yet.
>
> While I'm not opposed to the addition, I intentionally didn't ask
> for doing so when the options got introduced, not the
On 01/02/2019 16:44, Jan Beulich wrote:
On 01.02.19 at 16:13, wrote:
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -570,7 +570,7 @@ static void amd_dump_p2m_table(struct domain *d)
>>
Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
IOMMU hook accesses") introduced iommu_ops initialized at boot time
with data declared as __initconstrel.
On Intel systems there is another path where iommu_ops is initialized
and this path is relevant on resume after returning
On 01/02/2019 16:04, Wei Liu wrote:
> On Fri, Feb 01, 2019 at 09:01:57AM -0700, Jan Beulich wrote:
> On 01.02.19 at 16:43, wrote:
>>> Enabling and disabling one of the two isn't tested in OSSTest yet.
>> While I'm not opposed to the addition, I intentionally didn't ask
>> for doing so when
On 01/02/2019 17:29, Juergen Gross wrote:
> Commit 32a5ea00ec75ef53e ("IOMMU/x86: remove indirection from certain
> IOMMU hook accesses") introduced iommu_ops initialized at boot time
> with data declared as __initconstrel.
>
> On Intel systems there is another path where iommu_ops is initialized
flight 132708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132708/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
> Hi Stefano,
>
> On 1/31/19 9:56 PM, Stefano Stabellini wrote:
> > On Thu, 31 Jan 2019, Julien Grall wrote:
> > > On 31/01/2019 12:00, Andrii Anisov wrote:
> > > > Hello Julien,
> > > >
> > > > On 31.01.19 13:37, Julien Grall wrote:
On 01/02/2019 16:55, Jan Beulich wrote:
On 01.02.19 at 17:25, wrote:
>> On 01/02/2019 15:58, Jan Beulich wrote:
>> On 01.02.19 at 15:49, wrote:
c/s 9338a37d "x86/svm: implement debug events" added support for
introspecting
ICEBP debug exceptions, but didn't account for
On Thu, Jan 31, 2019 at 6:31 PM Christopher Lameter wrote:
>
> On Thu, 31 Jan 2019, Thomas Garnier wrote:
>
> > The per-cpu symbols are in a section that is zero based to create
> > offsets. The compiler doesn't see them as offsets but as relative
> > symbol and try to relocate them. Given the
Hi,
On 01/02/2019 16:53, Roger Pau Monné wrote:
On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
On 1/31/19 9:56 PM, Stefano Stabellini wrote:
On Thu, 31 Jan 2019, Julien Grall wrote:
On 31/01/2019 12:00, Andrii Anisov wrote:
On 31.01.19 13:37, Julien Grall wrote:
So, I've got
+Juergen
On Fri, 1 Feb 2019, Julien Grall wrote:
> Hi Andrii,
>
> On 2/1/19 10:35 AM, Andrii Anisov wrote:
> >
> >
> > On 01.02.19 12:16, Julien Grall wrote:
> > > The thing is the presence of the printk is not the real problem.
> > It is the problem when the intention is to play in a sandbox
On 1/30/19 8:51 AM, Roger Pau Monné wrote:
On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
Allow device model running in stubdomain to enable/disable MSI(-X),
bypassing pciback. While pciback is still used to access config space
from within stubdomain, it refuse to
flight 132710 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132710/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR.
vs. 132708
On 1/30/19 3:22 AM, Juergen Gross wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.
>
> Trying to do so would result in cases like the following:
>
> [ 584.559652] [ cut here ]
> [ 584.564897] WARNING: CPU: 2 PID: 1 at
On Fri, 1 Feb 2019, George Dunlap wrote:
> On Tue, Jan 22, 2019 at 9:17 AM Jan Beulich wrote:
> >
> > >>> On 22.01.19 at 00:41, wrote:
> > > We haven't managed to reach consensus on this topic. Your view might be
> > > correct, but it is not necessarily supported by compilers' behavior,
> > >
flight 132712 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132712/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Tue, Jan 22, 2019 at 9:17 AM Jan Beulich wrote:
>
> >>> On 22.01.19 at 00:41, wrote:
> > We haven't managed to reach consensus on this topic. Your view might be
> > correct, but it is not necessarily supported by compilers' behavior,
> > which depends on the opinion of compilers engineers on
flight 132654 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132654/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 02021d2ea4f64be3f29d4a0d9707a60889f3f71b
baseline version:
ovmf
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-credit2
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
flight 132640 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 129313
flight 132655 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132655/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
flight 132647 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132647/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
80 matches
Mail list logo
