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

flight 100741 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/100741/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100669 test-amd64-amd64-xl-rtds

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

flight 100743 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100743/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 72092534a9283291edd6b497c9aa934049c4b928 baseline version: ovmf 646a9e5b799b009426fe3

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

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

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

flight 100738 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100738/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 debian-install fail REGR. vs. 100734 Regressions which

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

flight 100739 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100739/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 646a9e5b799b009426fe37af7ac8528a98cc96ce baseline version: ovmf 0b09c212a8aecf18bab23

Re: [Xen-devel] [PATCH 3/3] mini-os: update README to reflect recent changes

Juergen Gross, on Fri 02 Sep 2016 10:56:47 +0200, wrote: > Add some notes to README regarding configuration of Mini-OS via config > files. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault > + Please update the current configuration files when adding a new CONFIG_ > + item and ma

Re: [Xen-devel] [PATCH 2/3] mini-os: add testbuild target to Makefile

Juergen Gross, on Fri 02 Sep 2016 10:56:46 +0200, wrote: > Add a "testbuild" target to the Makefile to test building a set of > pre-defined configurations. > > Configurations tested are stored under arch//testbuild in form > of configuration files. All configurations found there are built in > a l

Re: [Xen-devel] [PATCH 1/3] mini-os: fix builds with uncommon config settings

Juergen Gross, on Fri 02 Sep 2016 10:56:45 +0200, wrote: > Some config settings won't build standalone. Fix the following cases: > > - all CONFIG_* set to "n" > - standard config with latest Xen interface version > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault > --- > include/x

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On Fri, Aug 26, 2016 at 01:26:33PM +, Lars Kurth wrote: > > > On 04/08/2016 07:52, "Tian, Kevin" wrote: > > >> From: Boris Ostrovsky > >> Sent: Monday, August 01, 2016 9:57 PM > >> On 07/18/2016 10:01 AM, Boris Ostrovsky wrote: > >> > ACPI builder is currently distributed under GPLv2 licens

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

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

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

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

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

flight 100737 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100737/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3 baseline version: ovmf 8953d69a5ca7f18f80f46

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

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

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

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

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

On Fri, Sep 2, 2016 at 1:10 PM, Julien Grall wrote: > > > On 02/09/2016 19:47, Tamas K Lengyel wrote: >> >> On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall >> wrote: >>> >>> On 02/09/2016 18:45, Andrew Cooper wrote: On 02/09/16 18:37, Tamas K Lengyel wrote: > > > On Tue,

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

On 02/09/2016 19:47, Tamas K Lengyel wrote: On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall wrote: On 02/09/2016 18:45, Andrew Cooper wrote: On 02/09/16 18:37, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru wrote: On 08/01/2016 08:59 PM, Tamas K Lengyel wrote: A

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall wrote: > On 02/09/2016 18:45, Andrew Cooper wrote: >> >> On 02/09/16 18:37, Tamas K Lengyel wrote: >>> >>> On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru >>> wrote: On 08/01/2016 08:59 PM, Tamas K Lengyel wrote: > > Add support for

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

On 02/09/2016 18:45, Andrew Cooper wrote: On 02/09/16 18:37, Tamas K Lengyel wrote: On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru wrote: On 08/01/2016 08:59 PM, Tamas K Lengyel wrote: Add support for getting/setting registers through vm_event on ARM. Only TTB/CR/R0/R1, PC and CPSR are sent

