On 10/16/18 7:26 PM, George Dunlap wrote:
> On 09/27/2018 08:58 AM, Razvan Cojocaru wrote:
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
>>
>> Both altp2m get/set mem access functions
> -Original Message-
> From: Roger Pau Monne
> Sent: 16 October 2018 17:27
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; George Dunlap
> ; Andrew Cooper ; Wei
> Liu ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH] x86/mm/p2m: don't needlessly limit MMIO
> mapping order to 4k
>
flight 128846 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128846/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b7dcf31402f410c53242839271ba3b94b619
baseline version:
ovmf 25d310d9b6187ca2e770b
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Alexander Schulz - XCP-ng Project Member
> Sent: 16 October 2018 21:28
> To: xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Ian Jackson ;
> c...@schulzalex.de
> Subject: [Xen-devel] [PATCH]
The P2M code currently contains many loops to deal with the fact that,
while it may be require to handle page orders greater than 4k, the
IOMMU map and unmap functions do not.
This patch adds a page_order parameter to those functions and implements
the necessary loops within. This allows the P2M co
Hi Bart,
On Tue, Oct 16, 2018 at 03:42:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for vi
On 16/10/2018 16:33, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig beh
flight 128822 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10
fail in 128696 REGR. vs.
flight 128850 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebsd 6 host-bu
This patch adds a couple of regs to the vm_event that are used by
the introspection. The base, limit and ar
bits are compressed into a uint64_t union so as not to enlarge the
vm_event.
Signed-off-by: Alexandru Isaila
---
Changes since V1:
- Add helper function for packing
- Chang
flight 128849 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128849/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 7559ab7830c3e1594cd73efd3f1acbb171036728
baseline version:
xen 9266
On 17/10/18 10:39, Alexandru Stefan ISAILA wrote:
> This patch adds a couple of regs to the vm_event that are used by
> the introspection. The base, limit and ar
> bits are compressed into a uint64_t union so as not to enlarge the
> vm_event.
>
> Signed-off-by: Alexandru Isaila
>
> ---
> Changes s
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
qemu-xen runnning in a Linux-based stubdomain."):
> From those two options I'd prefer multiple xenstore keys as much
> cleaner. We do have them as an array in libxl already.
>
> So, let image/dmargs be actually a directo
This run is configured for baseline tests only.
flight 75437 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75437/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On 17.10.2018 12:49, Andrew Cooper wrote:
> On 17/10/18 10:39, Alexandru Stefan ISAILA wrote:
>> This patch adds a couple of regs to the vm_event that are used by
>> the introspection. The base, limit and ar
>> bits are compressed into a uint64_t union so as not to enlarge the
>> vm_event.
>>
>>
On 17/10/18 12:11, Alexandru Stefan ISAILA wrote:
>
>>> +uint16_t sel;
>>> +union
>>> +{
>>> +uint64_t bytes;
>>> +struct
>>> +{
>>> +uint64_t base :32;
>> Better known as... ?
> Sorry I don't follow here
An aligned 32-bit bitfield of a uin64_t
On 17/10/18 09:19, Paul Durrant wrote:
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 55df18501e..b264a97bd8 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -683,41 +684,13 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_,
> mfn_t mfn
> -Original Message-
> From: Andrew Cooper
> Sent: 17 October 2018 12:20
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Jun Nakajima ; Kevin T
flight 128824 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128824/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128688
test-armhf-armhf-libvirt 14 sav
On 05/10/18 18:02, Andrew Cooper wrote:
> When using shadow paging, EFER.NX is a Xen controlled bit, and is required by
> the shadow pagefault handler to distinguish instruction fetches from data
> accesses.
>
> This can be observed by a guest which has NX and SMEP clear but SMAP active by
> attemp
Hi,
I have started finding which patch introduced Armv8 Secondary CPUs issue.
I just want to start PV vdevb before domainU debian rootfs mount. Is it
possible?
Thanks,
Omkar B
On Mon, Oct 8, 2018 at 4:00 PM Julien Grall wrote:
>
>
> On 08/10/2018 10:12, Omkar Bolla wrote:
> > Hi,
>
> Hi,
>
>
These fields have existed since the SVM code was first introduced.
The earliest reference I can find is c/s d1bd157fbc9 which is unforunately a
rebase & squash of a separate dev tree. Looking a the commit message, I'm
guessing it was introduced by:
> user:twol...@xen-trw1.site
> date
On 16/10/18 15:41, Paul Durrant wrote:
> The P2M common code currently restricts the MMIO mapping order of any
> domain with IOMMU mappings, but that is not using shared tables, to 4k.
> This has been shown to have a huge performance cost when passing through
> a PCI device with a very large BAR (e
On 10/4/18 6:20 PM, Jan Beulich wrote:
> Roger recently has posted a patch adding rangeset_merge(), which I think
> is more general than your rangeset_copy(). That said, I'm in no way
> convinced copying (and then keeping in sync) the range sets across the
> altp2m-s is the best approach. It may we
On 17/10/18 14:26, Razvan Cojocaru wrote:
> On 10/4/18 6:20 PM, Jan Beulich wrote:
>> Roger recently has posted a patch adding rangeset_merge(), which I think
>> is more general than your rangeset_copy(). That said, I'm in no way
>> convinced copying (and then keeping in sync) the range sets across
On 10/17/18 4:30 PM, Andrew Cooper wrote:
> On 17/10/18 14:26, Razvan Cojocaru wrote:
>> On 10/4/18 6:20 PM, Jan Beulich wrote:
>>> Roger recently has posted a patch adding rangeset_merge(), which I think
>>> is more general than your rangeset_copy(). That said, I'm in no way
>>> convinced copying
On 10/5/18 2:00 PM, Razvan Cojocaru wrote:
> On 9/27/18 2:25 PM, George Dunlap wrote:
>> The name of the "with_gla" flag is confusing; it has nothing to do
>> with the existence or lack thereof of a faulting GLA, but rather where
>> the fault originated. The npfec.kind value is always valid, and
>
It would be good for me to keep an eye on the patches that touch Xen
support in Linux to try to spot changes that break Xen on ARM early on.
Signed-off-by: Stefano Stabellini
diff --git a/MAINTAINERS b/MAINTAINERS
index 40082e4..0c1984e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16013,6 +160
On Tue, 16 Oct 2018, Tamas K Lengyel wrote:
> On Mon, Oct 15, 2018 at 7:14 PM Stefano Stabellini
> wrote:
> >
> > On Mon, 15 Oct 2018, Tamas K Lengyel wrote:
> > > On Mon, Oct 15, 2018 at 3:57 AM Stefano Stabellini
> > > wrote:
> > > >
> > > > Initialize variable *access before returning it back
On Tue, 16 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
> > On 15/10/2018 08:25, Julien Grall wrote:
> > > Hi,
> > >
> > > On 10/10/2018 11:35 PM, Stefano Stabellini wrote:
> > > > On Tue, 28 Aug 2018, Julien Grall wrote:
> > > > > On 11/08/18
> -Original Message-
> From: Andrew Cooper
> Sent: 17 October 2018 14:24
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: George Dunlap ; Jan Beulich
> ; Wei Liu
> Subject: Re: [PATCH] x86/mm/p2m: don't needlessly limit MMIO mapping order
> to 4k
>
> On 16/10/18 15:41, Paul Durra
On Tue, 16 Oct 2018, Julien Grall wrote:
> Hi,
>
> Sorry I forgot to answer to the rest of the e-mail.
>
> On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
> > On 15/10/2018 08:25, Julien Grall wrote:
> > > > > > + bool hwdom_access; /* HW domain gets access regardless. */
> > > > > > +};
Hi Stefano,
On 17/10/2018 15:03, Stefano Stabellini wrote:
On Tue, 16 Oct 2018, Julien Grall wrote:
Hi,
Sorry I forgot to answer to the rest of the e-mail.
On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
On 15/10/2018 08:25, Julien Grall wrote:
+ bool hwdom_access; /* HW domain gets
Hi all,
This short patch series fixes a few issues discovered by the safety
certifications code scanner. The first two patches address simple
variable initializations concerns. The third patch introduces a new
macro that is used throughout the code in patch #4 to access _stext,
_etext pointers and
Initialize variable target before passing it as a parameter.
It makes the code a bit nicer and it is a safety certification
requirement.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- improve comment
---
xen/arch/arm/vgic-v2.c | 2 +-
xen/arch/arm/vgic-v3.c | 2 +-
2 files changed, 2 ins
Initialize variable *access before returning it back to the caller.
It makes the code a bit nicer and it is a safety certification
requirement.
Signed-off-by: Stefano Stabellini
CC: rcojoc...@bitdefender.com
CC: Tamas K Lengyel
---
Changes in v2:
- improve comment
- use p2m->default_access
---
Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.
RELOC_HIDE is needed when accessing symbols such as _stext and _etext
because the C standard forbids comparisons between pointers pointing to
diffe
Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
is only required when comparing pointers, but use it everywhere to avoid
confusion.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
CC: andrew.coop...@citrix.com
---
Changes in v2:
- cast return of __symbol to char* wh
On 10/17/18 5:31 PM, Stefano Stabellini wrote:
> Initialize variable *access before returning it back to the caller.
> It makes the code a bit nicer and it is a safety certification
> requirement.
>
> Signed-off-by: Stefano Stabellini
> CC: rcojoc...@bitdefender.com
> CC: Tamas K Lengyel
Acked-
Hi,
On 17/10/2018 15:31, Stefano Stabellini wrote:
Initialize variable target before passing it as a parameter.
It makes the code a bit nicer and it is a safety certification
requirement.
While I know why this is a certification requirement, it may not be the
case for other on the mailing lis
On 17/10/2018 15:31, Stefano Stabellini wrote:
Initialize variable *access before returning it back to the caller.
It makes the code a bit nicer and it is a safety certification
requirement.
Same as previous patch.
Signed-off-by: Stefano Stabellini
CC: rcojoc...@bitdefender.com
CC: Tamas
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > It will be #included by a file in a xen/arch/arm subdirectory.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > xen/arch/arm/domain_build.c | 2 +-
> > xen/arch/arm/kernel.c
On 17/10/2018 15:31, Stefano Stabellini wrote:
Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
to be used everywhere symbols such as _stext and _etext are used in the
code.
RELOC_HIDE is needed when accessing symbols such as _stext and _etext
because the C standard for
On 10/17/18 8:08 AM, Andrew Cooper wrote:
> On 05/10/18 18:02, Andrew Cooper wrote:
>> When using shadow paging, EFER.NX is a Xen controlled bit, and is required by
>> the shadow pagefault handler to distinguish instruction fetches from data
>> accesses.
>>
>> This can be observed by a guest which
On 10/17/18 8:47 AM, Andrew Cooper wrote:
> These fields have existed since the SVM code was first introduced.
>
> The earliest reference I can find is c/s d1bd157fbc9 which is unforunately a
> rebase & squash of a separate dev tree. Looking a the commit message, I'm
> guessing it was introduced b
On 10/17/18 9:44 AM, Stefano Stabellini wrote:
> It would be good for me to keep an eye on the patches that touch Xen
> support in Linux to try to spot changes that break Xen on ARM early on.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
>
> diff --git a/MAINTAINERS b/MAIN
Hi,
On 17/10/2018 15:31, Stefano Stabellini wrote:
Use __symbol everywhere _stext, _etext, etc. are used. Technically, it
is only required when comparing pointers, but use it everywhere to avoid
Well no. It is also required when substracting pointers (see [1]).
confusion.
[...]
diff --gi
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > Introduce vpl011 support to guests started from Xen: it provides a
> > simple way to print output from a guest, as most guests come with a
> > pl011 driver. It is also able to provide a working co
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > Move generic initializations out of construct_dom0 so that they can be
> > reused.
> >
> > Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
> >
> > No functional changes in this patch
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > +static int __init make_gic_domU_node(const struct domain *d, void *fdt)
> > +{
> > +switch ( gic_hw_version() )
>
> While I understand that today domains will use the same GIC versio
Alexander Schulz - XCP-ng Project Member writes ("[PATCH] Reservation of PCI
device range 0xc200-0xc2ff to XCP-ng Project"):
> We are the XCP-ng project (https://xcp-ng.org) and want to distribute
> our own PV-Tools (maybe also per windows updates) so we need an extra range.
Thanks. I acked you
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
qemu-xen runnning in a Linux-based stubdomain."):
> [stuff]
So, I only got a little way through this series, but it was a while
ago and you say things are done differently now. I'm not sure if it
is useful for me to rev
Hi,
>
> The device tree with everything seems to be system.dts, that was enough
> :-) I don't need the dtsi files you used to build the final dts, I only
> need the one you use in uboot and for your guest.
I wasn't sure so I sent everything, sorry for being bombarded with
all those files. :-)
>
On Mon, 15 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
> > To avoid mixing the output of different domains on the console, buffer
> > the output chars and print line by line. Unless the domain has input
> > from the serial, in which case we want to print
On Wed, Oct 17, 2018 at 7:41 AM Razvan Cojocaru
wrote:
>
> On 10/5/18 2:00 PM, Razvan Cojocaru wrote:
> > On 9/27/18 2:25 PM, George Dunlap wrote:
> >> The name of the "with_gla" flag is confusing; it has nothing to do
> >> with the existence or lack thereof of a faulting GLA, but rather where
> >
The P2M common code currently restricts the MMIO mapping order of any
domain with IOMMU mappings, but that is not using shared tables, to 4k.
This has been shown to have a huge performance cost when passing through
a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest
boot time
On Mon, Oct 08, 2018 at 04:03:54PM -0700, Stefano Stabellini wrote:
> Introduce a device tree binding for Xen reserved-memory regions. They
> are used to share memory across VMs from the VM config files. (See
> static_shm config option.)
>
> Signed-off-by: Stefano Stabellini
checkpatch.pl compl
flight 75438 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75438/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
Am 17.10.2018 um 17:14 schrieb Ian Jackson:
Alexander Schulz - XCP-ng Project Member writes ("[PATCH] Reservation of PCI device
range 0xc200-0xc2ff to XCP-ng Project"):
We are the XCP-ng project (https://xcp-ng.org) and want to distribute
our own PV-Tools (maybe also per windows updates) so we
On Tue, Oct 16, 2018 at 10:28:04PM +0200, Alexander Schulz - XCP-ng Project
Member wrote:
> We are the XCP-ng project (https://xcp-ng.org) and want to distribute our
> own PV-Tools (maybe also per windows updates) so we need an extra range.
>
> We also registered a PCI-Device:
>
> "XCP-ng Projec
---
cr-for-branches | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cr-for-branches b/cr-for-branches
index 6f544379..f7e4caea 100755
--- a/cr-for-branches
+++ b/cr-for-branches
@@ -31,7 +31,7 @@ scriptoptions="$1"; shift
LOGFILE=tmp/cr-for-branches.log
export LOGFILE
-: ${
On Wed, Oct 17, 2018 at 04:16:03PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
> qemu-xen runnning in a Linux-based stubdomain."):
> > [stuff]
>
> So, I only got a little way through this series, but it was a while
> ago and you say thi
On 17/10/2018 15:42, Stefano Stabellini wrote:
On Mon, 15 Oct 2018, Julien Grall wrote:
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 2 +-
Alexander Schulz - XCP-ng Project Member writes ("[PATCH] Reservation of PCI
device range 0xc200-0xc2ff to XCP-ng Project"):
> We are the XCP-ng project (https://xcp-ng.org) and want to distribute
> our own PV-Tools (maybe also per windows updates) so we need an extra range.
>
> We also register
flight 128852 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128852/
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 1
On 17/10/18 17:11, Julien Grall wrote:
>
>
> On 17/10/2018 15:42, Stefano Stabellini wrote:
>> On Mon, 15 Oct 2018, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 05/10/2018 19:47, Stefano Stabellini wrote:
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by:
On Tue, Oct 16, 2018 at 10:28:04PM +0200, Alexander Schulz - XCP-ng Project
Member wrote:
> We are the XCP-ng project (https://xcp-ng.org) and want to distribute our
> own PV-Tools (maybe also per windows updates) so we need an extra range.
>
> We also registered a PCI-Device:
>
> "XCP-ng Projec
Thanks for all your support!
Alex
Am 17. Oktober 2018 18:33:45 MESZ schrieb Wei Liu :
>On Tue, Oct 16, 2018 at 10:28:04PM +0200, Alexander Schulz - XCP-ng
>Project Member wrote:
>> We are the XCP-ng project (https://xcp-ng.org) and want to distribute
>our
>> own PV-Tools (maybe also per windows
flight 128829 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-armhf-pvops 5 host-
flight 128854 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128854/
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 1
This run is configured for baseline tests only.
flight 75440 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75440/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On Fri, Aug 24, 2018 at 5:36 PM Dario Faggioli wrote:
>
> Hello,
>
> As anticipated here:
> https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02052.html
>
> Here's a preliminary version of my work, trying to implement
> core-scheduling in Xen.
>
> First of all, this deals with Credit
This run is configured for baseline tests only.
flight 75441 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75441/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
flight 128841 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail REGR. vs.
128258
test-armhf-arm
flight 128833 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128833/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128724
test-armhf-armhf-libvirt-raw 13 saveresto
flight 128857 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128857/
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 1
flight 128856 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128856/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3a0329bed2a2c7d1ba45bd2376a2320141ef2bec
baseline version:
ovmf b7dcf31402f410c53
flight 128835 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
test-amd
flight 128860 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128860/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail REGR. vs.
128856
version targeted fo
This run is configured for baseline tests only.
flight 75444 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75444/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128837 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128837/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken in 128744
Tests
81 matches
Mail list logo
