>>> Julien Grall 03/20/19 12:19 AM >>>
>--- a/xen/drivers/char/console.c
>+++ b/xen/drivers/char/console.c
>@@ -1320,7 +1320,7 @@ static int __init debugtrace_init(void)
>}
>__initcall(debugtrace_init);
>
>-#endif /* !NDEBUG */
>+#endif /* !DEBUG_TRACE_DUMP */
But it's CONFIG_DEBUG_TRACE now,
>>> Julien Grall 03/20/19 12:20 AM >>>
>Signed-off-by: Julien Grall
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> Julien Grall 03/20/19 12:21 AM >>>
>The function is unused and could potentially lead a to trigger the
>BUG_ON() in p2m_change_type_one if misused as the p2m type is not
>sanitized.
>
>So remove it.
I don't think I agree - the entire file is effectively unused, and hence
removal should
perha
>>> Julien Grall 03/20/19 12:21 AM >>>
>Signed-off-by: Julien Grall
Acked-by: Jan Beulich
>--- a/xen/arch/x86/mm.c
>+++ b/xen/arch/x86/mm.c
>@@ -2003,7 +2003,7 @@ static int free_l4_table(struct page_info *page)
>* 2. We never call _put_page_type() on a page while holding its page lock.
>*
>*
flight 133913 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133913/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 130965
Tests
This run is configured for baseline tests only.
flight 83754 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83754/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 133914 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133914/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
test-am
On Tue, Mar 19, 2019 at 09:39:59PM +, Woods, Brian wrote:
>On 3/19/19 3:22 PM, Brian Woods wrote:
>> On 3/11/19 2:57 AM, Chao Gao wrote:
>>> Major changes in version 6:
>>> - run wbinvd before updating microcode (patch 10)
>>> - add an userspace tool for late microcode update (patch 1)
>>>
> On 18/03/2019 06:50, rambl...@sina.com wrote:
> > Hello,
> Hello,
> > I'm researching xen for automotive use case and I see a presentation called:
> > "Design and Implementation of Automotive Virtualization Based on Xen -
> > Sung-Min
> > Lee, Samsung Electronics"
> > on Xen Developer and Desi
flight 133942 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 133615
version t
On 19/03/2019 23:23, Julien Grall wrote:
> The format %pd will already prefix the domain ID with 'd'. So avoid to
> prefix with 'Dom'.
>
> Signed-off-by: Julien Grall
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
ht
On 19/03/2019 23:20, Julien Grall wrote:
> The function is unused and could potentially lead a to trigger the
> BUG_ON() in p2m_change_type_one if misused as the p2m type is not
> sanitized.
>
> So remove it.
>
> Signed-off-by: Julien Grall
Either the entire file goes, or this function stays. It
On 03/19/19 15:03, Anthony PERARD wrote:
> On Thu, Mar 14, 2019 at 07:45:56PM +, Igor Druzhinin wrote:
>> On 14/03/2019 17:41, Anthony PERARD wrote:
>>> Hi,
>>>
>>> On Wed, Mar 06, 2019 at 12:40:54PM +, Igor Druzhinin wrote:
This aperture doesn't exist in OVMF and trying to use it caus
On Tue, Mar 19, 2019 at 04:20:04PM +, Andrew Cooper wrote:
> This is a project I've been musing over for a long time now, to try and
> address Xen's almost complete absense of documentation.
>
> This series, plus some other in-progress conversion of the command line doc,
> is available to view
On 20/03/2019 11:20, Wei Liu wrote:
> On Tue, Mar 19, 2019 at 04:20:04PM +, Andrew Cooper wrote:
>> This is a project I've been musing over for a long time now, to try and
>> address Xen's almost complete absense of documentation.
>>
>> This series, plus some other in-progress conversion of the
On Wed, Mar 20, 2019 at 11:23:57AM +, Andrew Cooper wrote:
> On 20/03/2019 11:20, Wei Liu wrote:
> > On Tue, Mar 19, 2019 at 04:20:04PM +, Andrew Cooper wrote:
> >> This is a project I've been musing over for a long time now, to try and
> >> address Xen's almost complete absense of document
On 20/03/2019 11:28, Wei Liu wrote:
> On Wed, Mar 20, 2019 at 11:23:57AM +, Andrew Cooper wrote:
>> On 20/03/2019 11:20, Wei Liu wrote:
>>> On Tue, Mar 19, 2019 at 04:20:04PM +, Andrew Cooper wrote:
This is a project I've been musing over for a long time now, to try and
address Xe
Andrew Cooper writes ("Re: [PATCH 0/3] docs: User oriented documentation"):
> The point of using virtualenv is to get a known-compatible set of
> dependencies. See docs/sphinx/requirements.txt in patch 1.
I don't think we need to have more curlbashware in the Xen build tree.
Sphinx 1.4.9 is what i
On Wed, Mar 20, 2019 at 11:35:10AM +, Andrew Cooper wrote:
> On 20/03/2019 11:28, Wei Liu wrote:
> > On Wed, Mar 20, 2019 at 11:23:57AM +, Andrew Cooper wrote:
> >> On 20/03/2019 11:20, Wei Liu wrote:
> >>> On Tue, Mar 19, 2019 at 04:20:04PM +, Andrew Cooper wrote:
> This is a proj
On Tue, Mar 19, 2019 at 07:34:45PM +0100, Markus Armbruster wrote:
> = hw/xenpv/xen_machine_pv.c =
> Stefano Stabellini (supporter:X86)
> Anthony Perard (supporter:X86)
> Paul Durrant (supporter:X86)
> xen-devel@lists.xenproject.org (open list:X86)
That machine requires Xen
On 20/03/2019 11:49, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 0/3] docs: User oriented documentation"):
>> The point of using virtualenv is to get a known-compatible set of
>> dependencies. See docs/sphinx/requirements.txt in patch 1.
> I don't think we need to have more curlbashware
This run is configured for baseline tests only.
flight 83756 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/83756/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
Currently the comment at line #267 claims that the value should be
expressed in number logical sectors, whereas the comment at line #613
states that the value should be expressed strictly in units of 512 bytes.
Signed-off-by: Paul Durrant
---
Cc: Konrad Rzeszutek Wilk
Looking at xen-blkfront in
Wei Liu writes ("[PATCH] libxc: fix HVM core dump"):
> f969bc9fc96 forbid get_address_size call on HVM guests, because that
> didn't make sense. It broke core dump functionality on HVM because
> libxc unconditionally asked for guest width.
...
> +if ( !auto_translated_physmap &&
> + xc_
On Wed, Mar 20, 2019 at 12:52:28PM +, Paul Durrant wrote:
> Currently the comment at line #267 claims that the value should be
> expressed in number logical sectors, whereas the comment at line #613
> states that the value should be expressed strictly in units of 512 bytes.
>
> Signed-off-by:
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 20 March 2019 13:53
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [PATCH] public/io/blkif.h: make the comments on "sectors"
> self-consistent
>
> On Wed, Mar 20, 2019 at 12
> -Original Message-
> From: Paul Durrant
> Sent: 20 March 2019 13:59
> To: 'Konrad Rzeszutek Wilk'
> Cc: xen-devel@lists.xenproject.org
> Subject: RE: [PATCH] public/io/blkif.h: make the comments on "sectors"
> self-consistent
>
> > -Original Message-
> > From: Konrad Rzeszutek
flight 83757 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/83757/
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
...and properly enable it when synthesizing a drive.
The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants
to enable discard on a specified image. The code in
xen_block_driver_create() correctly parses this and uses it to set
'discard' to 'unamp' for the file_layer, but fails to
On Wed, Mar 20, 2019 at 02:05:15PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Paul Durrant
> > Sent: 20 March 2019 13:59
> > To: 'Konrad Rzeszutek Wilk'
> > Cc: xen-devel@lists.xenproject.org
> > Subject: RE: [PATCH] public/io/blkif.h: make the comments on "sectors"
> > s
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Konrad Rzeszutek Wilk
> Sent: 20 March 2019 14:28
> To: Paul Durrant
> Cc: 'xen-devel@lists.xenproject.org'
> Subject: Re: [Xen-devel] [PATCH] public/io/blkif.h: make the comments on
>
Hello Julien,
Julien Grall writes:
> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
>> From: Volodymyr Babchuk
>>
>> This enumeration controls TEE type for a domain. Currently there is
>> two possible options: either 'none' or 'native'.
>>
>> 'none' is the default value and it basically disables
Hi Julien,
Julien Grall writes:
>> if ( shm_rpc->guest_page )
>> put_page(shm_rpc->guest_page);
>> +
>
> Spurious change.
Good catch. Thank you.
>
>> +/*
>> + * TODO: With current implementation, OP-TEE will not issue
>> + * RPC to free this buffer. Gues
On Wed, Mar 20, 2019 at 01:49:30PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxc: fix HVM core dump"):
> > f969bc9fc96 forbid get_address_size call on HVM guests, because that
> > didn't make sense. It broke core dump functionality on HVM because
> > libxc unconditionally asked for gue
f969bc9fc96 forbid get_address_size call on HVM guests, because that
didn't make sense. It broke core dump functionality on HVM because
libxc unconditionally asked for guest width.
Force guest_width to a sensible value.
Reported-by: Igor Druzhinin
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc:
On 20/03/2019 15:27, Volodymyr Babchuk wrote:
Hello Julien,
Julien Grall writes:
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This enumeration controls TEE type for a domain. Currently there is
two possible options: either 'none' or 'native'.
'none' is the defau
Hi Julien,
Julien Grall writes:
[...]
>> struct dt_device_node *node;
>> @@ -48,12 +82,25 @@ static bool optee_probe(void)
>>(uint32_t)resp.a3 != OPTEE_MSG_UID_3 )
>> return false;
>> +/* Read number of threads */
>> +arm_smccc_smc(OPTEE_SMC_GET_CONFIG, OPTE
Hi Achin,
On 18/03/2019 21:04, Achin Gupta wrote:
On Mon, Mar 18, 2019 at 03:49:12PM +, Julien Grall wrote:
(+ Achin)
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This enumeration controls TEE type for a domain. Currently there is
two possible options: either 'n
Julien Grall writes:
Hi Julien,
> Hi Volodymyr,
>
> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
>> From: Volodymyr Babchuk
>>
>> OP-TEE usually uses the same idea with command buffers (see
>> previous commit) to issue RPC requests. Problem is that initially
>> it has no buffer, where it can w
The mail thread at [1] clarifies that the Xen blkif protocol requires that
sector based quantities should be interpreted strictly as multiples of
512 bytes. This patch modifies the xen-block code accordingly.
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01600.html
Signed-of
On 20/03/2019 15:36, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
if ( shm_rpc->guest_page )
put_page(shm_rpc->guest_page);
+
Spurious change.
Good catch. Thank you.
+/*
+ * TODO: With current implementation, OP-TEE will
Julien Grall writes:
> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
>> From: Volodymyr Babchuk
>
> Some of the patches are using your EPAM e-mail addresss. Other are
> using your gmail address. Could you confirm this is expected?
No, I'll make sure that all patches are authored by
>>
>> Sha
Wei Liu writes ("[PATCH v2] libxc: fix HVM core dump"):
> f969bc9fc96 forbid get_address_size call on HVM guests, because that
> didn't make sense. It broke core dump functionality on HVM because
> libxc unconditionally asked for guest width.
>
> Force guest_width to a sensible value.
>
> Reporte
Andrew Cooper writes ("Re: [PATCH 0/3] docs: User oriented documentation"):
> It turns out that I mis-interpreted the compatibility note in
> https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html# and
> stretch is probably fine.
OK, good.
Well, I think we could say that to build this docum
Julien Grall writes:
[...]
+/*
+ * TODO: With current implementation, OP-TEE will not issue
+ * RPC to free this buffer. Guest and OP-TEE will be out of
+ * sync: guest believes that it provided buffer to OP-TEE,
+ * while OP-TEE t
On 20/03/2019 16:14, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
[...]
struct dt_device_node *node;
@@ -48,12 +82,25 @@ static bool optee_probe(void)
(uint32_t)resp.a3 != OPTEE_MSG_UID_3 )
return false;
+/* Read number of th
On 3/20/19 12:02 PM, Wei Liu wrote:
> On Wed, Mar 20, 2019 at 11:35:10AM +, Andrew Cooper wrote:
>> On 20/03/2019 11:28, Wei Liu wrote:
>>> On Wed, Mar 20, 2019 at 11:23:57AM +, Andrew Cooper wrote:
On 20/03/2019 11:20, Wei Liu wrote:
> On Tue, Mar 19, 2019 at 04:20:04PM +, And
Hi,
On 20/03/2019 16:21, Volodymyr Babchuk wrote:
Julien Grall writes:
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where
On Wed, Mar 20, 2019 at 04:40:59PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v2] libxc: fix HVM core dump"):
> > f969bc9fc96 forbid get_address_size call on HVM guests, because that
> > didn't make sense. It broke core dump functionality on HVM because
> > libxc unconditionally asked for
On 20/03/2019 16:43, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 0/3] docs: User oriented documentation"):
>> It turns out that I mis-interpreted the compatibility note in
>> https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html# and
>> stretch is probably fine.
> OK, good.
>
> We
Julien Grall writes:
> On 20/03/2019 15:27, Volodymyr Babchuk wrote:
>>
>> Hello Julien,
>>
>> Julien Grall writes:
>>
>>> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This enumeration controls TEE type for a domain. Currently there is
two possible op
On 20/03/2019 16:49, George Dunlap wrote:
> On 3/20/19 12:02 PM, Wei Liu wrote:
>> On Wed, Mar 20, 2019 at 11:35:10AM +, Andrew Cooper wrote:
>>> On 20/03/2019 11:28, Wei Liu wrote:
On Wed, Mar 20, 2019 at 11:23:57AM +, Andrew Cooper wrote:
> On 20/03/2019 11:20, Wei Liu wrote:
>>>
Julien Grall writes:
> Hi,
>
> On 20/03/2019 16:21, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC request
On Fri, Mar 15, 2019 at 12:28 PM Andrew Cooper
wrote:
>
> On 15/03/2019 09:17, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jason Andryuk [mailto:jandr...@gmail.com]
> >> Sent: 14 March 2019 18:16
> >> To: Paul Durrant
> >> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.o
Julien Grall writes:
> On 20/03/2019 16:14, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
> Hi Volodymyr,
>
>> Julien Grall writes:
>>
>> [...]
struct dt_device_node *node;
@@ -48,12 +82,25 @@ static bool optee_probe(void)
(uint32_t)resp.a3 != OPTEE_MSG_UID_3 )
>>>
Hi,
On 20/03/2019 16:39, Volodymyr Babchuk wrote:
Julien Grall writes:
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
Some of the patches are using your EPAM e-mail addresss. Other are
using your gmail address. Could you confirm this is expected?
No, I'll make sur
Hi Volodymyr,
On 20/03/2019 17:42, Volodymyr Babchuk wrote:
[...]
+static void put_std_call(struct optee_domain *ctx, struct optee_std_call *call)
+{
+spin_lock(&ctx->lock);
+ASSERT(call->in_flight);
+unmap_xen_arg(call);
Same question for the unmap.
Yeah, in normal circumstance
Anthony PERARD writes:
> On Tue, Mar 19, 2019 at 07:34:45PM +0100, Markus Armbruster wrote:
>> = hw/xenpv/xen_machine_pv.c =
>> Stefano Stabellini (supporter:X86)
>> Anthony Perard (supporter:X86)
>> Paul Durrant (supporter:X86)
>> xen-devel@lists.xenproject.org (open list:
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/pci/proc.c: In function ‘proc_bus_pci_ioctl’:
drivers/pci/proc.c:216:6: warning: this statement may fall through
[-Wimplicit-fallthrough=]
Hi,
On 20/03/2019 17:01, Volodymyr Babchuk wrote:
Julien Grall writes:
On 20/03/2019 15:27, Volodymyr Babchuk wrote:
Hello Julien,
Julien Grall writes:
On 07/03/2019 21:04, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This enumeration controls TEE type for a domain. Currently ther
On Wed, Mar 20, 2019 at 01:27:15PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
Does this fix all the remaining cases in drivers/pci? I'd like to fix
them all at once.
What's the best way to wat
On 20/03/2019 18:27, Gustavo A. R. Silva wrote:
> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
> index 6fa1627ce08d..445b51db75b0 100644
> --- a/drivers/pci/proc.c
> +++ b/drivers/pci/proc.c
> @@ -222,6 +222,7 @@ static long proc_bus_pci_ioctl(struct file *file,
> unsigned int cmd,
>
On 3/20/19 2:24 PM, Bjorn Helgaas wrote:
> On Wed, Mar 20, 2019 at 01:27:15PM -0500, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>
> Does this fix all the remaining cases in drivers/pci? I'd like t
Julien Grall writes:
>>> Some of the patches are using your EPAM e-mail addresss. Other are
>>> using your gmail address. Could you confirm this is expected?
>>
>> No, I'll make sure that all patches are authored by
>>
>
> And your signed-off-by as well :).
Sure :)
>
> [...]
>
>>> I can't promi
On 3/20/19 2:27 PM, Andrew Cooper wrote:
> On 20/03/2019 18:27, Gustavo A. R. Silva wrote:
>> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
>> index 6fa1627ce08d..445b51db75b0 100644
>> --- a/drivers/pci/proc.c
>> +++ b/drivers/pci/proc.c
>> @@ -222,6 +222,7 @@ static long proc_bus_pci_ioc
flight 133918 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133918/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-xl
flight 133948 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133948/
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 1
Hi all,
Friendly ping:
Who can take this?
Thanks
--
Gustavo
On 2/28/19 5:51 AM, Oleksandr Andrushchenko wrote:
> +Xen-devel list
>
> On 2/27/19 10:53 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through
On Wed, Mar 20, 2019 at 01:27:15PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/pci/proc.c: In function ‘proc_bus_pci_ioctl’:
> drivers/pc
Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call
before calling acpi_parse_dmar()") PCI segment 0 is now known early
which made the sanity check on DRHD definition structure to work.
This, in turn, caused a regression on some machines (in particular,
HP PowerEdge R740 with I/O AT
On 3/20/19 3:13 PM, Bjorn Helgaas wrote:
> On Wed, Mar 20, 2019 at 01:27:15PM -0500, Gustavo A. R. Silva wrote:
[..]
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. S
flight 133924 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133924/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133783
test-amd64-amd64-xl-qemut-win7-amd64 17
flight 133920 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133920/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133896
test-amd64-amd64-xl-qemuu-win7-amd64
branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: qemuu git://xenbits.
flight 133923 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133923/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt 13 migrat
On Tue, Mar 19, 2019 at 02:16:44PM +, Anthony PERARD wrote:
> On Mon, Mar 18, 2019 at 10:43:12PM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Mar 18, 2019 at 06:37:31PM +0100, Roger Pau Monne wrote:
> > > Or if it's not possible to honor the hinted address an error is returned
> > > ins
flight 133926 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133926/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
Tests which
flight 133930 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt18 guest-start/debian.repeat fail REGR. vs. 133846
Tests which did not suc
This run is configured for baseline tests only.
flight 83760 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/83760/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
flight 133938 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133938/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fbdfef35cb82b3e0beed2ceb0243ef129d2e55ce
baseline version:
ovmf 7681a891cec6655e66d71
80 matches
Mail list logo