Re: [Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

On Wed, Aug 3, 2016 at 12:41 PM, Tamas K Lengyel wrote: > The two functions monitor_traps and mem_access_send_req duplicate some of the > same functionality. The mem_access_send_req however leaves a lot of the > standard vm_event fields to be filled by other functions. > > Remove mem_access_send_r

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

[PAUL] in line -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Friday, September 2, 2016 6:47 AM To: Lai, Paul C Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel Subject: Re: [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated. >>>

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

[PAUL] in-line Ravi -- please comment on swap comment below. -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Friday, September 2, 2016 6:31 AM To: Lai, Paul C Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel Subject: Re: [PATCH v2 Altp2m cleanup v3 2/3] Mov

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

On 02/09/16 18:37, Tamas K Lengyel wrote: > On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru > wrote: >> On 08/01/2016 08:59 PM, Tamas K Lengyel wrote: >>> Add support for getting/setting registers through vm_event on ARM. Only >>> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru wrote: > On 08/01/2016 08:59 PM, Tamas K Lengyel wrote: >> Add support for getting/setting registers through vm_event on ARM. Only >> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set >> as part of a response. The set of regi

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

flight 100736 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100736/ 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] [PATCH] libxc: zero-initialize structures in macros

On Fri, Sep 2, 2016 at 11:18 AM, Andrew Cooper wrote: > On 02/09/16 17:39, Tamas K Lengyel wrote: >> While debugging applications built on top of libxc with Valgrind we get a lot >> of complaining about relying on uninitialized values allocated in libxc. >> While these warnings are safe to ignore,

Re: [Xen-devel] [PATCH] libxc: zero-initialize structures in macros

On 02/09/16 17:39, Tamas K Lengyel wrote: > While debugging applications built on top of libxc with Valgrind we get a lot > of complaining about relying on uninitialized values allocated in libxc. > While these warnings are safe to ignore, zero-initializing the structures > reduces Valgrind clutter

[Xen-devel] [PATCH] libxc: zero-initialize structures in macros

While debugging applications built on top of libxc with Valgrind we get a lot of complaining about relying on uninitialized values allocated in libxc. While these warnings are safe to ignore, zero-initializing the structures reduces Valgrind clutter a lot and aids in spotting real bugs. Signed-off

Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

On Fri, Sep 02, 2016 at 01:08:27PM +0100, Wei Liu wrote: > On Fri, Sep 02, 2016 at 06:01:22AM -0600, Jan Beulich wrote: > > >>> On 02.09.16 at 13:47, wrote: > > > Currently only gcc 3.4 format is supported. > > > > Doesn't this patch contradict your coverage letter? Here you provide > > means to

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

Hi Vitaly, On 26/07/16 13:30, Vitaly Kuznetsov wrote: It may happen that Xen's and Linux's ideas of vCPU id diverge. In particular, when we crash on a secondary vCPU we may want to do kdump and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting on the vCPU which crashed. This

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

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On Sep 2, 2016 09:17, "Razvan Cojocaru" wrote: > > On 09/02/2016 06:13 PM, Tamas K Lengyel wrote: > > On Sep 2, 2016 09:03, "Jan Beulich" > > wrote: > >> > >> >>> On 02.09.16 at 16:50, > > wrote: > >> > On Sep 2, 2016 05:45, "Jan Beulich" >

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

On 01/09/16 16:27, Jan Beulich wrote: > >>> +{ >>> +if ( d->arch.x86_vendor == X86_VENDOR_AMD ) >>> +{ >>> +*eax = 0; >>> +*ebx = 0; >>> +*ecx = 0; >>> +*edx = 0; >>> +return; >>> +

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 06:13 PM, Tamas K Lengyel wrote: > On Sep 2, 2016 09:03, "Jan Beulich" > wrote: >> >> >>> On 02.09.16 at 16:50, > wrote: >> > On Sep 2, 2016 05:45, "Jan Beulich" > wrote: >> >> >> >> >>> On 02.09.16 at

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On Sep 2, 2016 09:03, "Jan Beulich" wrote: > > >>> On 02.09.16 at 16:50, wrote: > > On Sep 2, 2016 05:45, "Jan Beulich" wrote: > >> > >> >>> On 02.09.16 at 13:18, wrote: > >> > On 09/02/2016 01:02 PM, Jan Beulich wrote: > >> > On 02.09.16 at 10:51, wrote: > >> >>> Changes since V1 / RFC: >

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 16:50, wrote: > On Sep 2, 2016 05:45, "Jan Beulich" wrote: >> >> >>> On 02.09.16 at 13:18, wrote: >> > On 09/02/2016 01:02 PM, Jan Beulich wrote: >> > On 02.09.16 at 10:51, wrote: >> >>> Changes since V1 / RFC: >> >>> - Renamed xc_set_mem_access_sparse() to xc_set_mem_ac

[Xen-devel] [xen-unstable-smoke test] 100733: regressions - trouble: blocked/broken/pass

flight 100733 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100733/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 100732 Tests which

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On Sep 2, 2016 05:45, "Jan Beulich" wrote: > > >>> On 02.09.16 at 13:18, wrote: > > On 09/02/2016 01:02 PM, Jan Beulich wrote: > > On 02.09.16 at 10:51, wrote: > >>> Changes since V1 / RFC: > >>> - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(), > >>>and XENMEM_access_o

Re: [Xen-devel] [RFC] Classify and remove (some) abort()s in libxl

Andrew and Doug, do you have more comments? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

Thanks for posting. I go over all the patches and I think this series is in good shape. I will defer most of the table construction code to ARM maintainers. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 01/16] tools/libxl: Add an unified configuration option for ACPI

On Fri, Sep 02, 2016 at 10:55:24AM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > Since the existing configuration option "u.hvm.acpi" is x86 specific and > we want to reuse it on ARM as well, add a unified option "acpi" for > x86 and ARM, and for ARM it's disabled by default. > > Signed-of

Re: [Xen-devel] [PATCH v5 02/16] libxl/arm: prepare for constructing ACPI tables

On Fri, Sep 02, 2016 at 10:55:25AM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > It only constructs the ACPI tables for 64-bit ARM DomU when user enables > acpi because 32-bit DomU doesn't support ACPI. And the generation codes > are only built for 64-bit toolstack. > > Signed-off-by: Shan

Re: [Xen-devel] [PATCH v5 03/16] libxl/arm: Generate static ACPI DSDT table

On Fri, Sep 02, 2016 at 10:55:26AM +0800, Shannon Zhao wrote: > From: Shannon Zhao > > It uses static DSDT table like the way x86 uses. Currently the DSDT > table only contains processor device objects and it generates the > maximal objects which so far is 128. > > While the GUEST_MAX_VCPUS is d

Re: [Xen-devel] [PATCH v5] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

>>> On 02.09.16 at 10:20, wrote: > +/* smep: Enable/disable Supervisor Mode Execution Protection (default on). */ > +#define SMEP_HVM_ONLY (-1) > +static s8 __initdata opt_smep = 1; > +static void __init parse_smep_param(char *s) > +{ > +if ( !parse_bool(s) ) > +{ > +opt_smep = 0;

Re: [Xen-devel] Can't build ipxe with 6.1.1

Andrew Cooper writes ("Re: [Xen-devel] Can't build ipxe with 6.1.1"): > Ian: Can we see about getting xenbits:ipxe.git which works, and is > tested by osstest, in the same way as seabios currently is? As I said on IRC, I have no objection to this plan. When there is an appropriate ipxe git branch

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

On Tue, Aug 30, 2016 at 12:02:26PM +0100, Ian Jackson wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): > > Well, in a way. And then not: Initially I had thought no issue would > > arise, until I came to realize the kernel memory corruption potential. >

Re: [Xen-devel] [PATCH] docs: document old SUSE/Novell unplug for HVM

On Fri, Sep 02, 2016 at 11:32:55AM +0200, Olaf Hering wrote: > Signed-off-by: Olaf Hering More document is always a good thing. :-) I will leave the review to Konrad and Stefano because I don't know enough about this. ___ Xen-devel mailing list Xen-de

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

