Re: [Xen-devel] [PATCH RFC v2] x86/domctl: Don't pause the whole domain if only getting vcpu state

>>> On 21.02.18 at 19:24, wrote: > On Fri, Oct 6, 2017 at 11:02 AM, Alexandru Isaila > wrote: >> This patch adds the hvm_save_one_cpu_ctxt() function. >> It optimizes by only pausing the vcpu on all HVMSR_PER_VCPU save >> callbacks where only data for one VCPU is required. > > Sorry it's taken s

Re: [Xen-devel] ARM64:Porting xen to new hardware

On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall wrote: > Hello, > > On 03/10/17 08:05, bharat gohil wrote: > >> >> >> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall > > wrote: >> >> >> >> On 09/29/2017 09:15 AM, bharat gohil wrote: >> >> Hello >> >> >> Hi

[Xen-devel] [PATCH] get_maintainers.pl: Avoid THE_REST when files are added or removed

When files are added or removed /dev/null is used as a place holder name in the patch for the absent file. Don't try and find a MAINTAINER for this place holder, it only ever flags and then spams THE REST. Signed-off-by: Alan Robinson --- Tested by pretending to remove xen/common/cpupool.c for

Re: [Xen-devel] [PATCH RFC] CODING_STYLE: document intended usage of types

>>> On 21.02.18 at 16:34, wrote: > On Mon, Feb 19, 2018 at 8:44 AM, Jan Beulich wrote: >> +When signedness matters, qualify plain char, short, int, long, and >> +long long with "signed" or "unsigned". Signedness is specifically >> +considered to matter when the valid value range of a variable co

Re: [Xen-devel] [PATCH v4 14/28] x86/vvtd: Handle interrupt translation faults

On Mon, Feb 12, 2018 at 12:55:06PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:21PM +0800, Chao Gao wrote: >> Interrupt translation faults are non-recoverable fault. When faults >> are triggered, it needs to populate fault info to Fault Recording >> Registers and inject msi interru

Re: [Xen-devel] [PATCH v5 3/5] x86/clang: restore integrated assembler usage with indirect thunks

On Wed, Feb 21, 2018 at 04:56:14PM +, Andrew Cooper wrote: > On 20/02/18 14:10, Roger Pau Monne wrote: > > If the required features are met by the integrated clang assembler > > (support for .includes and propagation of .macro-s between asm()-s) > > do not disable it. > > > > Only disable the i

Re: [Xen-devel] [PATCH] get_maintainers.pl: Avoid THE_REST when files are added or removed

>>> On 22.02.18 at 10:09, wrote: > When files are added or removed /dev/null is used as a place > holder name in the patch for the absent file. Don't try and > find a MAINTAINER for this place holder, it only ever flags > and then spams THE REST. When a file is added, it falls under THE REST mai

Re: [Xen-devel] [PATCH] get_maintainers.pl: Avoid THE_REST when files are added or removed

Hi Jan, On Thu, Feb 22, 2018 at 02:16:23AM -0700, Jan Beulich wrote: > From: Jan Beulich > Subject: Re: [PATCH] get_maintainers.pl: Avoid THE_REST when files are > added or removed > > >>> On 22.02.18 at 10:09, wrote: > > When files are added or removed /dev/null is used as a place > > holder

Re: [Xen-devel] [PATCH] intel_iommu: allow updating FEADDR and FEUADDR with one 64bit write

On Wed, Jan 24, 2018 at 03:18:48PM +0100, Marek Marczykowski-Górecki wrote: > Allow updating those two adjacent 32bit fields with one 64bit write. > This fixes qemu crash when booting Xen inside. > > See discussion on Xen side of the thing here: > http://xen.markmail.org/message/6mrmemrnmhxvaxba X

Re: [Xen-devel] [PATCH v2] VT-d: use two 32-bit writes to update DMAR fault address registers

On Wed, Oct 11, 2017 at 05:27:05AM -0600, Jan Beulich wrote: > >>> On 11.10.17 at 05:03, wrote: > > --- a/xen/drivers/passthrough/vtd/iommu.c > > +++ b/xen/drivers/passthrough/vtd/iommu.c > > @@ -1105,7 +1105,13 @@ static void dma_msi_set_affinity(struct irq_desc > > *desc, const cpumask_t *mask)

Re: [Xen-devel] [PATCH] get_maintainers.pl: Avoid THE_REST when files are added or removed

>>> On 22.02.18 at 10:27, wrote: > On Thu, Feb 22, 2018 at 02:16:23AM -0700, Jan Beulich wrote: >> From: Jan Beulich >> Subject: Re: [PATCH] get_maintainers.pl: Avoid THE_REST when files are >> added or removed >> >> >>> On 22.02.18 at 10:09, wrote: >> > When files are added or removed /dev/nu

