[Xen-devel] [xen-4.7-testing test] 101076: tolerable FAIL - PUSHED

flight 101076 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101076/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-xsm 9 debian-install fail in 101050 pass in 101076 test-armhf-armhf-xl-credit2

Re: [Xen-devel] [for-4.8][PATCH v2 17/23] xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry

On Thu, 15 Sep 2016, Julien Grall wrote: > The ARM architecture mandates to use of a break-before-make sequence > when changing translation entries if the page table is shared between > multiple CPUs whenever a valid entry is replaced by another valid entry > (see D4.7.1 in ARM DDI 0487A.j for

[Xen-devel] [v2 3/3] tools & docs: add L2 CAT support in tools and docs.

This patch is the xl/xc changes to support Intel L2 CAT (Cache Allocation Technology). The new level option is introduced to original CAT setting command in order to set CBM for specified level CAT. - 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT info. - 'xl psr-cat-cbm-set' is

[Xen-devel] [v2 1/3] x86: refactor psr implementation in hypervisor.

Current psr.c is designed for supporting L3 CAT/CDP. It has many limitations to add new feature. Considering to support more PSR features, we need refactor PSR implementation to make it more flexible and fulfill the principle, open for extension but closed for modification. The core of the

[Xen-devel] [v2 2/3] x86: add support for L2 CAT in hypervisor.

Add L2 CAT (Cache Allocation Technology) feature support in hypervisor: - Implement 'struct feat_ops' callback functions for L2 CAT and initialize L2 CAT feature and add it into feature list. - Add new sysctl to get L2 CAT information. - Add new domctl to set/get L2 CAT CBM. Signed-off-by: He

[Xen-devel] [v2 0/3] Enable L2 Cache Allocation Technology

Design document is below: === % Intel L2 Cache Allocation Technology (L2 CAT) Feature % Revision 2.0 \clearpage Hi all, We plan to bring a new PSR (Platform Shared Resource) feature called Intel L2 Cache Allocation Technology

Re: [Xen-devel] [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

Hi, 河合英宏 Thanks for the patch log update, it looks good to me. Acked-by: Dave Young On 09/20/16 at 11:22am, 河合英宏 / KAWAI，HIDEHIRO wrote: > Here is the revised commit description reflecting Dave's > comment. Cc list was copied from -mm version. > > From: Hidehiro Kawai

[Xen-devel] [xen-4.6-testing test] 101074: tolerable FAIL - PUSHED

flight 101074 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101074/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail in 101049 pass in 101074

[Xen-devel] [ovmf baseline-only test] 67741: all pass

This run is configured for baseline tests only. flight 67741 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67741/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7419aedd93132f2dfc91e7bf3634fba7e0842c7b baseline

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Wed, 21 Sep 2016, Julien Grall wrote: > > > > And in my suggestion, we allow a richer set of labels, so that the user > > > > could also be more specific -- e.g., asking for "A15" specifically, for > > > > example, and failing to build if there are no A15 cores present, while > > > > allowing

[Xen-devel] Fwd: Openindiana, using -machine pc,accel=xen in qemu

Pls cc me with any replies. I didn't get any responses in xen-users, so I'm posting here. My use case is as below, but the jist of it is is the qemu option -machine pc,accel=xen meant to be usable in standalone qemu, or is it only available from a guest launched by xl, or libvirtd via libxl?

[Xen-devel] [xen-unstable-smoke test] 101083: tolerable all pass - PUSHED

flight 101083 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101083/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

On 09/21/2016 06:52 AM, Jan Beulich wrote: On 20.09.16 at 02:19, wrote: >> --- a/.gitignore >> +++ b/.gitignore >> @@ -127,13 +127,13 @@ tools/firmware/*bios/*bios*.txt >> tools/firmware/etherboot/gpxe/* >> tools/firmware/extboot/extboot.img >>

[Xen-devel] [libvirt test] 101072: tolerable FAIL - PUSHED

flight 101072 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/101072/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14

[Xen-devel] [xen-4.5-testing test] 101070: regressions - FAIL

flight 101070 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101070/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 101045

[Xen-devel] [xen-unstable test] 101069: tolerable FAIL - PUSHED

flight 101069 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101069/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101040

[Xen-devel] [ovmf test] 101071: all pass - PUSHED

flight 101071 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/101071/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7419aedd93132f2dfc91e7bf3634fba7e0842c7b baseline version: ovmf

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

Hi Dario, On 21/09/2016 16:45, Dario Faggioli wrote: On Wed, 2016-09-21 at 14:06 +0100, Julien Grall wrote: (CC a couple of ARM folks) Yay, thanks for this! :-) I had few discussions and more thought about big.LITTLE support in Xen. The main goal of big.LITTLE is power efficiency by

[Xen-devel] [xen-unstable-smoke test] 101082: tolerable all pass - PUSHED

flight 101082 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101082/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On 21/09/2016 20:11, Julien Grall wrote: Hi Stefano, On 21/09/2016 19:13, Stefano Stabellini wrote: On Wed, 21 Sep 2016, Julien Grall wrote: (CC a couple of ARM folks) On 21/09/16 11:22, George Dunlap wrote: On 21/09/16 11:09, Julien Grall wrote: On 20/09/16 21:17, Stefano Stabellini

[Xen-devel] [PATCH v1 3/3] xen-livepatch: If hypervisor is not compiled with Livepatching

. print a better error code. Reported-by: Andrew Cooper Signed-off-by: Konrad Rzeszutek Wilk --- tools/misc/xen-livepatch.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/misc/xen-livepatch.c

[Xen-devel] [PATCH v1 2/3] xen-livepatch: Print the header _after_ the first livepatch hypercall

That way we can print out the header if we are sure the hypervisor has been compiled with Xen Livepatching. Signed-off-by: Konrad Rzeszutek Wilk --- tools/misc/xen-livepatch.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Xen-devel] [PATCH v1 1/3] xen-livepatch: Remove the 'test' part

As it has evolved a bit and is more of a test tool. Reported-by: Bhavesh Davda Signed-off-by: Konrad Rzeszutek Wilk --- tools/misc/xen-livepatch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/misc/xen-livepatch.c

[Xen-devel] [PATCH v1] xen-livepatch fixes for Xen 4.8

Hey! Three tiny fixes that came about from various reports from folks. tools/misc/xen-livepatch.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) Konrad Rzeszutek Wilk (3): xen-livepatch: Remove the 'test' part xen-livepatch: Print the header _after_ the

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

Hi Stefano, On 21/09/2016 19:13, Stefano Stabellini wrote: On Wed, 21 Sep 2016, Julien Grall wrote: (CC a couple of ARM folks) On 21/09/16 11:22, George Dunlap wrote: On 21/09/16 11:09, Julien Grall wrote: On 20/09/16 21:17, Stefano Stabellini wrote: On Tue, 20 Sep 2016, Julien Grall

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

On Wed, Sep 21, 2016 at 9:30 AM, Tamas K Lengyel wrote: > On Wed, Sep 21, 2016 at 9:23 AM, Jan Beulich wrote: > On 21.09.16 at 17:16, wrote: >>> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel >>>

Re: [Xen-devel] [for-4.8][PATCH] xen/arm64: Add missing synchronization barrier in invalidate_cache

On Wed, 21 Sep 2016, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 21, 2016 at 03:52:12PM +0100, Julien Grall wrote: > > The invalidation of the instructions cache requires barriers to ensure > > the completion of the invalidation before continuing (see B2.3.4 in ARM > > DDI 0487A.j). > > > > This

Re: [Xen-devel] [PATCH] misc/arm: Correctly name bit in the booting document

On Wed, 21 Sep 2016, Julien Grall wrote: > SCTLR_EL3.HCR does not exists in the documentation (see D7.2.80 in ARM > DDI 0487A.j). It was meant to be SCTRL_EL3.HCE. > > Signed-off-by: Julien Grall Acked-by: Stefano Stabellini >

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

On 21/09/16 19:06, Wei Liu wrote: On Wed, Sep 21, 2016 at 02:00:50PM -0400, Boris Ostrovsky wrote: On 09/21/2016 01:36 PM, Wei Liu wrote: On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote: On 09/21/2016 12:13 PM, Ian Jackson wrote: Platform Team regression test user writes

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Wed, 21 Sep 2016, Julien Grall wrote: > (CC a couple of ARM folks) > > On 21/09/16 11:22, George Dunlap wrote: > > On 21/09/16 11:09, Julien Grall wrote: > > > > > > > > > On 20/09/16 21:17, Stefano Stabellini wrote: > > > > On Tue, 20 Sep 2016, Julien Grall wrote: > > > > > Hi Stefano, > >

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

On Wed, Sep 21, 2016 at 02:00:50PM -0400, Boris Ostrovsky wrote: > On 09/21/2016 01:36 PM, Wei Liu wrote: > > On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote: > >> On 09/21/2016 12:13 PM, Ian Jackson wrote: > >>> Platform Team regression test user writes ("[xen-4.5-testing > >>>

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

On 09/21/2016 01:36 PM, Wei Liu wrote: > On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote: >> On 09/21/2016 12:13 PM, Ian Jackson wrote: >>> Platform Team regression test user writes ("[xen-4.5-testing baseline-only >>> test] 67737: regressions - FAIL"): test-xtf-amd64-amd64-1

Re: [Xen-devel] [PATCH] xen: switch to threaded irq in netback

I think you'd better resubmit this patch to netdev@ because netfront/back patches will go via David Miller's tree. And perhaps uses the subject line: xen-netback: switch to threaded irq for control ring On Tue, Sep 20, 2016 at 04:21:37PM +0200, Juergen Gross wrote: > Instead of open coding it

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote: > On 09/21/2016 12:13 PM, Ian Jackson wrote: > > Platform Team regression test user writes ("[xen-4.5-testing baseline-only > > test] 67737: regressions - FAIL"): > >> test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail

[Xen-devel] [PATCH v5 10/16] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH

To use as a common way of testing alternative patching for livepatches. Both architectures have this FEATURE and the test-cases can piggyback on that. Suggested-by: Julien Grall Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Julien Grall

[Xen-devel] [PATCH v5 05/16] livepatch: Initial ARM64 support.

As compared to x86 the va of the hypervisor .text is locked down - we cannot modify the running pagetables to have the .ro flag unset. We borrow the same idea that alternative patching has - which is to vmap the entire .text region and use the alternative virtual address for patching. Since we

[Xen-devel] [PATCH v5 13/16] bug/x86/arm: Align bug_frames sections.

Most of the WARN_ON or BUG_ON sections are properly aligned on x86. However on ARM and on x86 assembler the macros don't include any alignment information - hence they end up being the default byte granularity. On ARM32 it is paramount that the alignment is word-size (4) otherwise if one tries to

[Xen-devel] [PATCH v5 03/16] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in.

If the payload had the sections mentioned but the hypervisor did not support some of them (say on ARM the .ex_table) - instead of ignoring them - it should forbid loading of such payload. Reviewed-by: Julien Grall Signed-off-by: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH v5 04/16] arm: poison initmem when it is freed.

The current byte sequence is '0xcc' which makes sense on x86, but on ARM it is: stclgt 12, cr12, [ip], {204} ; 0xcc Picking something more ARM applicable such as: efefefefsvc 0x00efefef Creates a nice crash if one executes that code: (XEN) CPU1: Unexpected Trap:

[Xen-devel] [PATCH v5 06/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr

If the distance is too big we are in trouble - as our relocation distance can surely be clipped, or still have a valid width - but cause an overflow of distance. On various architectures the maximum displacement for a unconditional branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while

[Xen-devel] [PATCH v5 16/16] livepatch: arm[32, 64], x86: NOP test-case

The test-case is quite simple - we NOP the 'xen_minor_version'. The amount of NOPs depends on the architecture. On x86 the function is 11 bytes long: 55 push %rbp <- NOP 48 89 e5mov%rsp,%rbp <- NOP b8 04 00 00 00 mov$0x4,%eax

[Xen-devel] [PATCH v5 02/16] arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]

x86 implements all of them by default - and we just add two extra HAS_ variables to be declared in autoconf.h. ARM 64 only has alternative while ARM 32 has none of them. And while at it change the livepatch common code that would benefit from this. Acked-by: Jan Beulich

[Xen-devel] [PATCH v5 15/16] livepatch, arm[32|64]: Share arch_livepatch_revert

It is exactly the same in both platforms. No functional change. Acked-by: Julien Grall Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Julien Grall Cc: Stefano Stabellini v3: New submission. v4:

[Xen-devel] [PATCH v5 08/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

Certain platforms, such as ARM [32|64] add extra mapping symbols such as $x (for ARM64 instructions), or more interesting to this patch: $t (for Thumb instructions). These symbols are suppose to help the final linker to make any adjustments (such as add an veneer). But more importantly - we do not

[Xen-devel] [PATCH v5 09/16] livepatch: Move test-cases to their own sub-directory in test.

So they can be shared with ARM64 (but not yet, so they are only built on x86). No functional change. We also need to tweak the MAINTAINERS and .gitignore file. Also we need to update SUBDIRS to include the new 'test' directory so 'cscope' can show the example livepatches. Acked-by: Jan Beulich

[Xen-devel] [PATCH v5 01/16] arm64: s/ALTERNATIVE/HAS_ALTERNATIVE/

No functional change. We resist the temptation to move the entries in the Kconfig file to be more in alphabetical order as the "arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]" will move one of the entries to common file. Suggested-by: Jan Beulich Signed-off-by: Konrad

[Xen-devel] [PATCH v5] Livepatch for ARM 64 and 32.

Hey! Since v4:[https://lists.xen.org/archives/html/xen-devel/2016-09/msg01734.html] - Added Acks/Reviewed-by - Reworked "arm: poison initmem when it is freed." and "xen/arm32: Add an helper to invalidate all instruction caches" - Moved "livepatch: x86, ARM, alternative: Expose

[Xen-devel] [PATCH v5 07/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

Those symbols are used to help final linkers to replace insn. The ARM ELF specification mandates that they are present to denote the start of certain CPU features. There are two variants of it - short and long format. Either way - we can ignore these symbols. Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH v5 14/16] livepatch: Initial ARM32 support.

The patch piggybacks on: livepatch: Initial ARM64 support, which brings up all of the necessary livepatch infrastructure pieces in. This patch adds three major pieces: 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which means the adddendum had to be extracted from within the

[Xen-devel] [PATCH v5 11/16] livepatch: tests: Make them compile under ARM64

We need to two things: 1) Wrap the platform-specific objcopy parameters in defines The input and output parameters for $(OBJCOPY) are different based on the platforms. As such provide them in the OBJCOPY_MAGIC define and use that. 2) The alternative is a bit different (exists only under

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

On 21/09/16 17:13, Ian Jackson wrote: Platform Team regression test user writes ("[xen-4.5-testing baseline-only test] 67737: regressions - FAIL"): test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706 test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR.

Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

On Wed, Sep 21, 2016 at 02:39:58AM -0600, Jan Beulich wrote: > >>> On 21.09.16 at 00:35, wrote: > > On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote: > >> > >> Paul, there's been no reply to > >>

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich wrote: > Again this looks like much clutter with little benefit to me, i.e. I'd > then rather go with the unmodified original proposal. That's largely > because nothing really enforces anyone to use the (disconnected) >

[Xen-devel] [PATCH v7 3/5] livepatch: NOP if func->new_addr is zero.

The NOP functionality will NOP any of the code at the 'old_addr' or at 'name' if the 'new_addr' is zero. The purpose of this is to NOP out calls, such as: e8 <4-bytes-offset> (5 byte insn), or on ARM a 4 byte insn for branching. We need the EIP of where we need to the NOP, and that can be

[Xen-devel] [PATCH v7 5/5] livepach: Add .livepatch.hooks functions and test-case

From: Ross Lagerwall Add hook functions which run during patch apply and patch revert. Hook functions are used by livepatch payloads to manipulate data structures during patching, etc. One use case is the XSA91. As Martin mentions it: "If we have shadow variables, we

[Xen-devel] [PATCH v7 1/5] livepatch: Disallow applying after an revert

On general this is unhealthy - as the payload's .bss (definitly) or .data (maybe) will be modified once the payload is running. Doing an revert and then re-applying the payload with a non-pristine .bss or .data can lead to unforseen consequences (.bss are assumed to always contain zero value but

[Xen-devel] [PATCH v7 4/5] livepatch: Drop _jmp from arch_livepatch_[apply, revert]_jmp

With "livepatch: NOP if func->new_addr is zero." that name makes no more sense as we also NOP now. Suggested-by: Jan Beulich Signed-off-by: Konrad Rzeszutek Wilk --- v7: New submission. --- xen/arch/arm/livepatch.c| 4 ++--

[Xen-devel] [PATCH v7] Livepatch fixes and general features for Xen 4.8.

Hey! Since v6: [https://lists.xen.org/archives/html/xen-devel/2016-09/msg01719.html] - Remade "livepatch: Disallow applying after an revert" to look at sh_size. - Added some Reviewed-by/Acks. - Added changes as requested. - Included a new patch: "livepatch: Drop _jmp from

[Xen-devel] [PATCH v7 2/5] livepatch: Add limit of 2MB to payload .bss sections.

The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793 "xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the size of the binary at 2MB. We follow that in capping the size of the .BSSes to be at maximum 2MB. We also bubble up the payload limit and this one in one #define called

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

On 09/21/2016 12:13 PM, Ian Jackson wrote: > Platform Team regression test user writes ("[xen-4.5-testing baseline-only > test] 67737: regressions - FAIL"): >> test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706 >> test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

On 09/21/2016 12:02 PM, Jan Beulich wrote: On 21.09.16 at 17:34, wrote: >> On 09/21/2016 11:16 AM, Jan Beulich wrote: >> On 21.09.16 at 17:09, wrote: On 09/21/2016 07:33 AM, Jan Beulich wrote: On 20.09.16 at 02:19,

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

On Wed, Sep 21, 2016 at 10:04:21AM -0600, Jan Beulich wrote: > >>> On 21.09.16 at 17:59, wrote: > > The fix can be done two ways: > > a) See if xen.efi.map exists and then copy it > > b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked > >

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

Ian Jackson writes ("Problem with Xen 4.5 failing XTF tests on old AMD cpus ?"): > Sadly we haven't yet managed to make the logs from this instance > public. I have copied the logs from this one test job to here: http://xenbits.xen.org/people/iwj/2016/67737/test-xtf-amd64-amd64-1/info.html

[Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

Platform Team regression test user writes ("[xen-4.5-testing baseline-only test] 67737: regressions - FAIL"): > test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706 > test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 67706 Several of these, 32bit and

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

>>> On 21.09.16 at 17:59, wrote: > The fix can be done two ways: > a) See if xen.efi.map exists and then copy it > b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked > against xen). > > The patch chooses the latter. Well, if the ARM

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

>>> On 21.09.16 at 17:34, wrote: > On 09/21/2016 11:16 AM, Jan Beulich wrote: > On 21.09.16 at 17:09, wrote: >>> On 09/21/2016 07:33 AM, Jan Beulich wrote: >>> On 20.09.16 at 02:19, wrote: > ---

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

On Tue, Sep 20, 2016 at 08:22:01AM -0600, Jan Beulich wrote: > >>> On 08.09.16 at 18:21, wrote: > > On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote: > >> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and > >> typo-ed the source file name of

[Xen-devel] [xen-unstable-smoke test] 101080: tolerable all pass - PUSHED

flight 101080 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101080/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Wed, 2016-09-21 at 14:06 +0100, Julien Grall wrote: > (CC a couple of ARM folks) > Yay, thanks for this! :-) > I had few discussions and  more thought about big.LITTLE support in > Xen.  > The main goal of big.LITTLE is power efficiency by moving task > around  > and been able to idle one

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

On 09/21/2016 11:16 AM, Jan Beulich wrote: On 21.09.16 at 17:09, wrote: >> On 09/21/2016 07:33 AM, Jan Beulich wrote: >> On 20.09.16 at 02:19, wrote: --- a/tools/libacpi/build.c +++ b/tools/libacpi/build.c @@ -20,6

Re: [Xen-devel] [for-4.8][PATCH] xen/arm64: Add missing synchronization barrier in invalidate_cache

On Wed, Sep 21, 2016 at 03:52:12PM +0100, Julien Grall wrote: > The invalidation of the instructions cache requires barriers to ensure > the completion of the invalidation before continuing (see B2.3.4 in ARM > DDI 0487A.j). > > This was overlooked in commit fb9d877 "xen/arm64: Add an helper to >

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

On Wed, Sep 21, 2016 at 9:23 AM, Jan Beulich wrote: On 21.09.16 at 17:16, wrote: >> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel >> wrote: >>> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

Boris Ostrovsky writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly"): > On 09/21/2016 11:05 AM, Ian Jackson wrote: > > Wait, the libxl makefiles are going to end up running iasl ? > > Not directly. There is a new target in libxl's Makefile: > > acpi: > $(MAKE)

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

>>> On 21.09.16 at 17:16, wrote: > On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel > wrote: >> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote: >> On 21.09.16 at 16:18, wrote: On

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

On 09/21/2016 11:05 AM, Ian Jackson wrote: > Boris Ostrovsky writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI > object files directly"): >> 2. ".tmp__" vs ".tmp": Because the temporary files are generated not in >> tools/libacpi but in the directory of the libacpi user (such as libxl) >>

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

>>> On 21.09.16 at 17:09, wrote: > On 09/21/2016 07:33 AM, Jan Beulich wrote: > On 20.09.16 at 02:19, wrote: >>> --- a/tools/libacpi/build.c >>> +++ b/tools/libacpi/build.c >>> @@ -20,6 +20,7 @@ >>> #include "ssdt_s4.h" >>> #include

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel wrote: > On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote: > On 21.09.16 at 16:18, wrote: >>> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote:

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote: On 21.09.16 at 16:18, wrote: >> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote: >> On 20.09.16 at 19:29, wrote: I'm trying to

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

On 09/21/2016 07:33 AM, Jan Beulich wrote: On 20.09.16 at 02:19, wrote: >> Signed-off-by: Boris Ostrovsky > libacpi parts > Acked-by: Jan Beulich > albeit ... > > >> --- a/tools/libacpi/build.c >> +++

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Wed, 2016-09-21 at 20:28 +0800, Peng Fan wrote: > Use this in xl cfg file? > vcpuclass=["0-1:A35","2-5:A53", "6-7:A72"] ? > > I am not sure. If there are more kinds of CPUs, how to handle guest > vcpus, > as we discussed in this thread, we tend to support different classes > of vcpu > for

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

Boris Ostrovsky writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly"): > 2. ".tmp__" vs ".tmp": Because the temporary files are generated not in > tools/libacpi but in the directory of the libacpi user (such as libxl) > it is possible that a Makefile there might use

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]"): > On 21.09.16 at 15:24, wrote: > > Would this be enough of an improvement, for you, to be worth the > > additional type name clutter etc. ? > > Again

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Wed, 2016-09-21 at 10:22 +0100, George Dunlap wrote: > On 21/09/16 09:38, Peng Fan wrote: > > User may change the hard affinity of a vcpu, so we also need to > > block a little > > vcpu be scheduled to a big physical cpu. Add some checking code in > > xen, > > when chaning the hard affnity,

[Xen-devel] [xen-unstable baseline-only test] 67736: regressions - FAIL

This run is configured for baseline tests only. flight 67736 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67736/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 9

[Xen-devel] [for-4.8][PATCH] xen/arm64: Add missing synchronization barrier in invalidate_cache

The invalidation of the instructions cache requires barriers to ensure the completion of the invalidation before continuing (see B2.3.4 in ARM DDI 0487A.j). This was overlooked in commit fb9d877 "xen/arm64: Add an helper to invalidate all instruction caches". Signed-off-by: Julien Grall

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

>>> On 21.09.16 at 16:18, wrote: > On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote: > On 20.09.16 at 19:29, wrote: >>> I'm trying to figure out the design decision regarding the handling of >>> guest MOV-TO-CR3

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

On Wed, Sep 21, 2016 at 10:23:09AM -0400, Chris Patterson wrote: > On Wed, Sep 21, 2016 at 10:07 AM, Konrad Rzeszutek Wilk > wrote: > > On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote: > >> On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

On Wed, Sep 21, 2016 at 10:07 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote: >> On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu wrote: >> > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

On Wed, Sep 21, 2016 at 3:03 AM, Jan Beulich wrote: On 20.09.16 at 17:54, wrote: >> On Tue, Sep 20, 2016 at 9:39 AM, Jan Beulich wrote: >> On 20.09.16 at 17:14, wrote: On Tue, Sep 20,

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

Hi guys I have found the problem (after hours and hours of gruesome debugging with the almighty print) and it seems that this could potentially have quite a bit of impact if altp2m is enabled for a guest domain (even if the functionality is never actively used), since destroying any vcpu of this

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote: On 20.09.16 at 19:29, wrote: >> I'm trying to figure out the design decision regarding the handling of >> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for >> VPID has been

[Xen-devel] [xen-4.5-testing baseline-only test] 67737: regressions - FAIL

This run is configured for baseline tests only. flight 67737 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67737/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-119

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote: > On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu wrote: > > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote: > >> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote: > >> > From:

[Xen-devel] [qemu-mainline test] 101062: regressions - FAIL

flight 101062 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 101017 Regressions

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

>>> On 21.09.16 at 15:24, wrote: > Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, > re qemu depriv) [and 1 more messages]"): >> On 21.09.16 at 14:23, wrote: >> > But changes in the contents of the specific

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu wrote: > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote: >> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote: >> > From: Chris Patterson >> > >> > xs_watch() creates a

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

>>> On 21.09.16 at 15:34, wrote: > On 09/21/2016 06:39 AM, Jan Beulich wrote: > On 20.09.16 at 02:19, wrote: >>> --- a/tools/firmware/hvmloader/acpi/dsdt.asl >>> +++ /dev/null >> Please try to represent this as a move, not as a

Re: [Xen-devel] [PATCH V2] x86/mm: Fix Coverity issues 1373105 and 1373106

>>> On 21.09.16 at 14:55, wrote: > On 21/09/16 13:52, Jan Beulich wrote: > On 21.09.16 at 14:41, wrote: >>> Added missing error checks in p2m_set_mem_access_multi(). >> >> I think the patch subject should say what is being changed/fixed,

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

On 09/21/2016 07:40 AM, Jan Beulich wrote: On 21.09.16 at 13:38, wrote: >> Jan Beulich writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI object >> files directly"): >>> On 21.09.16 at 13:29, wrote: I think `.dummy' would be a

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

On 09/21/2016 06:39 AM, Jan Beulich wrote: On 20.09.16 at 02:19, wrote: >> --- a/tools/firmware/hvmloader/acpi/dsdt.asl >> +++ /dev/null > Please try to represent this as a move, not as a delete+create. This was done by 'git mv' and patches were generated with

  1   2   >