Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 08:50:11AM +0200, Luis R. Rodriguez wrote: > On Fri, Aug 12, 2016 at 07:23:03AM +0200, Borislav Petkov wrote: > > On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote: > > > OK I've added CONFIG_BUILD_AVOID_BITROT. > > > > What does that do? > > > Enabling it

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

flight 100427 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100427/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 753cf34e29c52bb45d25eb0580e04145f19cd83d baseline version: ovmf 926059304e8377fc37bb8

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

flight 100424 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100424/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 100408 build-i386-rumpuserxen

Re: [Xen-devel] [Very RFC PATCH] Livepatch - initial ARM64/32 support.

Hi On 11/08/2016 21:05, Stefano Stabellini wrote: On Thu, 11 Aug 2016, Julien Grall wrote: On 09/08/2016 06:18, Konrad Rzeszutek Wilk wrote: Hey! Hi Konrad, Over the last couple of months in my spare time I was playing with making livepatch work with ARM64 (using the FoundationModel simula

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

On 11/08/2016 16:41, Tamas K Lengyel wrote: On Aug 11, 2016 02:18, "Julien Grall" mailto:julien.gr...@arm.com>> wrote: Hello Tamas, On 10/08/2016 16:49, Tamas K Lengyel wrote: On Aug 10, 2016 03:52, "Julien Grall"

Re: [Xen-devel] [PATCH] xen: handle inbound migration of VMs without ioreq server pages

> -Original Message- > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > Sent: 11 August 2016 21:07 > To: Paul Durrant > Cc: Anthony Perard; xen-de...@lists.xenproject.org; qemu- > de...@nongnu.org; Stefano Stabellini > Subject: RE: [PATCH] xen: handle inbound migration of VMs with

[Xen-devel] dependences for backporting to 4.5 [was: Re: [PATCH 2/3] xen: Have schedulers revise initial placement]

On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote: > > > > On 01.08.16 at 14:32, wrote: > > Yes, I think they're good backporting candidates. > Well, they appear to work fine on 4.7, but putting them onto 4.5 > causes an early boot crash (BUG_ON( cpu != svc->vcpu->processor ) > in __runq_insert

Re: [Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file

On 11/08/2016 19:59, "Stefano Stabellini" wrote: >On Thu, 11 Aug 2016, Lars Kurth wrote: >> On 11/08/2016 01:51, "Stefano Stabellini" >>wrote: >> >> >> +Developer's Certificate of Origin >> >> +- >> >> + >> >> +All patches to the Xen Project code base must incl

Re: [Xen-devel] [PATCH] xen: credit1: fix a race when picking initial pCPU for a vCPU

On 12/08/16 05:07, Dario Faggioli wrote: > In the Credit1 hunk of 9f358ddd69463 ("xen: Have > schedulers revise initial placement") csched_cpu_pick() > is called without taking the runqueue lock of the > (temporary) pCPU that the vCPU has been assigned to > (e.g., in XEN_DOMCTL_max_vcpus). > > How

Re: [Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file

On 11/08/2016 19:57, "Stefano Stabellini" wrote: >On Thu, 11 Aug 2016, George Dunlap wrote: >> On 11/08/16 01:51, Stefano Stabellini wrote: >> > On Wed, 10 Aug 2016, Lars Kurth wrote: >> >> >> diff --git a/CONTRIBUTING b/CONTRIBUTING >> >> new file mode 100644 >> >> index 000..7af13c4 >> >>

[Xen-devel] [qemu-mainline baseline-only test] 66966: tolerable FAIL

This run is configured for baseline tests only. flight 66966 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66966/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output

On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote: > Andrew Cooper writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for > getting output"): > > On 11/08/16 18:51, Wei Liu wrote: > > > I'm pretty out of idea here. > > > > Because of XTF's behaviour (waiting for xenconsoled to ca

[Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

COPYING file: The motivation of this change is to make it easier for new contributors to conduct a license and patent review, WITHOUT changing any licenses. - Remove references to BSD-style licenses as we have more common license exceptions and replace with "other license stanzas" - List the mo

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

On 09/08/16 12:30, Jan Beulich wrote: On 09.08.16 at 12:48, wrote: >> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >> depriv)"): >>> Actually, having thought about this some more, and taking this >>> together with the expectations to the privcmd driver previously

Re: [Xen-devel] [PATCH] xen: credit1: fix a race when picking initial pCPU for a vCPU

On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote: > On 12/08/16 05:07, Dario Faggioli wrote: > >  > > Reported-by: Andrew Cooper > > Signed-off-by: Dario Faggioli > It might be nice if we could add an ASSERT() that the appropriate > runqueue was locked, to make sure we don't get caught out

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output

Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"): > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote: > > We don't care when xenconsoled closes the logfile. We care about when > > it last calls write() (with a nonempty buffer). > > In logfile mode

Re: [Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only

On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote: > >>> On 11.08.16 at 11:17, wrote: > > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long > > mbi_p) > > if ( !opt_smep ) > > setup_clear_cpu_cap(X86_FEATURE_SMEP); > > if ( cpu_has_smep ) > > +

[Xen-devel] [PATCH 2/2] x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL

The undefined behaviour sanitiser shows that it really is NULL via the pre_initcall path. (XEN) (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66 (XEN) member access within null pointer of type 'struct proce

[Xen-devel] [PATCH 1/2] x86/boot: Align e820 and video data in the boot trampoline

The undefined behaviour sanitiser in Clang 3.8 identifies that these are all misaigned when used in __start_xen(). Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/boot/mem.S | 1 + xen/arch/x86/boot/video.S | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/arch/x86/b

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

On 11/08/16 19:10, Andrew Cooper wrote: > On 09/08/16 11:40, Jan Beulich wrote: >> --- a/xen/arch/x86/cpu/mtrr/main.c >> +++ b/xen/arch/x86/cpu/mtrr/main.c >> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) { >> pri

Re: [Xen-devel] [PATCH 5/7] x86emul: don't special case fetching unsigned 8-bit immediates

>>> On 11.08.16 at 19:38, wrote: > On 11/08/16 17:44, Jan Beulich wrote: > On 11.08.16 at 18:32, wrote: >>> On 11/08/16 13:06, Jan Beulich wrote: @@ -2893,7 +2894,6 @@ x86_emulate( goto swint; case 0xcd: /* int imm8 */ -src.val = insn_fetch_typ

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

>>> On 11.08.16 at 20:10, wrote: > On 09/08/16 11:40, Jan Beulich wrote: >> --- a/xen/arch/x86/cpu/mtrr/main.c >> +++ b/xen/arch/x86/cpu/mtrr/main.c >> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) { >> printk(KE

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

>>> On 12.08.16 at 12:34, wrote: > On 11/08/16 19:10, Andrew Cooper wrote: >> On 09/08/16 11:40, Jan Beulich wrote: >>> --- a/xen/arch/x86/cpu/mtrr/main.c >>> +++ b/xen/arch/x86/cpu/mtrr/main.c >>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >>> if ((type == MTRR_TYPE_WRCOMB)

Re: [Xen-devel] 答复: xen does not support the 8G large bar

>>> On 12.08.16 at 05:18, wrote: > Hi Jan, > Thanks for your reply. > Qemu-xen seems that has problem for support 8G large Bar. > I think this patch is not perfect: > https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commitdiff;h=aabc8530c7ba2b > e89e21463f051056ad7c255e6e > Because I found upper

Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case

Hello Tamas, On 10/08/2016 17:00, Tamas K Lengyel wrote: diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index ef614be..97948fd 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [

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

flight 100433 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100433/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 82df618711c596d3b6164e790572c795b7ea4dcc baseline version: ovmf 753cf34e29c52bb45d25e

Re: [Xen-devel] [PATCH 5/7] x86emul: don't special case fetching unsigned 8-bit immediates

On 12/08/16 11:50, Jan Beulich wrote: On 11.08.16 at 19:38, wrote: >> On 11/08/16 17:44, Jan Beulich wrote: >> On 11.08.16 at 18:32, wrote: On 11/08/16 13:06, Jan Beulich wrote: > @@ -2893,7 +2894,6 @@ x86_emulate( > goto swint; > > case 0xcd: /* int

Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning

On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote: > Support ballooning Mini-OS automatically up in case of memory shortage. > > Do some cleanups, a small correction and add some basic features to > lay groundwork for support of ballooning in Mini-OS (patches 1-14). > > The main visib

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

On 12/08/16 11:58, Jan Beulich wrote: On 11.08.16 at 20:10, wrote: >> On 09/08/16 11:40, Jan Beulich wrote: >>> --- a/xen/arch/x86/cpu/mtrr/main.c >>> +++ b/xen/arch/x86/cpu/mtrr/main.c >>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un >>> if ((type == MTRR_TYPE_WRCOMB) &&

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

>>> On 12.08.16 at 11:44, wrote: > On 09/08/16 12:30, Jan Beulich wrote: > On 09.08.16 at 12:48, wrote: >>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu >>> depriv)"): Actually, having thought about this some more, and taking this together with the expec

Re: [Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only

>>> On 12.08.16 at 12:03, wrote: > On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote: >> >>> On 11.08.16 at 11:17, wrote: >> > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long > mbi_p) >> > if ( !opt_smep ) >> > setup_clear_cpu_cap(X86_FEATURE_SMEP);

Re: [Xen-devel] [PATCH 1/2] x86/boot: Align e820 and video data in the boot trampoline

>>> On 12.08.16 at 12:35, wrote: > The undefined behaviour sanitiser in Clang 3.8 identifies that these are all > misaigned when used in __start_xen(). > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@list

Re: [Xen-devel] [PATCH 2/2] x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL

>>> On 12.08.16 at 12:35, wrote: > The undefined behaviour sanitiser shows that it really is NULL via the > pre_initcall path. > > (XEN) > > (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66 > (XEN) member

[Xen-devel] Unable to add disk on ARM64

Hi, I am using xen master branch on i.MX8 ARM64. My xl configuration: kernel = "/root/xen/Image" memory = "128" name = "DomU" vcpus = 1 serial="pty" disk = [ 'phy:/dev/loop0,xvda,w' ] extra = "console=hvc0 root=/dev/xvda debug=/bin/sh" And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

>>> On 12.08.16 at 01:13, wrote: > +### Lazy Consensus {#lazyconsensus} > + > +Lazy Consensus is a useful technique to make decisions for specific > proposals > +which are not covered by the Review Then Commit Policy or do not require a > more > +formal decison (see below). Lazy Consensus is e

Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning

On Fri, Aug 12, 2016 at 12:42:31PM +0100, Wei Liu wrote: > On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote: > > Support ballooning Mini-OS automatically up in case of memory shortage. > > > > Do some cleanups, a small correction and add some basic features to > > lay groundwork for s

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

On 12/08/2016 13:41, "Jan Beulich" wrote: On 12.08.16 at 01:13, wrote: >> +### Lazy Consensus {#lazyconsensus} >> + >> +Lazy Consensus is a useful technique to make decisions for specific >>proposals >> +which are not covered by the Review Then Commit Policy or do not >>require a more >

Re: [Xen-devel] Unable to add disk on ARM64

On 12/08/2016 14:24, Peng Fan wrote: Hi, Hello Peng, I have CCed Roger who is more familiar than me with the hotplug scripts. I am using xen master branch on i.MX8 ARM64. My xl configuration: kernel = "/root/xen/Image" memory = "128" name = "DomU" vcpus = 1 serial="pty" disk = [ 'phy:/dev/

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

>>> On 12.08.16 at 14:53, wrote: > On 12/08/2016 13:41, "Jan Beulich" wrote: > On 12.08.16 at 01:13, wrote: >>> +### Lazy Consensus {#lazyconsensus} >>> + >>> +Lazy Consensus is a useful technique to make decisions for specific >>>proposals >>> +which are not covered by the Review Then Comm

Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning

Wei Liu, on Fri 12 Aug 2016 13:48:09 +0100, wrote: > ---8<--- > From d72510368cdc3c73af3c8918a404a8137f40bd9c Mon Sep 17 00:00:00 2001 > From: Wei Liu > Date: Fri, 12 Aug 2016 11:32:57 +0100 > Subject: [PATCH] x86/arch_mm.h: move p2m_chk_pfn to x86/mm.c > > Making that function inlined won't buy

[Xen-devel] [PATCH] xl cpupool-numa-split: don't try to bring any dom0 vCPUs online

Since commit a9dd01431a799b6743193a75f4f1ce2fdfdb7296, main_cpupoolnumasplit wants to ensure that dom0 doesn't have more online vCPUs than the number of pCPUs in a NUMA node. However, if dom0 already has fewer online vCPUs than the number of pCPUs in a NUMA node, this will cause some to be made on

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output

On Fri, Aug 12, 2016 at 10:51:37AM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting > output"): > > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote: > > > We don't care when xenconsoled closes the logfile. We care about when > >

[Xen-devel] [distros-debian-wheezy test] 66969: all pass

flight 66969 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66969/ Perfect :-) All tests in this flight passed as required baseline version: flight 66914 jobs: build-amd64 pass build-armh

Re: [Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)

On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote: > On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote: > > Hey Ross, > > > > I am running in a symbol dependency issue that I am not exactly > > sure how to solve. > > > > I have an payload that introduces a new function (xen_foobar)

[Xen-devel] dependences for backporting to 4.6 [was: Re: [PATCH 2/3] xen: Have schedulers revise initial placement]

>>> On 12.08.16 at 03:59, wrote: > On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote: >> I'd really like to have those backported, but I have to ask one >> of you to identify which prereq-s are needed on 4.6 and 4.5 >> (I'll revert them from 4.5 right away, but I'll wait for an osstest >> fligh

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

I'll try to test this, but I have one comment inline... On 08/11/2016 10:17 PM, Dave Young wrote: On 08/10/16 at 05:09pm, Hidehiro Kawai wrote: Daniel Walker reported problems which happens when crash_kexec_post_notifiers kernel option is enabled (https://lkml.org/lkml/2015/6/24/44). In that c

[Xen-devel] [xen-unstable test] 100431: regressions - FAIL

flight 100431 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100431/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-buildfail REGR. vs. 100424 Tests which are fa

[Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON

BUILD_BUG_ON should not appear in a public-facing header, otherwise it risks clashing with macro with the same name in other code bases. I encountered such issue when trying to add BUILD_BUG_ON to a private header in Xen's gnttab library. Ideally BUILD_BUG_ON should be moved to a private header, b

Re: [Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON

Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote: > BUILD_BUG_ON should not appear in a public-facing header, otherwise it > risks clashing with macro with the same name in other code bases. I > encountered such issue when trying to add BUILD_BUG_ON to a private > header in Xen's gnttab library. >

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

flight 100452 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100452/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 62b8b5be713dd1f801cd44e4eb28f68585a9bd85 baseline version: ovmf 82df618711c596d3b6164

[Xen-devel] [PATCH 0/2] build-id adjustments

1: build-id: fix minor quirks 2: x86/EFI: use less crude way of generating the build ID Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/2] eliminate some section start symbols

Section start symbols frequently obscure the actual symbol name living at the start of the section. Eliminate them where they can be replaced by linker resolved .startof.* symbols. (Section end symbols may have the same undesirable effect, but they're less easy to eliminate, as they'd need to be re

[Xen-devel] [PATCH 1/2] build-id: fix minor quirks

The initial size check in xen_build_id_check() came too late (after the first access to the structure), but was mostly redundant with checks done in all callers; convert it to a properly placed ASSERT(). The "mostly" part being addressed too: xen_build_init() was off by one. And then there was a s

[Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

Besides being more logical this also allows verifying correct recording of alignments in .o files. The cpu0_stack related ASSERT() in xen.lds.S is now of questionable value (as it now verifies correct tool chain behavior), but I've left it in nevertheless. Signed-off-by: Jan Beulich --- a/xen/a

[Xen-devel] [PATCH 2/2] make use of .startof.() and .sizeof.() assembler expressions

Section start symbols frequently obscure the actual symbol name living at the start of the section. Eliminate them where they can be replaced by linker resolved .startof.* symbols. (Section end symbols may have the same undesirable effect, but they're less easy to eliminate, as they'd need to be re

[Xen-devel] [PATCH 2/2] x86/EFI: use less crude way of generating the build ID

Recent enough binutils support --build-id also for COFF/PE output, and hence we should use that in favor of the original hack when possible. This gets complicated by the linker requiring at least one COFF object file to attach the .buildid section to. Hence the patch introduces a buildid.ihex (in

Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case

On Aug 12, 2016 05:24, "Julien Grall" wrote: > > Hello Tamas, > > > On 10/08/2016 17:00, Tamas K Lengyel wrote: >> >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl >> index ef614be..97948fd 100644 >> --- a/tools/libxl/libxl_types.idl >> +++ b/tools/libxl/libxl_types.idl >>

Re: [Xen-devel] Unable to add disk on ARM64

On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote: > On 12/08/2016 14:24, Peng Fan wrote: > > Hi, > > Hello Peng, > > I have CCed Roger who is more familiar than me with the hotplug scripts. > > > I am using xen master branch on i.MX8 ARM64. > > > > My xl configuration: > > > > kern

[Xen-devel] [PATCH v2 0/2] x86emul: remaining misc small adjustments

1: fold SrcImmByte fetching 2: introduce SrcImm16 Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [Very RFC PATCH 3/3] livepatch: Initial ARM32/64 support.

Hi Konrad, On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote: The initial support for ARM64 - and livepatching works: As it is a very RFC I only gave a quick look. I have few comments on it (see below). (XEN) livepatch: xen_hello_world: Applying 1 functions (XEN) hi_func: Hi! (called 1 tim

Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

On 12/08/16 15:47, Jan Beulich wrote: > Besides being more logical this also allows verifying correct recording > of alignments in .o files. > > The cpu0_stack related ASSERT() in xen.lds.S is now of questionable > value (as it now verifies correct tool chain behavior), but I've left > it in nevert

Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case

On Fri, Aug 12, 2016 at 08:51:14AM -0600, Tamas K Lengyel wrote: > On Aug 12, 2016 05:24, "Julien Grall" wrote: > > > > Hello Tamas, > > > > > > On 10/08/2016 17:00, Tamas K Lengyel wrote: > >> > >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > >> index ef614be..97948fd

[Xen-devel] [PATCH v2 1/2] x86emul: fold SrcImmByte fetching

There's no need for having identical code spelled out twice. Signed-off-by: Jan Beulich --- v2: Add braces (with quite a bit of reluctance). --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1979,9 +1979,14 @@ x86_emulate( goto done;

[Xen-devel] [PATCH v2 2/2] x86emul: introduce SrcImm16

... and use it for RET, LRET, and ENTER processing to limit the amount of "manual" insn bytes fetching. Note that for the RET and LRET paths the change utilizes that SrcImplicit (aka SrcNone) table entries leave src.val as zero. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- a/xen/ar

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

flight 100457 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100457/ 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 1

[Xen-devel] [xen-unstable baseline-only test] 66968: tolerable FAIL

This run is configured for baseline tests only. flight 66968 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66968/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-build

Re: [Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON

On Fri, Aug 12, 2016 at 04:02:11PM +0200, Samuel Thibault wrote: > Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote: > > BUILD_BUG_ON should not appear in a public-facing header, otherwise it > > risks clashing with macro with the same name in other code bases. I > > encountered such issue when tr

Re: [Xen-devel] [PATCH] xen: credit1: fix a race when picking initial pCPU for a vCPU

On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote: > On 12/08/16 05:07, Dario Faggioli wrote: > Let me know if you want me to check this in as-is or if you think you > might send a follow-up patch adding an ASSERT. > Done, and it actually explodes like this: (XEN) [4.870128] Xen call tr

Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

>>> On 12.08.16 at 17:02, wrote: > On 12/08/16 15:47, Jan Beulich wrote: >> Besides being more logical this also allows verifying correct recording >> of alignments in .o files. >> >> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable >> value (as it now verifies correct tool chai

Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

On 12/08/16 16:21, Jan Beulich wrote: On 12.08.16 at 17:02, wrote: >> On 12/08/16 15:47, Jan Beulich wrote: >>> Besides being more logical this also allows verifying correct recording >>> of alignments in .o files. >>> >>> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable >>

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 09:25:07AM +0200, Borislav Petkov wrote: > On Fri, Aug 12, 2016 at 08:50:11AM +0200, Luis R. Rodriguez wrote: > > On Fri, Aug 12, 2016 at 07:23:03AM +0200, Borislav Petkov wrote: > > > On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote: > > > > OK I've added C

Re: [Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)

On Fri, Aug 12, 2016 at 09:51:39AM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote: > > On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote: > > > Hey Ross, > > > > > > I am running in a symbol dependency issue that I am not exactly > > > sure h

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote: > Even so, you don't link the compiled extra code so the only penalty > here is when compiling, nothing more. And if you are compiling typically > the cost here is just a few seconds. Yeah, so let's make it clear that this is simil

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 05:51:21PM +0200, Borislav Petkov wrote: > On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote: > > Even so, you don't link the compiled extra code so the only penalty > > here is when compiling, nothing more. And if you are compiling typically > > the cost her

[Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999

L.S., I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV guests and dom0 are uneffected). The clock is always set to 31/12/1999 on boot of the guest, instead of the system clock time. Bisecting seems to point out commit: 463a86304cae92e10277b47180ac59cf93982e5b char/ge

[Xen-devel] [PATCH 1/4] Add information on sources for vmac.* and rijndael.*

I added these, as I came across the sources during a license scan. Signed-off-by: Lars Kurth --- xen/crypto/README.source | 17 + xen/include/crypto/README.source | 17 + 2 files changed, 34 insertions(+) create mode 100644 xen/crypto/README.source creat

[Xen-devel] [PATCH 0/4] Clarify License information : m4, stubdom, tools/blktap2, xen/crypto

This series contains some of the easier license clean-up cases, which can be fixed by adding COPYING files or README.source files. The series specially contains: xen/crypto and xen/include/crypto Added a README.source file Does not need a COPYING file: all files are imported m4 Updated README.s

[Xen-devel] [PATCH 2/4] Added source of ax_compare_version.m4 to import log

In addition: - fixed a reference, which was incorrect Signed-off-by: Lars Kurth --- m4/README.source | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/m4/README.source b/m4/README.source index 21850a6..be7bc5a 100644 --- a/m4/README.source +++ b/m4/README.source @@ -3,6

[Xen-devel] [PATCH 4/4] blktap2: Added COPYING file

Blktap2 has some complexity, as some files do not have (c) headers and the directory did not have a COPYING file. At this stage, we have not verified the intention of (c) holders. We may do this in future, if the need arises. Signed-off-by: Lars Kurth --- tools/blktap2/COPYING | 72 +

[Xen-devel] [PATCH 3/4] [STUBDOM] Added COPYING files and README.source files

Added a COPYING file as a boilerplate to explain license oddities in this directory Added a vtpm/COPYING file which contains MIT licensed files only Added a vtpmmgr/README.source file which contains many BSD-3-Clause files that originally came from tools/vtpm_manager Signed-off-by: Lars Kurth -

Re: [Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999

Hi, On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote : > L.S., > > I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV > guests and dom0 are uneffected). The clock is always set to 31/12/1999 on > boot > of the guest, instead of the system clock time. > > Bis

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: > Alright, how's this new description: > > diff --git a/init/Kconfig b/init/Kconfig > index cac3f096050d..73e4890c24c4 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -53,6 +53,34 @@ config CROSS_COMPILE > need to set

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

flight 100468 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100468/ 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 1

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

Just some minor typos in descriptions I noticed below... On Fri, Aug 12, 2016 at 10:35 AM, Borislav Petkov wrote: > On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: >> Alright, how's this new description: >> >> diff --git a/init/Kconfig b/init/Kconfig >> index cac3f096050d..73e4

Re: [Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999

Friday, August 12, 2016, 7:29:37 PM, you wrote: > Hi, > On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote : >> L.S., >> >> I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV >> guests and dom0 are uneffected). The clock is always set to 31/12/1999 on >> boot

[Xen-devel] [qemu-mainline test] 100454: tolerable FAIL - PUSHED

flight 100454 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100454/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 100421 test-amd64-i386-xl-qemuu-w

[Xen-devel] [linux-3.14 baseline-only test] 66970: tolerable FAIL

This run is configured for baseline tests only. flight 66970 linux-3.14 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66970/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopf

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: > Alright, how's this new description: > > diff --git a/init/Kconfig b/init/Kconfig > index cac3f096050d..73e4890c24c4 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -53,6 +53,34 @@ config CROSS_COMPILE > need to set

Re: [Xen-devel] [PATCH 1/2] build-id: fix minor quirks

On Fri, Aug 12, 2016 at 08:45:02AM -0600, Jan Beulich wrote: > The initial size check in xen_build_id_check() came too late (after the > first access to the structure), but was mostly redundant with checks > done in all callers; convert it to a properly placed ASSERT(). The > "mostly" part being ad

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, 12 Aug 2016, Greg KH wrote: > > + Enabling this option never increases the size of your kernel. > > Then what does it do? Just burn electricity for no reason? I think that this whole thing could be without loss of generality reformulated in a "allows for participating in compile-te

Re: [Xen-devel] [Very RFC PATCH 3/3] livepatch: Initial ARM32/64 support.

On Fri, Aug 12, 2016 at 05:00:47PM +0200, Julien Grall wrote: > Hi Konrad, > > On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote: > > The initial support for ARM64 - and livepatching > > works: > > As it is a very RFC I only gave a quick look. I have few comments on it (see > below). > > > > > (

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

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

Re: [Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file

On Fri, 12 Aug 2016, Lars Kurth wrote: > On 11/08/2016 19:59, "Stefano Stabellini" wrote: > > >On Thu, 11 Aug 2016, Lars Kurth wrote: > >> On 11/08/2016 01:51, "Stefano Stabellini" > >>wrote: > >> > >> >> +Developer's Certificate of Origin > >> >> +- > >> >> + >

[Xen-devel] [seabios baseline-only test] 66971: tolerable FAIL

This run is configured for baseline tests only. flight 66971 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66971/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop

[Xen-devel] [distros-debian-jessie test] 66973: tolerable all pass

flight 66973 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66973/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail never pass test-armhf-ar

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

On Fri, 12 Aug 2016, Jan Beulich wrote: > > +Let me express this as an algorithm. > > + > > + treshhold=2/3; > > + active='number of active members'; (7 for the Hypervisor project; > > IanC is inactive) > > + favour='number of +1 and +2 votes' > > + against='number of -1 a

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

On Fri, Aug 12, 2016 at 10:23:34PM +0200, Greg KH wrote: > On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote: > > Alright, how's this new description: > > > > diff --git a/init/Kconfig b/init/Kconfig > > index cac3f096050d..73e4890c24c4 100644 > > --- a/init/Kconfig > > +++ b/init/

Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

On Fri, 12 Aug 2016, Lars Kurth wrote: > COPYING file: > The motivation of this change is to make it easier for new > contributors to conduct a license and patent review, WITHOUT > changing any licenses. > - Remove references to BSD-style licenses as we have more > common license exceptions and r

Re: [Xen-devel] [PATCH] xen: handle inbound migration of VMs without ioreq server pages

On Fri, 12 Aug 2016, Paul Durrant wrote: > > -Original Message- > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: 11 August 2016 21:07 > > To: Paul Durrant > > Cc: Anthony Perard; xen-de...@lists.xenproject.org; qemu- > > de...@nongnu.org; Stefano Stabellini > > Subject

[Xen-devel] [xen-unstable test] 100466: regressions - FAIL

flight 100466 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100466/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 7 host-ping-check-xen fail REGR. vs. 100431 test-amd64-amd64-x

  1   2   >