>>> On 02.09.16 at 15:15, wrote: > >> -Original Message- >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Friday, September 2, 2016 6:46 PM >> To: Wu, Feng >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; >> george.dun...@eu.citrix.com; Tian, Kevin ; xen- >> de...@li

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

flight 100712 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100712/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 100667 build-amd64-rumpuserxen

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

>>> On 19.08.16 at 19:22, wrote: > Ravi Sahita's dynamically allocated altp2m structs I think I've asked before: With this and ... > Signed-off-by: Paul Lai > Reviewed-by: Ravi Sahita ... this - who's the actual author? > @@ -5279,11 +5279,11 @@ static int do_altp2m_op( > break;

[Xen-devel] [PATCH] xen: Have __DEFINE_COMPAT_HANDLE() generate const versions

Both DEFINE_XEN_GUEST_HANDLE() and __DEFINE_XEN_GUEST_HANDLE() each produce both const and non-const handles, only DEFINE_COMPAT_HANDLE() does (__DEFINE_COMPAT_HANDLE() does not). This patch has __DEFINE_COMPAT_HANDLE() also produce a const handle. Suggested-by: Jan Beulich Signed-off-by: Razvan

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

flight 100732 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/100732/ 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] [PATCH] tools: delete gtraceview and gtracestat

On Fri, Sep 02, 2016 at 12:36:21PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH] tools: delete gtraceview and gtracestat"): > > On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote: > > > If so, it's probably just the case that the trace record format has > > > changed somewhat

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 04:26 PM, Julien Grall wrote: > > > On 02/09/16 14:22, Razvan Cojocaru wrote: >> On 09/02/2016 04:17 PM, Julien Grall wrote: >>> Hello Razvan, >> >> Hello Julien, thanks for the email! >> >>> On 02/09/16 09:51, Razvan Cojocaru wrote: Currently it is only possible to set mem_acc

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

