Re: [Xen-devel] [PATCH v2 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

On 2017/3/31 6:00, Julien Grall wrote: > > > On 30/03/2017 22:49, Stefano Stabellini wrote: >> On Thu, 30 Mar 2017, Wei Chen wrote: >>> +/* >>> + * If the SErrors option is "FORWARD", we have to prevent forwarding >>> + * serror to wrong vCPU. So before context switch, we have to use

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

On 2017/3/31 2:38, Julien Grall wrote: > > > On 30/03/17 19:32, Julien Grall wrote: >> On 30/03/17 19:28, Julien Grall wrote: >>> Hi Wei, >>> >>> On 30/03/17 10:13, Wei Chen wrote: +void synchronize_serror(void) >>> >>> Sorry for been late in the party. Looking at the way you use the >>>

Re: [Xen-devel] [PATCH v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt

> From: Gao, Chao > Sent: Wednesday, March 29, 2017 1:12 PM > > msi_msg_to_remap_entry() is buggy when the live IRTE is in posted format. It > wrongly inherits the 'im' field meaning the IRTE is in posted format but > updates all the other fields to remapping format. > > There are also two

Re: [Xen-devel] [PATCH v2 12/19] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header

On 2017/3/31 5:36, Stefano Stabellini wrote: > On Thu, 30 Mar 2017, Wei Chen wrote: >> We want to move part of SErrors checking code from hyp_error assembly code >> to a function. This new function will use this macro to distinguish the >> guest SErrors from hypervisor SErrors. So we have to move

Re: [Xen-devel] [PATCH v2 11/19] xen/arm32: Use alternative to skip the check of pending serrors

On 2017/3/31 5:29, Stefano Stabellini wrote: > On Thu, 30 Mar 2017, Julien Grall wrote: >> Hi Wei, >> >> On 30/03/17 10:13, Wei Chen wrote: >>> We have provided an option to administrator to determine how to >>> handle the SErrors. In order to skip the check of pending SError, >>> in conventional

Re: [Xen-devel] [PATCH v2 08/19] xen/arm: Introduce a command line parameter for SErrors/Aborts

Hi Julien, On 2017/3/31 1:39, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: >> In order to distinguish guest-generated SErrors from hypervisor-generated >> SErrors we have to place SError checking code in every EL1 -> EL2 paths. >> That will cause overhead on entries due to

Re: [Xen-devel] [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI

> From: Chao Gao > Sent: Wednesday, March 29, 2017 1:12 PM > > When a vCPU migrated to another pCPU, pt irqs binded to this vCPU also > needed migration. When VT-d PI is enabled, interrupt vector will be recorded > to a main memory resident data-structure and a notification whose > destination is

[Xen-devel] [qemu-mainline baseline-only test] 71127: trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71127 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71127/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm

Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

On 2017/3/31 1:20, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: >> When guest triggers async aborts, in most platform, such aborts >> will be routed to hypervisor. But we don't want the hypervisor >> to handle such aborts, so we have to route such aborts back to >> the

Re: [Xen-devel] [PATCH v11 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list

> From: Gao, Chao > Sent: Wednesday, March 29, 2017 1:12 PM > > The current VT-d PI related code may operate incorrectly in the following > scenarios: > 1. When VT-d PI is enabled, neen't migrate pirq which is using VT-d PI during neen't -> needn't > vCPU migration. Patch [1/6] solves this by

Re: [Xen-devel] [PATCH v3 3/9] x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL

> From: Zhang, Haozhong > Sent: Thursday, March 30, 2017 2:20 PM > > If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and > LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those > bits are set before SW can enable LMCE. > > Signed-off-by: Haozhong Zhang

Re: [Xen-devel] [PATCH v3 2/8] x86/hvm: introduce hvm_domain_irq macro

> From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: Wednesday, March 29, 2017 10:47 PM > > Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No > functional change. > > Signed-off-by: Roger Pau Monné Reviewed-by: Kevin Tian

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

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

Re: [Xen-devel] Legacy PCI interrupt {de}assertion count

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, March 27, 2017 4:00 PM > > >>> On 24.03.17 at 17:54, wrote: > > As I understand it, for level triggered legacy PCI interrupts Xen sets > > up a timer in order to perform the EOI if the guest takes too long in >

Re: [Xen-devel] [PATCH RFC 00/20] Add postcopy live migration support

On Wed, Mar 29, 2017 at 11:50:52PM +0100, Andrew Cooper wrote: > On 27/03/2017 10:06, Joshua Otto wrote: > > Hi, > > > > We're a team of three fourth-year undergraduate software engineering > > students at > > the University of Waterloo in Canada. In late 2015 we posted on the list > > [1] to >

[Xen-devel] Outreachy project - Xen Code Review Dashboard

Hi, I am Vaishnavi, interested in contributing to the Xen Project as part of the Outreachy Program. I am particularly interested in working on the Xen Code Review Dashboard. I have worked on the ElasticSearch - Logstash- Kibana (ELK) stack previously and am comfortable with Javascript. It would

[Xen-devel] [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

In preparation for making the clockevents core NTP correction aware, all clockevent device drivers must set ->min_delta_ticks and ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a clockevent device's rate is going to change dynamically and thus, the ratio of ns to ticks ceases to

Re: [Xen-devel] [RFC PATCH 4/4] msi: taking interrupt format into consideration during judging a pirq is binded with a event channel

On Thu, Mar 30, 2017 at 06:29:29PM +0100, Anthony PERARD wrote: >On Fri, Mar 17, 2017 at 07:29:17PM +0800, Lan Tianyu wrote: >> From: Chao Gao >> Subject: msi: taking interrupt format into consideration during >> judging a pirq is binded with a event channel > >This is quite a

Re: [Xen-devel] [RFC PATCH 3/4] xen-pt: bind/unbind interrupt remapping format MSI

On Thu, Mar 30, 2017 at 05:51:45PM +0100, Anthony PERARD wrote: >On Fri, Mar 17, 2017 at 07:29:16PM +0800, Lan Tianyu wrote: >> From: Chao Gao >> >> If a vIOMMU is exposed to guest, guest will configure the msi to remapping >> format. The original code isn't suitable to the

Re: [Xen-devel] [PATCH v2 01/19] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check

Hi Julien On 2017/3/30 21:31, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: >> Xen will do exception syndrome check while some types of exception >> take place in EL2. The syndrome check code read the ESR_EL2 register >> directly, but in some situation this register maybe

Re: [Xen-devel] [RFC PATCH 2/4] Xen: add a dummy vIOMMU to create/destroy vIOMMU in Xen

On Thu, Mar 30, 2017 at 05:24:52PM +0100, Anthony PERARD wrote: >Hi, > >On Fri, Mar 17, 2017 at 07:29:15PM +0800, Lan Tianyu wrote: >> From: Chao Gao >> >> Since adding a dynamic sysbus device is forbidden, so choose TYPE_DEVICE >> as parent class. >> >> Signed-off-by: Chao

Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu operations in libxc

On Wed, Mar 29, 2017 at 09:08:06AM +, Paul Durrant wrote: >> -Original Message- >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of >> Chao Gao >> Sent: 29 March 2017 01:40 >> To: Wei Liu >> Cc: Lan Tianyu ; Kevin Tian

Re: [Xen-devel] [PATCH v3 1/9] x86/mce: handle LMCE locally

On 03/30/17 08:35 -0600, Jan Beulich wrote: > >>> On 30.03.17 at 08:19, wrote: > > --- a/xen/arch/x86/cpu/mcheck/mce.c > > +++ b/xen/arch/x86/cpu/mcheck/mce.c > > @@ -42,6 +42,13 @@ DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, > > poll_bankmask); > >

Re: [Xen-devel] [PATCH v3] xen/arm32: Introduce alternative runtime patching

Hi Julien, On 2017/3/30 20:55, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:02, Wei Chen wrote: >> +/* Unconditional branch instructions */ >> +/* >> + * From ARM DDI 0406C.c Section A8.8.25. We can see blx has a H bit. >> + * In an ARM/Thumb instructions mixed running environment, this bit

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

flight 107005 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107005/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 106959 Regressions which

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

Hi Julien and Stefano, On 2017/3/31 6:03, Stefano Stabellini wrote: > On Thu, 30 Mar 2017, Julien Grall wrote: >> Hi Wei, >> >> On 30/03/17 10:13, Wei Chen wrote: >>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >>> index de59e5f..8af223e 100644 >>> ---

[Xen-devel] [xen-4.8-testing baseline-only test] 71125: tolerable trouble: blocked/broken/fail/pass

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

[Xen-devel] [ovmf baseline-only test] 71126: regressions - FAIL

This run is configured for baseline tests only. flight 71126 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71126/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7

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

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

[Xen-devel] [PATCH] xl: Add 'pvh' config option

In addition to 'device_model_version="none"' config option users can also use 'pvh=1' in xl configuration file when creating a PVH guest. We can skip parsing options related to device model once we establish that we are building PVH guest. Also process 'device_model_version="none"' for HVM

[Xen-devel] [PATCH v2 2/2] ACPICA: IORT: Add in support for the SMMUv3 subtable

From: Al Stone ACPICA commit 9f7c3e148f440049615e2791d73b292f65692d7e The most recent version of the IORT specification adds in a definition for a subtable to describe SMMUv3 devices; there is already a subtable for SMMUv1/v2 devices. Add in the definition of the subtable, add

[Xen-devel] [PATCH v2 0/2] Support for IORT table

This patch set adds definitions for IORT ACPI table. The header file definitions are ported from Linux Kernel source. Al Stone (1): ACPICA: IORT: Add in support for the SMMUv3 subtable Lv Zheng (1): ACPICA: ACPI 6.0: Add support for IORT table. xen/include/acpi/actbl2.h | 144

[Xen-devel] [PATCH v2 1/2] ACPICA: ACPI 6.0: Add support for IORT table.

From: Lv Zheng ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca This patch adds support for IORT (IO Remapping Table) in iasl. Note that some field names are modified to shrink their length or the decompiled IORT ASL will contain fields with ugly ":" alignment. The

Re: [Xen-devel] [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

On 03/30/2017 04:06 PM, Nicolai Stange wrote: > In preparation for making the clockevents core NTP correction aware, > all clockevent device drivers must set ->min_delta_ticks and > ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a > clockevent device's rate is going to change

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

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

[Xen-devel] [linux-linus test] 106998: regressions - FAIL

flight 106998 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106998/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 11 guest-start fail REGR. vs. 59254

[Xen-devel] [PATCH] setup vwfi correctly on cpu0

parse_vwfi runs after init_traps on cpu0, potentially resulting in the wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their case init_traps will write the correct set of flags to HCR_EL2. For cpu0, fix the issue by changing HCR_EL2 setting directly in parse_vwfi.

Re: [Xen-devel] [PATCH v2 02/19] xen/arm: Remove vwfi while setting HCR_EL2 in init_traps

On Thu, 30 Mar 2017, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: > > We will set HCR_EL2 for each domain individually at the place where each > > domain is created. vwfi will affect the behavior of VM trap. Initialize > > the HCR_EL2 in init_traps is a generic setting for

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

On Thu, 30 Mar 2017, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > > index de59e5f..8af223e 100644 > > --- a/xen/arch/arm/domain_build.c > > +++ b/xen/arch/arm/domain_build.c > > @@ -2171,6

Re: [Xen-devel] [PATCH v2 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

On 30/03/2017 22:49, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Wei Chen wrote: +/* + * If the SErrors option is "FORWARD", we have to prevent forwarding + * serror to wrong vCPU. So before context switch, we have to use the + * synchronize_serror to guarantee that the

Re: [Xen-devel] [PATCH v2 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

On Thu, 30 Mar 2017, Wei Chen wrote: > If there is a pending SError while we are doing context switch, if the > SError handle option is "FORWARD", We have to guranatee this serror to > be caught by current vCPU, otherwise it will be caught by next vCPU and > be forwarded to this wrong vCPU. > >

Re: [Xen-devel] [PATCH v2 12/19] xen/arm: Move macro VABORT_GEN_BY_GUEST to common header

On Thu, 30 Mar 2017, Wei Chen wrote: > We want to move part of SErrors checking code from hyp_error assembly code > to a function. This new function will use this macro to distinguish the > guest SErrors from hypervisor SErrors. So we have to move this macro to > common header. > > The

Re: [Xen-devel] [PATCH v2 11/19] xen/arm32: Use alternative to skip the check of pending serrors

On Thu, 30 Mar 2017, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: > > We have provided an option to administrator to determine how to > > handle the SErrors. In order to skip the check of pending SError, > > in conventional way, we have to read the option every time before

Re: [Xen-devel] [PATCH v2 09/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

On Thu, 30 Mar 2017, Julien Grall wrote: > On 30/03/17 10:13, Wei Chen wrote: > > In the later patches of this series, we want to use the alternative > > patching framework to avoid checking serror_op in every entries. > > So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for > >

Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

On Thu, 30 Mar 2017, Julien Grall wrote: > Hi Wei, > > On 30/03/17 10:13, Wei Chen wrote: > > When guest triggers async aborts, in most platform, such aborts > > will be routed to hypervisor. But we don't want the hypervisor > > to handle such aborts, so we have to route such aborts back to > >

Re: [Xen-devel] [PATCH v2 05/19] xen/arm: Avoid setting/clearing HCR_RW at every context switch

On Thu, 30 Mar 2017, Wei Chen wrote: > The HCR_EL2 flags for 64-bit and 32-bit domains are different. But > when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of > DomU in vcpu_initialise, we didn't know the domain's address size > information. We had to use compatible flags to

[Xen-devel] [PATCH v7 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

This patch introduces macros, structs and functions to handle rings in the format described by docs/misc/pvcalls.markdown and docs/misc/9pfs.markdown. The index page (struct __name##_data_intf) contains the indexes and the grant refs to setup two rings. Indexes page

[Xen-devel] [PATCH v7 2/4] xen: introduce a C99 headers check

Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h and pvcalls.h. In addition to the usual -include stdint.h, also add -include string.h to the C99 check to get the declaration of memcpy and size_t. For the same reason, also add -include cstring to the C++ check when

[Xen-devel] [PATCH v7 4/4] Introduce the pvcalls header

Define the ring and request and response structs according to the specification. Use the new DEFINE_XEN_FLEX_RING macro. Add the header to the C99 check. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: konrad.w...@oracle.com --- xen/include/Makefile | 3 ++- 1

[Xen-devel] [PATCH v7 3/4] Introduce the Xen 9pfs transport header

Define the ring according to the protocol specification, using the new DEFINE_XEN_FLEX_RING_AND_INTF macro. Add the header to the C99 check. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: konrad.w...@oracle.com --- xen/include/Makefile | 4 +++-

[Xen-devel] [PATCH v7 0/4] new ring macros, 9pfs and pvcalls headers

Hi all, this patch series introduces a set of new ring macros to support rings in the formats specified by the Xen 9pfs transport and PV Calls protocol. It also introduces the Xen 9pfs and PV Calls protocols headers. Changes in v7: - code style - remove -include from prereq variable - use only

Re: [Xen-devel] [PATCH v6 3/4] Introduce the Xen 9pfs transport header

On Thu, 30 Mar 2017, Jan Beulich wrote: > >>> On 30.03.17 at 00:18, wrote: > > --- a/xen/include/Makefile > > +++ b/xen/include/Makefile > > @@ -94,9 +94,12 @@ all: headers.chk headers99.chk headers++.chk > > > > PUBLIC_HEADERS := $(filter-out public/arch-%

Re: [Xen-devel] [PATCH v6 2/4] xen: introduce a C99 headers check

On Thu, 30 Mar 2017, Jan Beulich wrote: > >>> On 30.03.17 at 00:18, wrote: > > @@ -104,16 +105,22 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile > > done >$@.new > > mv $@.new $@ > > > > +headers99.chk: $(PUBLIC_C99_HEADERS) Makefile > > + rm -f $@.new $@ > >

Re: [Xen-devel] [PATCH v6 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

On Thu, 30 Mar 2017, Jan Beulich wrote: > >>> On 30.03.17 at 00:18, wrote: > > +static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size) > >\ > > +{ > >\ > > +return

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Lets make it clear - there must be one translation table for EL0 apps... On Mar 30, 2017 23:18, Volodymyr Babchuk wrote: Hi Julien, On 30 March 2017 at 22:57, Julien Grall wrote: > Hi Volodymyr > > On 30/03/2017 20:19, Volodymyr Babchuk wrote: >>

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hi Julien, On 30 March 2017 at 22:57, Julien Grall wrote: > Hi Volodymyr > > On 30/03/2017 20:19, Volodymyr Babchuk wrote: >> >> On 30 March 2017 at 21:52, Stefano Stabellini >> wrote: >>> >>> On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: >> >>

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hi Volodymyr On 30/03/2017 20:19, Volodymyr Babchuk wrote: On 30 March 2017 at 21:52, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: And yes, my profiler shows that there are ways to further decrease latency. Most obvious way is to get rid of

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hi Volodymyr On 30/03/2017 20:19, Volodymyr Babchuk wrote: On 30 March 2017 at 21:52, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: And yes, my profiler shows that there are ways to further decrease latency. Most obvious way is to get rid of

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

Hi Stefano, On 30/03/2017 19:55, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Julien Grall wrote: Hi Stefano, On 30/03/17 19:37, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Julien Grall wrote: +/* + * When using ACPI, most of the MMIO regions will be mapped on-demand + * in stage-2

[Xen-devel] [RFC PATCH v3 1/2] xen: credit2: enable per cpu runqueue creation

The patch introduces a new command line option 'cpu' that when used will create runqueue per logical pCPU. Signed-off-by: Praveen Kumar --- docs/misc/xen-command-line.markdown | 3 ++- xen/common/sched_credit2.c | 15 +++ 2 files changed, 13

[Xen-devel] [RFC PATCH v3 2/2] xen: credit2: provide custom option to create

The patch introduces a new command line option 'custom' that when used will create runqueue based upon the pCPU subset provide during bootup. Signed-off-by: Praveen Kumar --- docs/misc/xen-command-line.markdown | 8 +- xen/common/sched_credit2.c | 170

[Xen-devel] [RFC PATCH v3 0/2] xen: credit2: flexible configuration for runqueues

Hello, The idea is to give user more flexibility to configure runqueue further. For most workloads and in most systems, using per-core means have too many small runqueues. Using per-socket is almost always better, but it may result in too few big runqueues. OPTION 1 : The user can

[Xen-devel] [PATCH v2 2/2] xen: credit2: provide custom option to create

The patch introduces a new command line option 'custom' that when used will create runqueue based upon the pCPU subset provide during bootup. Signed-off-by: Praveen Kumar --- docs/misc/xen-command-line.markdown | 8 +- xen/common/sched_credit2.c | 170

[Xen-devel] [PATCH v2 1/2] xen: credit2: enable per cpu runqueue creation

The patch introduces a new command line option 'cpu' that when used will create runqueue per logical pCPU. Signed-off-by: Praveen Kumar --- docs/misc/xen-command-line.markdown | 3 ++- xen/common/sched_credit2.c | 15 +++ 2 files changed, 13

[Xen-devel] [PATCH v2 0/2] xen: credit2: flexible configuration for runqueues

Hello, The idea is to give user more flexibility to configure runqueue further. For most workloads and in most systems, using per-core means have too many small runqueues. Using per-socket is almost always better, but it may result in too few big runqueues. OPTION 1 : The user can

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hi Stefano, On 30 March 2017 at 21:52, Stefano Stabellini wrote: > On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: >> Hi Julien, >> >> 5pm UTC+1 will be fine for me. >> >> I just finished my EL0 PoC and want to share benchmark results. >> >> My benchmark setup is primitive,

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

On Thu, 30 Mar 2017, Julien Grall wrote: > Hi Stefano, > > On 30/03/17 19:37, Stefano Stabellini wrote: > > On Thu, 30 Mar 2017, Julien Grall wrote: > > > +/* > > > + * When using ACPI, most of the MMIO regions will be mapped on-demand > > > + * in stage-2 page tables for the hardware domain

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: > Hi Julien, > > 5pm UTC+1 will be fine for me. > > I just finished my EL0 PoC and want to share benchmark results. > > My benchmark setup is primitive, but results are reproducible. I have > wrote small driver that calls SMC 10.000.000 times in a

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

Hi Stefano, On 30/03/17 19:37, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Julien Grall wrote: +/* + * When using ACPI, most of the MMIO regions will be mapped on-demand + * in stage-2 page tables for the hardware domain because Xen is not + * able to know from the EFI memory map the MMIO

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

On 30/03/17 19:32, Julien Grall wrote: On 30/03/17 19:28, Julien Grall wrote: Hi Wei, On 30/03/17 10:13, Wei Chen wrote: +void synchronize_serror(void) Sorry for been late in the party. Looking at the way you use the function, you execute depending on the behavior chosen by the user when

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

On Thu, 30 Mar 2017, Julien Grall wrote: > When booting using ACPI, not all MMIOs can be discovered by parsing the > static tables or the UEFI memory map. A lot of them will be described in > the DSDT. However, Xen does not have an AML parser which requires us to > find a different approach. > >

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

On 30/03/17 19:28, Julien Grall wrote: Hi Wei, On 30/03/17 10:13, Wei Chen wrote: +void synchronize_serror(void) Sorry for been late in the party. Looking at the way you use the function, you execute depending on the behavior chosen by the user when an SErrors happen. This behavior will not

Re: [Xen-devel] [PATCH v2 16/19] xen/arm: Introduce a helper to synchronize SError

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: +void synchronize_serror(void) Sorry for been late in the party. Looking at the way you use the function, you execute depending on the behavior chosen by the user when an SErrors happen. This behavior will not change at runtime, so always checking

Re: [Xen-devel] Xen 4.9 Development Update

Hi, all On Tue, Mar 28, 2017 at 5:20 PM, Julien Grall wrote: > This email only tracks big items for xen.git tree. Please reply for items you > woulk like to see in 4.9 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to provide

Re: [Xen-devel] [PATCH] docs/misc: document PV control/feature keys for laptop/slate mode

On Thu, 30 Mar 2017, Paul Durrant wrote: > On 30 March 2017, at 18:49, Stefano Stabellini wrote: > >On Thu, 30 Mar 2017, Paul Durrant wrote: > >> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch" > >> added code to provide an 'laptop/slate mode' ACPI

Re: [Xen-devel] [GSoC] Xen on ARM: create multiple guests from device tree

Hi Stefano, sorry if i am so late but my schedule was full this week. I am currently preparing a presentation for an event here in Italy and i had no time to check even my emails. > Il giorno 29 mar 2017, alle ore 02:13, Stefano Stabellini > ha scritto: > > On Tue, 28

Re: [Xen-devel] [PATCH v2 11/19] xen/arm32: Use alternative to skip the check of pending serrors

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: We have provided an option to administrator to determine how to handle the SErrors. In order to skip the check of pending SError, in conventional way, we have to read the option every time before we try to check the pending SError. This will add

Re: [Xen-devel] [PATCH] docs/misc: document PV control/feature keys for laptop/slate mode

On 30 March 2017, at 18:49, Stefano Stabellini wrote: > > >On Thu, 30 Mar 2017, Paul Durrant wrote: >> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch" >> added code to provide an 'laptop/slate mode' ACPI device to guests. >> >> When present this

Re: [Xen-devel] [PATCH v2 09/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

On 30/03/17 10:13, Wei Chen wrote: In the later patches of this series, we want to use the alternative patching framework to avoid checking serror_op in every entries. So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for serror_op. When serror_op is not equal to SERROR_DIVERSE, this

[Xen-devel] [xen-unstable-smoke test] 107006: tolerable trouble: broken/fail/pass - PUSHED

flight 107006 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107006/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

Re: [Xen-devel] [GSoC]about the task "Share a page in memory from the VM config file"

I think that makes perfect sense. On Thu, 30 Mar 2017, Zhongze Liu wrote: > Hi Stefano, > > What do you say if we extend this project into "sharing multiple > ranges of memory area among VMs from the config file". > > Cheers. > > Zhongze Liu > > 2017-03-30 9:07 GMT+08:00 Zhongze Liu

Re: [Xen-devel] [PATCH v2 09/19] xen/arm: Introduce a initcall to update cpu_hwcaps by serror_op

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: In the later patches of this series, we want to use the alternative patching framework to avoid checking serror_op in every entries. So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for serror_op. When serror_op is not equal to

Re: [Xen-devel] [PATCH] docs/misc: document PV control/feature keys for laptop/slate mode

On Thu, 30 Mar 2017, Paul Durrant wrote: > Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch" > added code to provide an 'laptop/slate mode' ACPI device to guests. > > When present this device is used by Microsoft Windows to bind a HID > driver which controls whether the

Re: [Xen-devel] raisin and minios stubdom

On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote: Hi, Currently the xen build system has optional support for building a minios (+needed libraries and tools) based stubdom. What is your opinion about moving support for building this into raisin and once that is stable drop support

Re: [Xen-devel] [PATCH v2 08/19] xen/arm: Introduce a command line parameter for SErrors/Aborts

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: In order to distinguish guest-generated SErrors from hypervisor-generated SErrors we have to place SError checking code in every EL1 -> EL2 paths. That will cause overhead on entries due to dsb/isb. However, not all platforms want to categorize

Re: [Xen-devel] [RFC PATCH 4/4] msi: taking interrupt format into consideration during judging a pirq is binded with a event channel

On Fri, Mar 17, 2017 at 07:29:17PM +0800, Lan Tianyu wrote: > From: Chao Gao > Subject: msi: taking interrupt format into consideration during > judging a pirq is binded with a event channel This is quite a long title, I think we can make it shorter. Maybe "msi: Handle MSI

Re: [Xen-devel] [PATCH v2 07/19] xen/arm: Introduce a virtual abort injection helper

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: When guest triggers async aborts, in most platform, such aborts will be routed to hypervisor. But we don't want the hypervisor to handle such aborts, so we have to route such aborts back to the guest. This helper is using the HCR_EL2.VSE (HCR.VA for

Re: [Xen-devel] [PATCH v2 05/19] xen/arm: Avoid setting/clearing HCR_RW at every context switch

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: The HCR_EL2 flags for 64-bit and 32-bit domains are different. But when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of DomU in vcpu_initialise, we didn't know the domain's address size information. We had to use compatible flags to

Re: [Xen-devel] [PATCH v2] x86/emul: Poision the stubs with debug traps

On 30/03/17 13:08, Jan Beulich wrote: On 30.03.17 at 13:56, wrote: >> On 20/03/17 11:50, Jan Beulich wrote: >> On 20.03.17 at 11:58, wrote: ...rather than leaving fragments of old instructions in place. This reduces

Re: [Xen-devel] [PATCH v2 04/19] xen/arm: Restore HCR_EL2 register

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index de59e5f..8af223e 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -2171,6 +2171,13 @@ int construct_dom0(struct domain *d) return rc;

Re: [Xen-devel] 4.9.19 (and others) hang when running as a nested dom0

On 30/03/17 17:53, Juergen Gross wrote: > On 30/03/17 18:32, George Dunlap wrote: >> I normally test CentOS using nested virtualization (mainly because >> it's easy to restore the disk to a known state). At some point in the >> last six months this basically stopped working, as newer kernels (and

Re: [Xen-devel] [PATCH v2 02/19] xen/arm: Remove vwfi while setting HCR_EL2 in init_traps

Hi Wei, On 30/03/17 10:13, Wei Chen wrote: We will set HCR_EL2 for each domain individually at the place where each domain is created. vwfi will affect the behavior of VM trap. Initialize the HCR_EL2 in init_traps is a generic setting for AT translations while creating dom0. This statement

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

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

Re: [Xen-devel] 4.9.19 (and others) hang when running as a nested dom0

On 30/03/17 18:32, George Dunlap wrote: > I normally test CentOS using nested virtualization (mainly because > it's easy to restore the disk to a known state). At some point in the > last six months this basically stopped working, as newer kernels (and > even backports) stopped booting properly

Re: [Xen-devel] [RFC PATCH 3/4] xen-pt: bind/unbind interrupt remapping format MSI

On Fri, Mar 17, 2017 at 07:29:16PM +0800, Lan Tianyu wrote: > From: Chao Gao > > If a vIOMMU is exposed to guest, guest will configure the msi to remapping > format. The original code isn't suitable to the new format. A new pair > bind/unbind interfaces are added for this

Re: [Xen-devel] [PATCH v4 3/4] xenstore: rework of transaction handling

On 30/03/17 17:41, Wei Liu wrote: > On Thu, Mar 30, 2017 at 03:11:48PM +0200, Juergen Gross wrote: > [...] >> + >> +/* >> + * A node has been accessed. >> + * >> + * Modifying accesses (write, delete) always update the generation (global >> and >> + * node->generation). >> + * >> + * Accesses in

Re: [Xen-devel] [PATCH v3 6/9] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

On Thu, Mar 30, 2017 at 08:57:05AM -0600, Jan Beulich wrote: > >>> On 30.03.17 at 08:20, wrote: > > If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present > > in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP. > > By default, LMCE

[Xen-devel] [PATCH for-4.9 1/4] tools/libxc: Tolerate specific zero-content records in migration v2 streams

The migration v2 save code was written to avoid sending data records with no content, as such records serve no purpose but come with a performance hit. The restore code sanity checks this expectation. Under some circumstances (most notably, on AMD hardware with Debug Extensions, and a PV guest

[Xen-devel] [PATCH for-4.9 3/4] tools/python: Adjust migration v2 library to warn about zero-content records

These records shouldn't be in a stream, but accidentally are. Warn about them, but don't abort the verification. While here, add a missing length check to the X86_PV_P2M_FRAMES record checker. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu

[Xen-devel] [PATCH for-4.9 4/4] docs: Clarify the expected behaviour of zero-content records

The sending side shouldn't send any data records which end up having zero content, but the receiving side will need to tolerate such records for compatibility purposes. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu

  1   2   3   >