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(
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. 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
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.
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
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 ++
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
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
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
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
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 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 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 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 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
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 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
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 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,
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 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 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 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 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 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 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
>
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:
> --- 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
> -
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 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
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 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
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
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 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
> >>>
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 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 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
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 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
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 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 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
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
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
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
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
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
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-
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 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
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 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
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 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 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
59 matches
Mail list logo
