flight 140746 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140746/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 76040af020521b535a066e8df91e224b14ce284f
baseline version:
freebsd 4438d71949e
flight 140735 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which are faili
flight 140738 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 140598
Tests which did not suc
flight 140732 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 139936
Tests wh
Hi Stefano,
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On Wed, 28 Aug 2019, Peng Fan wrote:
> > Hi Robin,
> >
> > > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> > >
> > > On 09/07/2019 09:22, Peng Fan wrote:
> > > > arm64 shares some code under arch/arm/x
flight 140730 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139876
test-amd64-i386-xl
flight 140776 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140776/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 140729 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140729/
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. 133580
test-amd64-i386-xl-
On Wed, Aug 28, 2019 at 3:11 PM Andrew Cooper wrote:
>
> On 28/08/2019 18:35, Tamas K Lengyel wrote:
> > On Wed, Aug 28, 2019 at 11:16 AM Andrew Cooper
> > wrote:
> >> On 28/08/2019 18:07, Tamas K Lengyel wrote:
> >>> On Wed, Aug 28, 2019 at 10:55 AM Andrew Cooper
> >>> wrote:
> On 28/08/20
On 28/08/2019 18:35, Tamas K Lengyel wrote:
> On Wed, Aug 28, 2019 at 11:16 AM Andrew Cooper
> wrote:
>> On 28/08/2019 18:07, Tamas K Lengyel wrote:
>>> On Wed, Aug 28, 2019 at 10:55 AM Andrew Cooper
>>> wrote:
On 28/08/2019 17:25, Tamas K Lengyel wrote:
> On Wed, Aug 28, 2019 at 9:54 AM
Performing soft reset should not opportunistically kill IOREQ servers
for device emulators that might be currently running for a domain.
Every emulator is supposed to clean up IOREQ servers for itself on exit.
This allows a toolstack to elect whether or not a particular device
model should be resta
flight 140773 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140773/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Hi all,
I'm working on ARM64 Xen testing with Xilinx, and I have a few
quick questions to ask.
How is success vs failure determined with testing using Gitlab CI?
It looks like everything goes into a log, but is there parsing
done afterwards to make the output easier to go through?
If I have a co
On 27/08/2019 15:36, Jan Beulich wrote:
> On 14.08.2019 12:44, Andrew Cooper wrote:
>> Introduce a new ENDDATA() helper which sets type and size together.
>
> Except this isn't very natural: Setting the size late is quite
> common, to avoid the need for an "end" label. But the type would
> better b
On 27.08.19 16:28, Jan Beulich wrote:
Hi Jan
On 20.08.2019 20:09, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/xmalloc.h
+++ b/xen/include/xen/xmalloc.h
@@ -35,6 +35,18 @@
#define xzalloc_array(_type, _num) \
((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num))
+/
On Wed, 28 Aug 2019, Peng Fan wrote:
> Hi Robin,
>
> > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> >
> > On 09/07/2019 09:22, Peng Fan wrote:
> > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > However ZONE_DMA is removed by commit
> > > ad67f5a6545("arm64: r
On Wed, Aug 28, 2019 at 11:16 AM Andrew Cooper
wrote:
>
> On 28/08/2019 18:07, Tamas K Lengyel wrote:
> > On Wed, Aug 28, 2019 at 10:55 AM Andrew Cooper
> > wrote:
> >> On 28/08/2019 17:25, Tamas K Lengyel wrote:
> >>> On Wed, Aug 28, 2019 at 9:54 AM Jan Beulich wrote:
> On 28.08.2019 17:51
flight 140766 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 140727
Tests which
On 28/08/2019 18:07, Tamas K Lengyel wrote:
> On Wed, Aug 28, 2019 at 10:55 AM Andrew Cooper
> wrote:
>> On 28/08/2019 17:25, Tamas K Lengyel wrote:
>>> On Wed, Aug 28, 2019 at 9:54 AM Jan Beulich wrote:
On 28.08.2019 17:51, Tamas K Lengyel wrote:
> On Wed, Aug 28, 2019 at 9:35 AM Jan Be
On Wed, Aug 28, 2019 at 10:55 AM Andrew Cooper
wrote:
>
> On 28/08/2019 17:25, Tamas K Lengyel wrote:
> > On Wed, Aug 28, 2019 at 9:54 AM Jan Beulich wrote:
> >> On 28.08.2019 17:51, Tamas K Lengyel wrote:
> >>> On Wed, Aug 28, 2019 at 9:35 AM Jan Beulich wrote:
> On 28.08.2019 17:28, Tamas
On 28/08/2019 17:25, Tamas K Lengyel wrote:
> On Wed, Aug 28, 2019 at 9:54 AM Jan Beulich wrote:
>> On 28.08.2019 17:51, Tamas K Lengyel wrote:
>>> On Wed, Aug 28, 2019 at 9:35 AM Jan Beulich wrote:
On 28.08.2019 17:28, Tamas K Lengyel wrote:
> Hi all,
> I'm trying to track down how
On Wed, Aug 28, 2019 at 9:54 AM Jan Beulich wrote:
>
> On 28.08.2019 17:51, Tamas K Lengyel wrote:
> > On Wed, Aug 28, 2019 at 9:35 AM Jan Beulich wrote:
> >>
> >> On 28.08.2019 17:28, Tamas K Lengyel wrote:
> >>> Hi all,
> >>> I'm trying to track down how a call in common/grant_table.c to
> >>>
flight 140725 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140725/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail
REGR. vs. 140559
version targe
On 28.08.2019 17:51, Tamas K Lengyel wrote:
> On Wed, Aug 28, 2019 at 9:35 AM Jan Beulich wrote:
>>
>> On 28.08.2019 17:28, Tamas K Lengyel wrote:
>>> Hi all,
>>> I'm trying to track down how a call in common/grant_table.c to
>>> share_xen_page_with_guest will actually populate that page into the
On Wed, Aug 28, 2019 at 9:35 AM Jan Beulich wrote:
>
> On 28.08.2019 17:28, Tamas K Lengyel wrote:
> > Hi all,
> > I'm trying to track down how a call in common/grant_table.c to
> > share_xen_page_with_guest will actually populate that page into the
> > guest's physmap. Immediately after the call
flight 140721 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 140235
Tests wh
On 28.08.2019 17:28, Tamas K Lengyel wrote:
> Hi all,
> I'm trying to track down how a call in common/grant_table.c to
> share_xen_page_with_guest will actually populate that page into the
> guest's physmap. Immediately after the call the page doesn't seem to
> be present in the physmap, as share_x
Hi all,
I'm trying to track down how a call in common/grant_table.c to
share_xen_page_with_guest will actually populate that page into the
guest's physmap. Immediately after the call the page doesn't seem to
be present in the physmap, as share_xen_page_with_guest will just add
the page to the domai
On 19.08.2019 03:25, Chao Gao wrote:
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -594,10 +594,6 @@ static int cpu_request_microcode(const void *buf, size_t
> bufsize)
> xfree(mc_amd);
>
>out:
> -#if CONFIG_HVM
> -svm_host_osvw_init();
> -#endif
> -
If MCFG area is not reserved in E820 Xen by default will defer its usage
until Dom0 registers it explicitly after ACPI parser recognizes it as
a reserved resource in DSDT. Having it reserved in E820 is not
mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
and firmware is fre
On 19.08.2019 03:25, Chao Gao wrote:
> +/* Return true if cache gets updated. Otherwise, return false */
> +bool microcode_update_cache(struct microcode_patch *patch)
> +{
> +
> +ASSERT(spin_is_locked(µcode_mutex));
Stray blank line ahead of this one.
> --- a/xen/arch/x86/microcode_intel.c
>
On 19.08.2019 03:25, Chao Gao wrote:
> to a more generic function. So that it can be used alone to check
> an update against the CPU signature and current update revision.
>
> Note that enum microcode_match_result will be used in common code
> (aka microcode.c), it has been placed in the common he
On Wed, Aug 28, 2019 at 02:55:58PM +, Alexandru Stefan ISAILA wrote:
>
>
> On 28.08.2019 16:32, Roger Pau Monne wrote:
> > This partially reverts commit
> > 854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that
> > propagates changes to the domain physmap done by p2m_pt_set_ent
On 28.08.2019 16:32, Roger Pau Monne wrote:
> This partially reverts commit
> 854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that
> propagates changes to the domain physmap done by p2m_pt_set_entry into
> the iommu page tables. Without this logic changes to the guest physmap
> ar
On 27/08/2019 16:39, Jan Beulich wrote:
> On 13.08.2019 12:53, Andrew Cooper wrote:
>> This functionality is obsolete. It was introduced by c/s 39407bed9c0
>> into
>> Xend, but never exposed in libxl.
>
> This is good enough a reason I think (hope), while ...
>
>> While not explicitly limited to P
On 28/08/2019 15:16, Andrew Cooper wrote:
> On 08/08/2019 21:59, Sander Eikelenboom wrote:
>> Hi Andrew,
>>
>> It seems the pvshim patches in xen-unstable staging break the build on my
>> machine.
>> I cloned a fresh tree to be sure, haven't checked which of the two commits
>> causes it:
>> 060f4
On 28/08/2019 15:10, Jan Beulich wrote:
> On 12.08.2019 20:21, Andrew Cooper wrote:
>> load_TR() is used exclusively in the resume path, but jumps through a lot of
>> unnecessary hoops.
>>
>> As suspend/resume is strictly on CPU0 in idle context, the correct GDT to use
>> is boot_gdt, which means i
On 12.08.2019 20:21, Andrew Cooper wrote:
> load_TR() is used exclusively in the resume path, but jumps through a lot of
> unnecessary hoops.
>
> As suspend/resume is strictly on CPU0 in idle context, the correct GDT to use
> is boot_gdt, which means it doesn't need saving on suspend. Similarly,
flight 140717 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail in 140670 REGR. vs.
139910
Tests which are
On 28.08.2019 15:32, Roger Pau Monne wrote:
> This partially reverts commit
> 854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that
> propagates changes to the domain physmap done by p2m_pt_set_entry into
> the iommu page tables. Without this logic changes to the guest physmap
> are
This partially reverts commit
854a49a7486a02edae5b3e53617bace526e9c1b1 by re-adding the logic that
propagates changes to the domain physmap done by p2m_pt_set_entry into
the iommu page tables. Without this logic changes to the guest physmap
are not propagated to the iommu, leaving stale iommu entri
On Tue, Aug 27, 2019 at 08:46:24AM +, Pawel Wieczorkiewicz wrote:
> Extend the XC python bindings library to support also all common
> livepatch operations and actions.
>
> Add the python bindings for the following operations:
> - status (pyxc_livepatch_status):
> Requires a payload name as
On 08/08/2019 21:59, Sander Eikelenboom wrote:
> Hi Andrew,
>
> It seems the pvshim patches in xen-unstable staging break the build on my
> machine.
> I cloned a fresh tree to be sure, haven't checked which of the two commits
> causes it:
> 060f4eee0fb408b316548775ab921e16b7acd0e0 or
> 32b1d6288
On 28.08.2019 13:51, Andrew Cooper wrote:
On 28/08/2019 07:26, Jan Beulich wrote:
On 27.08.2019 18:04, Andrew Cooper wrote:
On 01/07/2019 12:58, Jan Beulich wrote:
@@ -9896,6 +9902,32 @@ x86_emulate(
: "0" ((uint32_t)src.val), "rm"
(_regs.edx) );
bre
On 28/08/2019 07:26, Jan Beulich wrote:
> On 27.08.2019 18:04, Andrew Cooper wrote:
>> On 01/07/2019 12:58, Jan Beulich wrote:
>>> @@ -9896,6 +9902,32 @@ x86_emulate(
>>> : "0" ((uint32_t)src.val), "rm"
>>> (_regs.edx) );
>>> break;
>>> + case X86EMUL
On 27/08/2019 17:45, Andrew Cooper wrote:
> AMD explicitly doesn't have leaf 4. Their leaf 0x801d is similar in
> behaviour (by having subleafs), and is mostly compatible, but
> irritatingly doesn't have an identical data layout.
>
> I've got another query out with AMD because the documentatio
On 28/08/2019 08:14, Jan Beulich wrote:
> On 27.08.2019 19:27, Andrew Cooper wrote:
>> On 27/08/2019 16:53, Jan Beulich wrote:
>>> On 27.08.2019 17:31, Andrew Cooper wrote:
On 01/07/2019 12:57, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_e
flight 140708 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
test-amd64-i386-qemu
flight 140744 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140744/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 10279e35609ba590b86308a83400b3161f5c7157
baseline version:
xen 7ef6
On 27/08/2019 05:52, Chao Gao wrote:
> On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>> On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>>> On 19/08/2019 02:25, Chao Gao wrote:
register an nmi callback. And this callback does busy-loop on threads
which are waiti
Another debugtrace enhancement I needed for core scheduling debugging,
plus some cleanup.
Changes in V3:
- rebase to current staging
Changes in V2:
- added new patch 1 (preparing the move of debugtrace coding)
- patch 4 (v1 patch 3): avoid leaking buffer
Juergen Gross (4):
xen: use common outp
Instead of living in drivers/char/console.c move the debugtrace
related coding to a new file common/debugtrace.c
No functional change, code movement only.
Signed-off-by: Juergen Gross
---
xen/common/Makefile| 1 +
xen/common/debugtrace.c| 181 ++
debugtrace is normally writing trace entries into a single trace
buffer. There are cases where this is not optimal, e.g. when hunting
a bug which requires writing lots of trace entries and one cpu is
stuck. This will result in other cpus filling the trace buffer and
finally overwriting the interest
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer.
While at it switch debugtrace_send_to_console and debugtrace_used to
bool and delete an empty line.
Signed-off-by: Juergen Gr
Today dumping the debugtrace buffers is done via sercon_puts(), while
direct printing of trace entries (after toggling output to the console)
is using serial_puts().
Use sercon_puts() in both cases, as the difference between both is not
really making sense.
In order to prepare moving debugtrace f
On 27.08.19 20:18, Julien Grall wrote:
A more complete patch (fix another place) has already been sent on the
mailing list (see [1]). It is waiting on Stefano's ack at the moment...
Cheers,
[1]
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01439.html
Ah, yes. Missed it.
On 27. Aug 2019, at 18:58, Konrad Rzeszutek Wilk
mailto:konrad.w...@oracle.com>> wrote:
On August 27, 2019 4:46:17 AM EDT, Pawel Wieczorkiewicz
mailto:wipa...@amazon.de>> wrote:
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_paylo
flight 140691 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140691/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 140282
Tests which are f
On 27.08.2019 19:27, Andrew Cooper wrote:
On 27/08/2019 16:53, Jan Beulich wrote:
On 27.08.2019 17:31, Andrew Cooper wrote:
On 01/07/2019 12:57, Jan Beulich wrote:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -9124,6 +9126,48 @@ x86_emulate(
59 matches
Mail list logo