On Fri, Sep 02, 2016 at 02:21:28PM +0100, Julien Grall wrote: > Hi Wei, > > On 02/09/16 13:01, Wei Liu wrote: > >On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: > >On 02.09.16 at 13:47, wrote: > >> > >>Since this is a config option - why bother issuing a warning and > >>tainting

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

On Fri, Sep 02, 2016 at 01:30:40PM +0100, Andrew Cooper wrote: > On 02/09/16 13:26, Jan Beulich wrote: > On 02.09.16 at 14:13, wrote: > >> On 02/09/16 13:06, Jan Beulich wrote: > >> On 02.09.16 at 14:01, wrote: > On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: > >>>

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

>>> On 19.08.16 at 19:22, wrote: > @@ -65,6 +66,50 @@ altp2m_vcpu_destroy(struct vcpu *v) > vcpu_unpause(v); > } > > +int > +hvm_altp2m_init( struct domain *d) Stray blank (more elsewhere). Also I don't think hvm_ is a proper prefix for a function placed in this file, i.e. if altp2m_i

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 02/09/16 14:22, Razvan Cojocaru wrote: > On 09/02/2016 04:17 PM, Julien Grall wrote: >> Hello Razvan, > > Hello Julien, thanks for the email! > >> On 02/09/16 09:51, Razvan Cojocaru wrote: >>> Currently it is only possible to set mem_access restrictions only for >>> a contiguous range of GFN

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 04:10 PM, Jan Beulich wrote: On 02.09.16 at 15:03, wrote: >> On 09/02/2016 03:56 PM, Jan Beulich wrote: >> On 02.09.16 at 14:41, wrote: On 09/02/2016 03:33 PM, Jan Beulich wrote: On 02.09.16 at 14:21, wrote: >> On 09/02/2016 01:02 PM, Jan Beulich wrote: >

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

Hi Wei, On 02/09/16 13:01, Wei Liu wrote: On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: On 02.09.16 at 13:47, wrote: Since this is a config option - why bother issuing a warning and tainting the hypervisor? Because there isn't a clear indicator if gcov is enabled. I think

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 04:17 PM, Julien Grall wrote: > Hello Razvan, Hello Julien, thanks for the email! > On 02/09/16 09:51, Razvan Cojocaru wrote: >> Currently it is only possible to set mem_access restrictions only for >> a contiguous range of GFNs (or, as a particular case, for a single GFN). >> This

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