Re: [Xen-devel] ARM64:Porting xen to new hardware

On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil wrote: > > > On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall wrote: > >> Hello, >> >> On 03/10/17 08:05, bharat gohil wrote: >> >>> >>> >>> On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall >> > wrote: >>> >>> >>> >>> On 09

[Xen-devel] [libvirt test] 119792: tolerable all pass - PUSHED

flight 119792 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/119792/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 119702 test-armhf-armhf-libvirt-raw 13 saveresto

Re: [Xen-devel] [PATCH v2] VT-d: use two 32-bit writes to update DMAR fault address registers

>>> On 22.02.18 at 10:44, wrote: > On Wed, Oct 11, 2017 at 05:27:05AM -0600, Jan Beulich wrote: >> >>> On 11.10.17 at 05:03, wrote: >> > --- a/xen/drivers/passthrough/vtd/iommu.c >> > +++ b/xen/drivers/passthrough/vtd/iommu.c >> > @@ -1105,7 +1105,13 @@ static void dma_msi_set_affinity(struct irq

Re: [Xen-devel] ARM64:Porting xen to new hardware

On Thu, Feb 22, 2018 at 3:15 PM, bharat gohil wrote: > > > On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil wrote: > >> >> >> On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall >> wrote: >> >>> Hello, >>> >>> On 03/10/17 08:05, bharat gohil wrote: >>> On Fri, Sep 29, 2017 at 11:12 PM, Jul

Re: [Xen-devel] [PATCH] get_maintainers.pl: Avoid THE_REST when files are added or removed

Hi Jan, On Thu, Feb 22, 2018 at 02:45:48AM -0700, Jan Beulich wrote: > Oh, I see - it's the file name collection code you change, not the > consuming side, I'm sorry for the noise. However, isn't > omitting the leading / a potential problem then? The leading / is stripped away several lines befor

Re: [Xen-devel] ARM64:Porting xen to new hardware

typo On Thu, Feb 22, 2018 at 4:03 PM, bharat gohil wrote: > > > On Thu, Feb 22, 2018 at 3:15 PM, bharat gohil wrote: > >> >> >> On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil wrote: >> >>> >>> >>> On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall >>> wrote: >>> Hello, On 03/10/17 08:

[Xen-devel] [PATCH] build: Help attempts to syntax highlight Config.mk

Some attempts to syntax highlight Config.mk end up thinking that most of Config.mk is a string, due to the unbalanced squote. Provide a balancing squote in a comment to compensate. No functional change. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Ko

[Xen-devel] [PATCH] build: Rename as-insn-check to as-insn-add

as-insn-check mutates the passed-in flags. Rename it to as-insn-add, in line with cc-option-add. Update all callers. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim Deegan CC: Wei Liu CC: Roger Pa

Re: [Xen-devel] [PATCH] build: Help attempts to syntax highlight Config.mk

On 02/22/2018 10:50 AM, Andrew Cooper wrote: > Some attempts to syntax highlight Config.mk end up thinking that most of > Config.mk is a string, due to the unbalanced squote. Provide a balancing > squote in a comment to compensate. > > No functional change. > > Signed-off-by: Andrew Cooper > --

Re: [Xen-devel] ARM64:Porting xen to new hardware

Hello Bharat, On 22.02.18 12:33, bharat gohil wrote: System got hand and I got following traces related to energy aware scheduler. Is Xen affected with guest scheduling mechanism? I have SoC which has 4-Cortex A35 and 2-Cortex A72. [    0.202545] Xen: initializing cpu4 [    0.202562] Invalid

Re: [Xen-devel] ARM64:Porting xen to new hardware

Hello Bharat, Threads [1], [2] should feed your interest about big.LITTLE support in XEN. [1] - https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00079.html [2] - https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01695.html -- *Andrii Anisov* __

[Xen-devel] [PATCH v2 ] get_maintainers.pl: Avoid THE_REST when files are added or removed

When files are added or removed /dev/null is used as a place holder name in the patch for the absent file. Don't try and find a MAINTAINER for this place holder, it only ever flags and then spams THE REST, behaviour for a real filename is unchanged. Signed-off-by: Alan Robinson --- v1 - original

[Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

Jim Fehlig writes ("[PATCH] xenstore: increase default thread stack size to 32k"): > On several Skylake machines I've observed xl segfaults when running > create or destroy subcommands. Other subcommands may segfault too, > but I've only looked at create and destroy which share a similar > backtra

Re: [Xen-devel] ARM64:Porting xen to new hardware

On 22/02/18 11:01, Andrii Anisov wrote: On 22.02.18 12:33, bharat gohil wrote: System got hand and I got following traces related to energy aware scheduler. Is Xen affected with guest scheduling mechanism? I have SoC which has 4-Cortex A35 and 2-Cortex A72. [    0.202545] Xen: initializing

Re: [Xen-devel] [PATCH v4 15/28] x86/vvtd: Enable Queued Invalidation through GCMD

On Mon, Feb 12, 2018 at 02:04:46PM +, Roger Pau Monné wrote: >On Fri, Nov 17, 2017 at 02:22:22PM +0800, Chao Gao wrote: >> Software writes to QIE field of GCMD to enable or disable queued >> invalidations. This patch emulates QIE field of GCMD. >> >> Signed-off-by: Chao Gao >> Signed-off-by:

Re: [Xen-devel] ARM64:Porting xen to new hardware

Hi, Please configure your e-mail client to quote with '>'. It is incredibly difficult to read e-mail when space is used for quoting (see below). On 22/02/18 10:33, bharat gohil wrote: I have tried your suggestion, I got following crash. It unable find interrupt controller but

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

flight 119785 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/119785/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 11

Re: [Xen-devel] [PATCH] build: Rename as-insn-check to as-insn-add

>>> On 22.02.18 at 11:51, wrote: > as-insn-check mutates the passed-in flags. Rename it to as-insn-add, in line > with cc-option-add. Update all callers. I'm not convinced - cc-option-add makes relatively clear that something is being added to the options passed to CC. If I take as-insn-add thi

Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

Juergen Gross writes ("Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k"): > The main problem is that any thread local storage is taken from the > stack without any interface being available for adjusting the _real_ > stack size instead of the meory for thread local stor

Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

On Thu, Feb 22, 2018 at 11:16:53AM +, Ian Jackson wrote: > Jim Fehlig writes ("[PATCH] xenstore: increase default thread stack size to > 32k"): > > On several Skylake machines I've observed xl segfaults when running > > create or destroy subcommands. Other subcommands may segfault too, > > but

Re: [Xen-devel] [PATCH] get_maintainers.pl: Avoid THE_REST when files are added or removed

Jan Beulich writes ("Re: [PATCH] get_maintainers.pl: Avoid THE_REST when files are added or removed"): > On 22.02.18 at 10:27, wrote: > Oh, I see - it's the file name collection code you change, not the > consuming side, I'm sorry for the noise. However, isn't > omitting the leading / a potential

Re: [Xen-devel] [PATCH] build: Rename as-insn-check to as-insn-add

On 22/02/18 11:33, Jan Beulich wrote: On 22.02.18 at 11:51, wrote: >> as-insn-check mutates the passed-in flags. Rename it to as-insn-add, in line >> with cc-option-add. Update all callers. > I'm not convinced - cc-option-add makes relatively clear that > something is being added to the opt

Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

On 22/02/18 12:35, Roger Pau Monné wrote: > On Thu, Feb 22, 2018 at 11:16:53AM +, Ian Jackson wrote: >> Jim Fehlig writes ("[PATCH] xenstore: increase default thread stack size to >> 32k"): >>> On several Skylake machines I've observed xl segfaults when running >>> create or destroy subcommand

[Xen-devel] [PATCH] xtf: fix cdefs.h conflict with __section

On FreeBSD the build fails with: /root/src/xtf/include/xtf/compiler.h:13:9: error: '__section' macro redefined [-Werror,-Wmacro-redefined] #define __section(s) __attribute__((__section__(s))) ^ /usr/include/sys/cdefs.h:229:9: note: previous definition is here #define __secti

Re: [Xen-devel] [PATCH] xtf: fix cdefs.h conflict with __section

On 22/02/18 12:03, Roger Pau Monne wrote: > On FreeBSD the build fails with: > > /root/src/xtf/include/xtf/compiler.h:13:9: error: '__section' macro redefined > [-Werror,-Wmacro-redefined] > #define __section(s) __attribute__((__section__(s))) > ^ > /usr/include/sys/cdefs.h:2

[Xen-devel] [xen-devel] [fuzz] [x86 emulator] Input size

Hello, In the x86 instruction emulator fuzzer, when checking wether the input size is correct, we are checking for this bounds : DATA_OFFSET < size < INPUT_SIZE. The fact is that INPUT_SIZE is actually the size of the data buffer in the fuzz_corpus structure. This way, AFL is not able to ha

Re: [Xen-devel] [PATCH] build: Rename as-insn-check to as-insn-add

>>> On 22.02.18 at 12:41, wrote: > On 22/02/18 11:33, Jan Beulich wrote: > On 22.02.18 at 11:51, wrote: >>> as-insn-check mutates the passed-in flags. Rename it to as-insn-add, in >>> line >>> with cc-option-add. Update all callers. >> I'm not convinced - cc-option-add makes relatively cle

Re: [Xen-devel] [PATCH] xtf: fix cdefs.h conflict with __section

>>> On 22.02.18 at 13:03, wrote: > On FreeBSD the build fails with: > > /root/src/xtf/include/xtf/compiler.h:13:9: error: '__section' macro > redefined > [-Werror,-Wmacro-redefined] > #define __section(s) __attribute__((__section__(s))) > ^ > /usr/include/sys/cdefs.h:229:9

Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

On 22/02/18 12:33, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] [PATCH] xenstore: increase default > thread stack size to 32k"): >> The main problem is that any thread local storage is taken from the >> stack without any interface being available for adjusting the _real_ >> stack si

Re: [Xen-devel] [PATCH] xtf: fix cdefs.h conflict with __section

On 22/02/18 12:24, Jan Beulich wrote: On 22.02.18 at 13:03, wrote: >> On FreeBSD the build fails with: >> >> /root/src/xtf/include/xtf/compiler.h:13:9: error: '__section' macro >> redefined >> [-Werror,-Wmacro-redefined] >> #define __section(s) __attribute__((__section__(s)))

Re: [Xen-devel] [PATCH] build: Rename as-insn-check to as-insn-add

On 02/22/2018 12:22 PM, Jan Beulich wrote: On 22.02.18 at 12:41, wrote: >> On 22/02/18 11:33, Jan Beulich wrote: >> On 22.02.18 at 11:51, wrote: as-insn-check mutates the passed-in flags. Rename it to as-insn-add, in line with cc-option-add. Update all callers. >>> I'm

Re: [Xen-devel] [PATCH] xen/tools: support Python 2 and Python 3

On 22/02/18 05:52, Doug Goldstein wrote: > These changes should make it possible to support modern Pythons as well > as the oldest Python 2 still supported. > > Signed-off-by: Doug Goldstein To the overall effect, this is definitely a good thing.  Some queries however... > --- > CC: Andrew Coope

[Xen-devel] [seabios test] 119788: regressions - FAIL

flight 119788 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/119788/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not suc

Re: [Xen-devel] [PATCH] xtf: fix cdefs.h conflict with __section

>>> On 22.02.18 at 13:28, wrote: > On 22/02/18 12:24, Jan Beulich wrote: > On 22.02.18 at 13:03, wrote: >>> On FreeBSD the build fails with: >>> >>> /root/src/xtf/include/xtf/compiler.h:13:9: error: '__section' macro >>> redefined >>> [-Werror,-Wmacro-redefined] >>> #define __section(s

Re: [Xen-devel] [PATCH] build: Rename as-insn-check to as-insn-add

>>> On 22.02.18 at 13:39, wrote: > On 02/22/2018 12:22 PM, Jan Beulich wrote: > On 22.02.18 at 12:41, wrote: >>> On 22/02/18 11:33, Jan Beulich wrote: >>> On 22.02.18 at 11:51, wrote: > as-insn-check mutates the passed-in flags. Rename it to as-insn-add, in > line > with cc

[Xen-devel] [PATCH] x86/HVM: don't give the wrong impression of WRMSR succeeding

... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says that the function returns 0 for unrecognized MSRs, so {svm,vmx}_msr_write_intercept() should not convert this into success. At the time it went in, commit 013e34f5a6 ("x86: handle paged gfn in wrmsr_hypervisor_regs") was probably

Re: [Xen-devel] [PATCH RFC v2] x86/domctl: Don't pause the whole domain if only getting vcpu state

On Mi, 2018-02-21 at 18:24 +, George Dunlap wrote: > On Fri, Oct 6, 2017 at 11:02 AM, Alexandru Isaila > wrote: > > > > This patch adds the hvm_save_one_cpu_ctxt() function. > > It optimizes by only pausing the vcpu on all HVMSR_PER_VCPU save > > callbacks where only data for one VCPU is requi

[Xen-devel] [PATCH] tools/xenstore: try to get minimum thread stack size for watch thread

When creating a pthread in xs_watch() try to get the minimal needed size of the thread from glibc instead of using a constant. This avoids problems when the library is used in programs with large per-thread memory. Use dlsym() to get the pointer to __pthread_get_minstack() in order to avoid linkag

Re: [Xen-devel] [PATCH v3 05/17] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

On 21/02/18 14:27, Andre Przywara wrote: Hi, Hi Andre, On 15/02/18 15:02, Julien Grall wrote: The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for hardening the branch predictor. So we want the handling to be as fast as possible. As the mitigation is applied on every guest

Re: [Xen-devel] [PATCH v5 4/5] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

>>> On 20.02.18 at 15:10, wrote: > When indirect_thunk_asm.h is instantiated directly into assembly files > CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against > it is wrong. > > Add a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so > that using .if CONFIG_INDIREC

Re: [Xen-devel] [PATCH v5 5/5] build/clang: add a check whether the assembler supports .skip with labels

>>> On 20.02.18 at 15:10, wrote: > Or else disable the integrated assembler for assembly files. This is > relevant for older clang versions which integrated assembler don't > support .skip with labels. > > Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich but pending the decision what to do

Re: [Xen-devel] [PATCH] x86/HVM: don't give the wrong impression of WRMSR succeeding

On 02/22/2018 08:44 AM, Jan Beulich wrote: > ... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says > that the function returns 0 for unrecognized MSRs, so > {svm,vmx}_msr_write_intercept() should not convert this into success. > > At the time it went in, commit 013e34f5a6 ("x86: hand

Re: [Xen-devel] [PATCH] x86/HVM: don't give the wrong impression of WRMSR succeeding

On 22/02/18 13:44, Jan Beulich wrote: > ... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says > that the function returns 0 for unrecognized MSRs, so > {svm,vmx}_msr_write_intercept() should not convert this into success. > > At the time it went in, commit 013e34f5a6 ("x86: handle pa

Re: [Xen-devel] [PATCH] x86/HVM: don't give the wrong impression of WRMSR succeeding

>>> On 22.02.18 at 15:53, wrote: > On 22/02/18 13:44, Jan Beulich wrote: >> ... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says >> that the function returns 0 for unrecognized MSRs, so >> {svm,vmx}_msr_write_intercept() should not convert this into success. >> >> At the time it we

Re: [Xen-devel] [PATCH] x86/HVM: don't give the wrong impression of WRMSR succeeding

On 22/02/18 15:00, Jan Beulich wrote: On 22.02.18 at 15:53, wrote: >> On 22/02/18 13:44, Jan Beulich wrote: >>> ... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says >>> that the function returns 0 for unrecognized MSRs, so >>> {svm,vmx}_msr_write_intercept() should not convert

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

flight 119797 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/119797/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 119692 test-amd64-amd64-xl-qemuu-win7-amd6

Re: [Xen-devel] [PATCH] x86/HVM: don't give the wrong impression of WRMSR succeeding

>>> On 22.02.18 at 15:53, wrote: > On 22/02/18 13:44, Jan Beulich wrote: >> ... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says >> that the function returns 0 for unrecognized MSRs, so >> {svm,vmx}_msr_write_intercept() should not convert this into success. >> >> At the time it we

Re: [Xen-devel] [PATCH] xenstore: increase default thread stack size to 32k

On 02/21/2018 10:18 PM, Juergen Gross wrote: On 21/02/18 23:13, Jim Fehlig wrote: On several Skylake machines I've observed xl segfaults when running create or destroy subcommands. Other subcommands may segfault too, but I've only looked at create and destroy which share a similar backtrace Thr

Re: [Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 21/02/18 16:07, Andre Przywara wrote: Hi, Hi Andre, On 15/02/18 15:02, Julien Grall wrote: Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. Signed-off-by: Julien Grall --- Changes in v3: - Add the missing call to smc #0. Changes in v2:

Re: [Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi, On 21/02/18 17:35, Stefano Stabellini wrote: On Wed, 21 Feb 2018, Julien Grall wrote: Hi Stefano, On 21/02/2018 00:35, Stefano Stabellini wrote: On Thu, 15 Feb 2018, Julien Grall wrote: Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. Signed-off-by: Julien Grall ---

Re: [Xen-devel] [PATCH v3 12/17] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

On 21/02/18 16:37, Julien Grall wrote: On 21/02/18 16:27, Andre Przywara wrote: Hi, Hi, On 15/02/18 15:02, Julien Grall wrote: Currently, the behavior of do_common_cpu will slightly change depending on the PSCI version passed in parameter. Looking at the code, more the specific 0.2 beha

Re: [Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

On Wed, Feb 21, 2018 at 02:02:51PM +, Julien Grall wrote: > The function populate_pt_range is used to populate in advance the > page-table but it will not do the actual mapping. So passing the MFN in > parameter is pointless. Note that the only caller pass 0... > > At the same time replace 0 b

Re: [Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

Hi Wei, On 22/02/18 16:35, Wei Liu wrote: On Wed, Feb 21, 2018 at 02:02:51PM +, Julien Grall wrote: The function populate_pt_range is used to populate in advance the page-table but it will not do the actual mapping. So passing the MFN in parameter is pointless. Note that the only caller pas

Re: [Xen-devel] [PATCH v4 09/16] xen/pdx: Introduce helper to convert MFN <-> PDX

On Wed, Feb 21, 2018 at 02:02:52PM +, Julien Grall wrote: > This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base. > > Signed-off-by: Julien Grall > Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https:

Re: [Xen-devel] [PATCH] xen/tools: support Python 2 and Python 3

On 2/22/18 6:54 AM, Andrew Cooper wrote: > On 22/02/18 05:52, Doug Goldstein wrote: >> These changes should make it possible to support modern Pythons as well >> as the oldest Python 2 still supported. >> >> Signed-off-by: Doug Goldstein > > To the overall effect, this is definitely a good thing.

Re: [Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

On Thu, Feb 22, 2018 at 04:40:04PM +, Julien Grall wrote: > Hi Wei, > > On 22/02/18 16:35, Wei Liu wrote: > > On Wed, Feb 21, 2018 at 02:02:51PM +, Julien Grall wrote: > > > The function populate_pt_range is used to populate in advance the > > > page-table but it will not do the actual map

[Xen-devel] [PATCH 0/5] xen/tools: sched: Credit1: improve handling of vCPU migration delay

Hi, vCPU migration delay is a parameter of the Credit1 scheduler specifying for how long, after a vCPU stopped running on a particular pCPU, the cache(s) should be considered "hot" for the vCPU's working set. Basically, if less than the value set for such parameter (in microseconds) passed, the v

[Xen-devel] [PATCH 3/5] tools: libxl/xl: allow to get/set Credit1's vcpu_migration_delay

Make it possible to get and set a (Credit1) scheduler's vCPU migration delay via the SCHEDOP sysctl, from both libxl and xl (no change needed in libxc). Signed-off-by: Dario Faggioli --- Cc: Ian Jackson Cc: Wei Liu Cc: George Dunlap Cc: Andrew Cooper --- docs/man/xl.pod.1.in| 11 ++

Re: [Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

Hi Wei, On 22/02/18 16:51, Wei Liu wrote: On Thu, Feb 22, 2018 at 04:40:04PM +, Julien Grall wrote: Hi Wei, On 22/02/18 16:35, Wei Liu wrote: On Wed, Feb 21, 2018 at 02:02:51PM +, Julien Grall wrote: The function populate_pt_range is used to populate in advance the page-table but it

[Xen-devel] [PATCH 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

Now that it is possible to get and set the migration delay via the SCHEDOP sysctl, use that in xenpm, instead of the special purpose libxc interface (which will be removed in a following commit). The sysctl, however, requires a cpupool-id argument, for knowing on which scheduler it is operating on

[Xen-devel] [PATCH 2/5] xen: sched/credit1: make vcpu_migration_delay per-cpupool

Right now, vCPU migration delay is controlled by the vcpu_migration_delay boot parameter. This means the same value will always be used for every instance of Credit1, in any cpupool that will be created. Also, in order to get and set such value, a special purpose libxc interface is defined, and us

[Xen-devel] [PATCH 5/5] xen/libxc: suppress direct access to Credit1's migration delay

Removes special purpose access to Credit1 vCPU migration delay parameter. This fixes a build breakage, occuring when Xen is configured with SCHED_CREDIT=n. Signed-off-by: Dario Faggioli --- Ian Jackson Wei Liu Andrew Cooper George Dunlap Jan Beulich Konrad Rzeszutek Wilk Stefano Stabellini

[Xen-devel] [PATCH 1/5] xen: sched/credit: convert scheduling parameter to s_time_t when set

Basically, instead of converting integers to s_time_t at usage time (hot paths), do the convertion when the values are set (cold paths). This applies to the timeslice and the ratelimit parameters of Credit1. Note that, when changing the type of the fields of struct csched_private (from unsigned t

Re: [Xen-devel] [PATCH v2] xen: append EXTRA_CFLAGS_XEN_CORE to CFLAGS

On Wed, Feb 21, 2018 at 11:48:16PM -0600, Doug Goldstein wrote: > Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS_XEN_CORE > environment variable for hypervisor builds. This is not a > configuration that is supported but is only aimed to help support > testing and troubleshooting when you

Re: [Xen-devel] [PATCH v2] xen: append EXTRA_CFLAGS_XEN_CORE to CFLAGS

On Wed, Feb 21, 2018 at 11:48:16PM -0600, Doug Goldstein wrote: > Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS_XEN_CORE > environment variable for hypervisor builds. This is not a > configuration that is supported but is only aimed to help support > testing and troubleshooting when you

Re: [Xen-devel] [PATCH] xen/tools: support Python 2 and Python 3

On Thu, Feb 22, 2018 at 10:47:27AM -0600, Doug Goldstein wrote: > On 2/22/18 6:54 AM, Andrew Cooper wrote: > > On 22/02/18 05:52, Doug Goldstein wrote: > >> These changes should make it possible to support modern Pythons as well > >> as the oldest Python 2 still supported. > >> > >> Signed-off-by:

Re: [Xen-devel] [PATCH] xen/tools: support Python 2 and Python 3

On 22/02/18 16:47, Doug Goldstein wrote: > On 2/22/18 6:54 AM, Andrew Cooper wrote: >> On 22/02/18 05:52, Doug Goldstein wrote: >>> These changes should make it possible to support modern Pythons as well >>> as the oldest Python 2 still supported. >>> >>> Signed-off-by: Doug Goldstein >> To the ov

[Xen-devel] [PATCH] grant: Release domain lock on 'map' path in cache_flush

common/grant_table.c:cache_flush() grabs the rcu lock for the current domain, but only releases it on error paths. Note that this is not a security issue, as the preempt count is used exclusively for assertions at the moment. Signed-off-by: George Dunlap Reviewed-by: Jan Beulich --- CC: Ian Jac

Re: [Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

On Thu, Feb 22, 2018 at 04:55:10PM +, Julien Grall wrote: > Hi Wei, > > On 22/02/18 16:51, Wei Liu wrote: > > On Thu, Feb 22, 2018 at 04:40:04PM +, Julien Grall wrote: > > > Hi Wei, > > > > > > On 22/02/18 16:35, Wei Liu wrote: > > > > On Wed, Feb 21, 2018 at 02:02:51PM +, Julien Gral

[Xen-devel] [PATCH] xen/pvcalls: fix null pointer dereference on map->sock

From: Colin Ian King Currently if map is null then a potential null pointer deference occurs when calling sock_release on map->sock. I believe the actual intention was to call sock_release on sock instead. Fix this. Fixes: 5db4d286a8ef ("xen/pvcalls: implement connect command") Signed-off-by: C

Re: [Xen-devel] [PATCH] tools/xenstore: try to get minimum thread stack size for watch thread

On Thu, Feb 22, 2018 at 02:53:35PM +0100, Juergen Gross wrote: > When creating a pthread in xs_watch() try to get the minimal needed > size of the thread from glibc instead of using a constant. This avoids > problems when the library is used in programs with large per-thread > memory. > > Use dlsy

Re: [Xen-devel] [PATCH 5/5] xen/libxc: suppress direct access to Credit1's migration delay

On Thu, Feb 22, 2018 at 05:55:32PM +0100, Dario Faggioli wrote: > Removes special purpose access to Credit1 vCPU > migration delay parameter. > > This fixes a build breakage, occuring when Xen > is configured with SCHED_CREDIT=n. > > Signed-off-by: Dario Faggioli > --- > Ian Jackson > Wei Liu

Re: [Xen-devel] [PATCH 5/5] xen/libxc: suppress direct access to Credit1's migration delay

On Thu, Feb 22, 2018 at 05:30:28PM +, Wei Liu wrote: > On Thu, Feb 22, 2018 at 05:55:32PM +0100, Dario Faggioli wrote: > > Removes special purpose access to Credit1 vCPU > > migration delay parameter. > > > > This fixes a build breakage, occuring when Xen > > is configured with SCHED_CREDIT=n.

[Xen-devel] [linux-next test] 119805: regressions - FAIL

flight 119805 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/119805/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 19 leak-check/check fail REGR. vs. 119687 test-armhf-armhf-xl-

Re: [Xen-devel] [PATCH 5/5] xen/libxc: suppress direct access to Credit1's migration delay

On Thu, 2018-02-22 at 17:30 +, Wei Liu wrote: > On Thu, Feb 22, 2018 at 05:55:32PM +0100, Dario Faggioli wrote: > > Removes special purpose access to Credit1 vCPU > > migration delay parameter. > > > > This fixes a build breakage, occuring when Xen > > is configured with SCHED_CREDIT=n. > > >

Re: [Xen-devel] [PATCH 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

On Thu, Feb 22, 2018 at 05:55:25PM +0100, Dario Faggioli wrote: > Now that it is possible to get and set the migration > delay via the SCHEDOP sysctl, use that in xenpm, instead > of the special purpose libxc interface (which will be > removed in a following commit). > > The sysctl, however, requi

Re: [Xen-devel] [PATCH 3/5] tools: libxl/xl: allow to get/set Credit1's vcpu_migration_delay

On Thu, Feb 22, 2018 at 05:55:17PM +0100, Dario Faggioli wrote: > Make it possible to get and set a (Credit1) scheduler's > vCPU migration delay via the SCHEDOP sysctl, from both > libxl and xl (no change needed in libxc). > > Signed-off-by: Dario Faggioli Acked-by: Wei Liu ___

Re: [Xen-devel] [PATCH 5/5] xen/libxc: suppress direct access to Credit1's migration delay

On Thu, Feb 22, 2018 at 05:30:28PM +, Wei Liu wrote: > On Thu, Feb 22, 2018 at 05:55:32PM +0100, Dario Faggioli wrote: > > Removes special purpose access to Credit1 vCPU > > migration delay parameter. > > > > This fixes a build breakage, occuring when Xen > > is configured with SCHED_CREDIT=n.

Re: [Xen-devel] RTDS with extra time issue

On Tue, 2018-02-20 at 13:34 +0200, Andrii Anisov wrote: > Hello Dario, > Hi, > On 16.02.18 20:37, Dario Faggioli wrote: > > And in any case, is it, in its turn (I mean the > > workload running in DomR) a synthetic real-time load, or is it a > > real > > real-time application? > > Real-time domai

Re: [Xen-devel] [xen-devel] [fuzz] [x86 emulator] Input size

On Thu, Feb 22, 2018 at 01:39:01PM +0100, Paul Semel wrote: > Hello, > > > In the x86 instruction emulator fuzzer, when checking wether the input size > is correct, we are checking for this bounds : DATA_OFFSET < size < > INPUT_SIZE. > > > The fact is that INPUT_SIZE is actually the size of the

Re: [Xen-devel] [RFC Patch v4 3/8] xl/acpi: unify the computation of lapic_id

On Wed, Dec 06, 2017 at 03:50:09PM +0800, Chao Gao wrote: > There were two places where the lapic_id is computed, one in hvmloader and one > in libacpi. Unify them by defining LAPIC_ID in a header file and incluing it > in both places. > > To address compilation issue and make libacpi.h self-conta

Re: [Xen-devel] [RFC Patch v4 4/8] hvmloader: boot cpu through broadcast

On Wed, Dec 06, 2017 at 03:50:10PM +0800, Chao Gao wrote: > Intel SDM Extended XAPIC (X2APIC) -> "Initialization by System Software" > has the following description: > > "The ACPI interfaces for the x2APIC are described in Section 5.2, “ACPI System > Description Tables,” of the Advanced Configurat

Re: [Xen-devel] [PATCH] tools/xenstore: try to get minimum thread stack size for watch thread

On 22/02/18 18:28, Wei Liu wrote: > On Thu, Feb 22, 2018 at 02:53:35PM +0100, Juergen Gross wrote: >> When creating a pthread in xs_watch() try to get the minimal needed >> size of the thread from glibc instead of using a constant. This avoids >> problems when the library is used in programs with l

[Xen-devel] Xen Project Application | Outreachy

Hi, Lars. I'm Pallavi V G, a second year undergrad majoring in CS from India. I went through the community landing page of Xen Project and found this project that I would like to contribute on- Xen on ARM: create multiple guests from device tree. I have taken a course on C during my second semeste

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote: > Signed-off-by: Chao Gao > --- > xen/include/public/hvm/hvm_info_table.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/include/public/hvm/hvm_info_table.h > b/xen/include/public/hvm/hvm_info_table.h > inde

Re: [Xen-devel] [PATCH] tools/xenstore: try to get minimum thread stack size for watch thread

On Thu, Feb 22, 2018 at 07:44:22PM +0100, Juergen Gross wrote: > On 22/02/18 18:28, Wei Liu wrote: > > On Thu, Feb 22, 2018 at 02:53:35PM +0100, Juergen Gross wrote: > >> When creating a pthread in xs_watch() try to get the minimal needed > >> size of the thread from glibc instead of using a consta

Re: [Xen-devel] [PATCH] tools/xenstore: try to get minimum thread stack size for watch thread

On Thu, Feb 22, 2018 at 06:53:28PM +, Wei Liu wrote: > On Thu, Feb 22, 2018 at 07:44:22PM +0100, Juergen Gross wrote: > > On 22/02/18 18:28, Wei Liu wrote: > > > On Thu, Feb 22, 2018 at 02:53:35PM +0100, Juergen Gross wrote: > > >> When creating a pthread in xs_watch() try to get the minimal ne

Re: [Xen-devel] [PATCH] tools/xenstore: try to get minimum thread stack size for watch thread

On 22/02/18 19:55, Wei Liu wrote: > On Thu, Feb 22, 2018 at 06:53:28PM +, Wei Liu wrote: >> On Thu, Feb 22, 2018 at 07:44:22PM +0100, Juergen Gross wrote: >>> On 22/02/18 18:28, Wei Liu wrote: On Thu, Feb 22, 2018 at 02:53:35PM +0100, Juergen Gross wrote: > When creating a pthread in x

Re: [Xen-devel] [PATCH] xen/pvcalls: fix null pointer dereference on map->sock

On 22/02/18 18:22, Colin King wrote: > From: Colin Ian King > > Currently if map is null then a potential null pointer deference > occurs when calling sock_release on map->sock. I believe the > actual intention was to call sock_release on sock instead. Fix > this. > > Fixes: 5db4d286a8ef ("xen/

  1   2   >