Hello Razvan, On 02/09/16 09:51, Razvan Cojocaru wrote: Currently it is only possible to set mem_access restrictions only for a contiguous range of GFNs (or, as a particular case, for a single GFN). This patch introduces a new libxc function taking an array of GFNs. The alternative would be to s

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, September 2, 2016 6:46 PM > To: Wu, Feng > Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; > george.dun...@eu.citrix.com; Tian, Kevin ; xen- > de...@lists.xen.org > Subject: RE: [PATCH v3 4/6] P

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

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

Re: [Xen-devel] xen arm64 dom0 question

On 02/09/16 12:27, Peng Fan wrote: Hi Julien, Stefano Hi Peng, On My ARM64 platform, there is 6GB memory. 0x8000 - 0xfff: 2GB 0x88000 - 0x9: 4GB xen will alloc 1:1 mapping for Dom0 memory, so if I assign dom0_mem with a bigger value, saying 2048MB or bigger. xen will

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 15:03, wrote: > On 09/02/2016 03:56 PM, Jan Beulich wrote: > On 02.09.16 at 14:41, wrote: >>> On 09/02/2016 03:33 PM, Jan Beulich wrote: >>> On 02.09.16 at 14:21, wrote: > On 09/02/2016 01:02 PM, Jan Beulich wrote: >>> +/* + * Corresponding lis

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 1/3] altp2m cleanup work

>>> On 19.08.16 at 19:22, wrote: > @@ -5213,12 +5213,25 @@ static int do_altp2m_op( > return -EFAULT; > > if ( a.pad1 || a.pad2 || > - (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) || > - (a.cmd < HVMOP_altp2m_get_domain_state) || > - (a.cmd > HVMOP_altp2m_c

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 03:56 PM, Jan Beulich wrote: On 02.09.16 at 14:41, wrote: >> On 09/02/2016 03:33 PM, Jan Beulich wrote: >> On 02.09.16 at 14:21, wrote: On 09/02/2016 01:02 PM, Jan Beulich wrote: >> +/* >>> + * Corresponding list of access settings for pfn_list >>>

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 14:41, wrote: > On 09/02/2016 03:33 PM, Jan Beulich wrote: > On 02.09.16 at 14:21, wrote: >>> On 09/02/2016 01:02 PM, Jan Beulich wrote: > +/* >> + * Corresponding list of access settings for pfn_list >> + * Used only with XENMEM_access_op_set_access

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

flight 100721 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/100721/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89 baseline version: ovmf 4a2aaff2fca69d9f41c5b

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

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

Re: [Xen-devel] [PATCH 23/24] xen: credit2: optimize runq_tickle() a little bit

On 17/08/16 18:20, Dario Faggioli wrote: By not looking at the same cpu (to check whether we want to preempt who's running there) twice, if the vcpu being woken up has both soft and hard affinity. In fact, all the cpus that are part of both soft affinity and hard-affinity (of the waking vcpu) ar

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 03:33 PM, Jan Beulich wrote: On 02.09.16 at 14:21, wrote: >> On 09/02/2016 01:02 PM, Jan Beulich wrote: +/* > + * Corresponding list of access settings for pfn_list > + * Used only with XENMEM_access_op_set_access_multi > + */ > +XEN_GUES

Re: [Xen-devel] fail to register IRQ for virtualization exception

Or should I modify the linux kernel to add support for handling #VE exception? 2016-09-02 16:35 GMT+08:00 Big Strong : > Sorry for that. Could you give any suggestions on how to register the IRQ > handler for #VE? > > 2016-09-02 15:52 GMT+08:00 Jan Beulich : > >> >>> On 02.09.16 at 04:59, wrote:

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 14:21, wrote: > On 09/02/2016 01:02 PM, Jan Beulich wrote: >>> +/* >>> > + * Corresponding list of access settings for pfn_list >>> > + * Used only with XENMEM_access_op_set_access_multi >>> > + */ >>> > +XEN_GUEST_HANDLE(uint8) access_list; >> And for both o

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

On 02/09/16 13:26, Jan Beulich wrote: On 02.09.16 at 14:13, wrote: >> On 02/09/16 13:06, Jan Beulich wrote: >> On 02.09.16 at 14:01, wrote: On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: On 02.09.16 at 13:47, wrote: > Since this is a config option - why b

[Xen-devel] [PATCH v2] xen/pciback: support driver_override

Support the driver_override scheme introduced with commit 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override") As pcistub_probe() is called for all devices (it has to check for a match based on the slot address rather than device type) it has to check for driver_ov

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

>>> On 02.09.16 at 14:13, wrote: > On 02/09/16 13:06, Jan Beulich wrote: > On 02.09.16 at 14:01, wrote: >>> On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: >>> On 02.09.16 at 13:47, wrote: Since this is a config option - why bother issuing a warning and tainting th

Re: [Xen-devel] [PATCH] xen/pciback: support driver_override

nce) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Juergen-Gross/xen-pciback-support-driver_override/20160902-195956 base: https://git.kernel.org/

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

On 09/02/2016 01:02 PM, Jan Beulich wrote: >> +/* >> > + * Corresponding list of access settings for pfn_list >> > + * Used only with XENMEM_access_op_set_access_multi >> > + */ >> > +XEN_GUEST_HANDLE(uint8) access_list; > And for both of them - I don't think the arrays are mean

Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

On 02/09/16 13:06, Wei Liu wrote: > On Fri, Sep 02, 2016 at 01:04:45PM +0100, Andrew Cooper wrote: >> On 02/09/16 12:47, Wei Liu wrote: >>> This series further cleans up existing gcov code. It should be now clear >>> that >>> Xen's gcov is using gcc 3.4 format. >>> >>> I have tried to integrate gc

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

On 02/09/16 13:06, Jan Beulich wrote: On 02.09.16 at 14:01, wrote: >> On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: >> On 02.09.16 at 13:47, wrote: >>> Since this is a config option - why bother issuing a warning and >>> tainting the hypervisor? >>> >> Because there isn't

Re: [Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

On Fri, Sep 02, 2016 at 05:58:43AM -0600, Jan Beulich wrote: > >>> On 02.09.16 at 13:47, wrote: > > --- a/xen/arch/x86/xen.lds.S > > +++ b/xen/arch/x86/xen.lds.S > > @@ -205,6 +205,8 @@ SECTIONS > > . = ALIGN(8); > > __ctors_start = .; > > *(.ctors) > > + *(SORT(.init

Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

On Fri, Sep 02, 2016 at 06:01:22AM -0600, Jan Beulich wrote: > >>> On 02.09.16 at 13:47, wrote: > > Currently only gcc 3.4 format is supported. > > Doesn't this patch contradict your coverage letter? Here you provide > means to add support for further formats, but there you said there's > no obvi

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

>>> On 02.09.16 at 14:01, wrote: > On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: >> >>> On 02.09.16 at 13:47, wrote: >> >> Since this is a config option - why bother issuing a warning and >> tainting the hypervisor? >> > > Because there isn't a clear indicator if gcov is enabled

Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

On Fri, Sep 02, 2016 at 01:04:45PM +0100, Andrew Cooper wrote: > On 02/09/16 12:47, Wei Liu wrote: > > This series further cleans up existing gcov code. It should be now clear > > that > > Xen's gcov is using gcc 3.4 format. > > > > I have tried to integrate gcc 4.7 format. The amount of work is m

Re: [Xen-devel] [PATCH 0/5] gcov: more cleanup

On 02/09/16 12:47, Wei Liu wrote: > This series further cleans up existing gcov code. It should be now clear that > Xen's gcov is using gcc 3.4 format. > > I have tried to integrate gcc 4.7 format. The amount of work is moderate in > terms of coding effort, but I now believe it is a mistake to have

Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

>>> On 02.09.16 at 13:47, wrote: > Currently only gcc 3.4 format is supported. Doesn't this patch contradict your coverage letter? Here you provide means to add support for further formats, but there you said there's no obvious route to that goal. Jan __

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote: > >>> On 02.09.16 at 13:47, wrote: > > Since this is a config option - why bother issuing a warning and > tainting the hypervisor? > Because there isn't a clear indicator if gcov is enabled. I think it would be valuable to just tell

Re: [Xen-devel] [PATCH 3/5] xen: replace TEST_COVERAGE with CONFIG_GCOV

>>> On 02.09.16 at 13:47, wrote: > The sole purpose of TEST_COVERAGE macro is to guard the availability of > gcov sysctl. Now we have a proper CONFIG_GCOV, use it. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-deve

Re: [Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

>>> On 02.09.16 at 13:47, wrote: > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -205,6 +205,8 @@ SECTIONS > . = ALIGN(8); > __ctors_start = .; > *(.ctors) > + *(SORT(.init_array.*)) > + *(.init_array) > __ctors_end = .; >} :text

[Xen-devel] [PATCH] xen/pciback: support driver_override

Support the driver_override scheme introduced with commit 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override") As pcistub_probe() is called for all devices (it has to check for a match based on the slot address rather than device type) it has to check for driver_ov

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

>>> On 02.09.16 at 13:47, wrote: Since this is a config option - why bother issuing a warning and tainting the hypervisor? > --- a/xen/common/gcov/gcov.c > +++ b/xen/common/gcov/gcov.c > @@ -23,6 +23,11 @@ > #include > #include > > +const char __initconst warning_gcov[] = > +"WARNING:

[Xen-devel] [PATCH 0/5] gcov: more cleanup

This series further cleans up existing gcov code. It should be now clear that Xen's gcov is using gcc 3.4 format. I have tried to integrate gcc 4.7 format. The amount of work is moderate in terms of coding effort, but I now believe it is a mistake to have invented xen specific format which is in f

[Xen-devel] [PATCH 5/5] gcov: split out gcc version specific stuff

Gcov record format is tied to specific gcc versions. The current code in tree conforms to gcc 3.4 format. Move structure definitions to a specific file and factor out some version specific functions. No functional change. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian

[Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

Signed-off-by: Wei Liu --- The location of warning_add() is a bit arbitrary because gcov doesn't have an initialisation routine. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- xen/common/

[Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

The version of gcc (4.9.2) I use put constructors into .init_array* section(s). Collect those sections into constructor list as well. Modify both arm and x86 scripts to keep them in sync. Signed-off-by: Wei Liu --- Cc: Stefano Stabellini Cc: Julien Grall Cc: Jan Beulich Cc: Andrew Cooper ---

[Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

Currently only gcc 3.4 format is supported. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- xen/Kconfig.debug | 13 + 1 file changed, 13 insertions(+

[Xen-devel] [PATCH 3/5] xen: replace TEST_COVERAGE with CONFIG_GCOV

The sole purpose of TEST_COVERAGE macro is to guard the availability of gcov sysctl. Now we have a proper CONFIG_GCOV, use it. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc:

Re: [Xen-devel] [PATCH 19/24] xen: credit2: soft-affinity awareness in load balancing

On 17/08/16 18:19, Dario Faggioli wrote: We want is soft-affinity to play a role in load balancing, i.e., when deciding whether or not to something like that at some point. (Oh, and while there, just a couple of style fixes are also done.) Signed-off-by: Dario Faggioli --- Cc: George Dunlap

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

>>> On 02.09.16 at 13:18, wrote: > On 09/02/2016 01:02 PM, Jan Beulich wrote: > On 02.09.16 at 10:51, wrote: >>> Changes since V1 / RFC: >>> - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(), >>>and XENMEM_access_op_set_access_sparse to >>>XENMEM_access_op_set_access_

  1   2   >