Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] > Sent: Wednesday, December 21, 2016 1:44 PM > > When Xen apicv is enabled, wall clock time is faster on Windows7-32 > guest with high payload (with 2vCPU, captured from xentrace, in > high payload, the count of IPI interrupt increases rapidly

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

sent too quick. I meant please add your tested-by here. :-) > From: Tian, Kevin > Sent: Thursday, December 22, 2016 3:48 PM > > Thanks a lot! > > > From: Gao, Chao > > Sent: Thursday, December 22, 2016 4:02 AM > > > > Hi, xuquan. > > I have tested it on my skylake server. W/o this patch the

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

Thanks a lot! > From: Gao, Chao > Sent: Thursday, December 22, 2016 4:02 AM > > Hi, xuquan. > I have tested it on my skylake server. W/o this patch the inaccurate > wall clock time issue only exists in Win7-32 guest. Win7-64, Win8-32, Win8-64, > Win10-32 ,Win10-64 and linux-4.8.0+ guests don't

Re: [Xen-devel] Xen: Support for mapping OperationRegion in ACPI ASL

>>> On 20.12.16 at 23:50, wrote: > On Tue, 20 Dec 2016, Jan Beulich wrote: >> >>> On 20.12.16 at 00:01, wrote: >> > This is actually not an ARM specific question, so changing the subject >> > and CC'ing more people. >> > >> > On Wed, 14 Dec 2016,

Re: [Xen-devel] [PATCH v15] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

Hi, Konrad! I see no comments for almost 3 weeks now, so probably there are no objections against this protocol. Can we please move on on this? Thank you in advance, Oleksandr On 12/08/2016 05:13 PM, Oleksandr Andrushchenko wrote: I'm just wondering if anybody had a chance to look at the

[Xen-devel] [PATCH 0/3] xen: fix some minor bugs and cleanup of xenbus

Do some minor bug fixes and cleanup of xenbus driver. Juergen Gross (3): xen: xenbus driver must not accept invalid transaction ids xen: return xenstore command failures via response instead of rc xen: remove stale xs_input_avail() from header drivers/xen/xenbus/xenbus_comms.h| 1

[Xen-devel] [PATCH 3/3] xen: remove stale xs_input_avail() from header

In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of xs_input_avail(). Remove it. Signed-off-by: Juergen Gross --- drivers/xen/xenbus/xenbus_comms.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/xen/xenbus/xenbus_comms.h

[Xen-devel] [PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

When accessing Xenstore in a transaction the user is specifying a transaction id which he normally obtained from Xenstore when starting the transaction. Xenstore is validating a transaction id against all known transaction ids of the connection the request came in. As all requests of a domain not

[Xen-devel] [PATCH 2/3] xen: return xenstore command failures via response instead of rc

When the xenbus driver does some special handling for a Xenstore command any error condition related to the command should be returned via an error response instead of letting the related write operation fail. Otherwise the user land handler might take wrong decisions assuming the connection to

[Xen-devel] [xen-4.6-testing baseline-only test] 68255: regressions - FAIL

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

[Xen-devel] help regarding intel board

hi, Can anybody give a list of intel based boards for automotive embedded use case in which xen could be installed?. regards, George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [linux-4.1 test] 103784: regressions - trouble: broken/fail/pass

flight 103784 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/103784/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737

[Xen-devel] [qemu-mainline test] 103785: trouble: blocked/broken/fail/pass

flight 103785 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/103785/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 3 host-install(3)broken REGR. vs.

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

Hi Chao, To me, it is sufficient.. thanks for your verification!! Quan On December 22, 2016 4:02 AM, Chao Gao wrote: >Hi, xuquan. >I have tested it on my skylake server. W/o this patch the inaccurate wall >clock time issue only exists in Win7-32 guest. Win7-64, Win8-32, Win8-64, >Win10-32

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

Hi, xuquan. I have tested it on my skylake server. W/o this patch the inaccurate wall clock time issue only exists in Win7-32 guest. Win7-64, Win8-32, Win8-64, Win10-32 ,Win10-64 and linux-4.8.0+ guests don't have this issue. W/ this v4 patch, the issue disappears in Win7-32 guest and no wall lock

[Xen-devel] [PATCH v2 2/6] tools: add init.h for tools

Start off with just __ref -- we enalbe you to override, if you do that then you can define your own. The way you'd use this, if you do override, is define your own __ref and then use include_next. Signed-off-by: Luis R. Rodriguez --- tools/include/linux/init.h | 9 +

[Xen-devel] [PATCH v2 4/6] tools: expand export.h with VMLINUX_SYMBOL()

This will be used later by the linker-table userspace sandbox. Signed-off-by: Luis R. Rodriguez --- tools/include/linux/export.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/tools/include/linux/export.h b/tools/include/linux/export.h index

[Xen-devel] [PATCH v2 0/6] tools: add linker table userspace sandbox

is the second part to the linker table work, the first part is the kernel work. I've split it up to make it easier to review. All the code is present on my linux-next 20161221-linker-tables-v5 branch on kernel.org [1], if you check that code out you can disregard the last patch as it was a debug patch

[Xen-devel] [PATCH v2 5/6] tools: add __section() to compiler.h

This will be used later by the userspace linker table. Signed-off-by: Luis R. Rodriguez --- tools/include/linux/compiler.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h index 556c991de212..6321265df00a

[Xen-devel] [PATCH v2 1/6] tools: add a userspace tools bug.h

This will be used later by the userspace linker-tables sandbox. As a convenience, include bug.h on kernel.h -- this is not done on upstream kernel.h, however most header files do include bug.h eventually, if we were to only add the ones that need it we'd need to copy a lot of headers to tools for

[Xen-devel] [PATCH v2 3/6] tools: add __used and enable to override

This adds __used, to be used later in the userspace linker-tables sandbox. If any userspace applicaiton wants to override they can add their own definition and then use include_next. This definition should probably suffice for most uses cases though. Signed-off-by: Luis R. Rodriguez

[Xen-devel] [PATCH v5 12/14] kprobes: port .kprobes.text to section range

kprobe makes use of two custom sections, each custom section is folded into one of the standard Linux sections types as follows, it currently relies on the linker script to fold the custom section onto the respective Linux section: type Linux-section custom section name begin

[Xen-devel] [PATCH v5 14/14] lib: add linker tables test driver

Add a test drivers for linker tables. v5: added this commit for the first time in this series. Signed-off-by: Luis R. Rodriguez --- lib/Kconfig.debug| 6 + lib/Makefile | 1 + lib/test_linktables/Makefile |

[Xen-devel] [PATCH v5 07/14] firmware: port built-in section to linker table

This ports built-in firmware to use linker tables, this replaces the custom section solution with a generic solution. This also demos the use of the .rodata linker table. Tested with 0 built-in firmware, 1 and 2 built-in firmwares successfully. v5: o since we dropped SECTION_ORDER_ANY, use

[Xen-devel] [PATCH v5 11/14] kprobes: move kprobe declarations to asm-generic/kprobes.h

Often all is needed is these small helpers, instead of compiler.h or a full kprobes.h. This is important for asm helpers, in fact even some asm/kprobes.h make use of these helpers... instead just keep a generic asm file with helpers useful for asm code with the least amount of clutter as possible.

[Xen-devel] [PATCH v5 10/14] dynamic_debug: port to use linker tables

This removes the custom vmlinux.lds.h hacks and uses the generalized solution for .data entries. There is much more potential for further fine tuning here in the future though. For instance, linker tables enable an extra postfix for order level annotations, this could easily be used as the

[Xen-devel] [PATCH v5 08/14] jump_label: move guard #endif down where it belongs

The ending header guard is misplaced. This has no functional change, this is just an eye-sore. Signed-off-by: Luis R. Rodriguez --- include/linux/jump_label.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/jump_label.h

[Xen-devel] [PATCH v5 09/14] jump_label: port __jump_table to linker tables

Move the __jump_table from the a custom section solution to a generic solution, this avoiding extra vmlinux.lds.h customizations. This also demos the use of the .data linker table and of the shared asm call push_section_tbl(). Built-in kernel functionality was tested with

[Xen-devel] [PATCH v5 13/14] kprobes: port blacklist kprobes to linker table

kprobe makes use of two sections, the one dealing with the actual kprobes was recently ported using the standard section range API. The blacklist functionality of kprobes is still using a custom section and declaring its custom section using the linker script as follows: type Linux-section

[Xen-devel] [PATCH v5 06/14] firmware/Makefile: force recompilation if makefile changes

If you modify the target asm we currently do not force the recompilation of the firmware files. The target asm is in the firmware/Makefile, peg this file as a dependency to require re-compilation of firmware targets when the asm changes. v3: introduced in this series Signed-off-by: Luis R.

[Xen-devel] [PATCH v5 05/14] kbuild: enable option to force compile force-obj-y and force-lib-y

Linux provides a rich array of features, enabling each feature however increases the size of the kernel and there are many features which users often want disabled. The traditional solution to this problem is for each feature to have its own Kconfig symbol, followed by a series of #ifdef

[Xen-devel] [PATCH v5 03/14] ranges.h: add helpers to build and identify Linux section ranges

Section ranges are on one of the types of custom sections types used in Linux. This provides a series of helpers for defining them and using them. Most importantly this also enables us to avoid modifying the linker script when we add a new section range. It turns out a lot of custom sections are

[Xen-devel] [PATCH v5 04/14] tables.h: add linker table support

A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications, per architecture. This adds a general linker

[Xen-devel] [PATCH v5 01/14] generic-sections: add section core helpers

Linux makes extensive use of custom ELF header sections, documentation for these are well scatterred. Unify this documentation in a central place and provide helpers to build custom Linux sections. This also generalizes sections code to enable avoiding modifying the linker scripts when we want to

[Xen-devel] [PATCH v5 02/14] xtensa: skip adding literal when SORT() is used

When SORT(foo.*) is used the current sed replacements add SORT(foo.literal foo.*), this breaks linking. Avoid adding literals for SORT globs, if needed, these need to be added manually. Signed-off-by: Luis R. Rodriguez --- arch/xtensa/kernel/Makefile | 8 1 file

[Xen-devel] [PATCH v5 00/14] linux: generalize sections, ranges and linker tables

(this) is for the kernel work, the second set is for the tools/ userspace sandbox. If you would like to review all the changes in git form you can yank them off of my linux-next 20161221-linker-tables-v5 branch on kernel.org [3], please however note that the last patch on that tree was *not* submitted upstream

[Xen-devel] [PATCH v2 2/4] arm: store vcpu id in struct irq_pending

We currently store the LR register number for every irq in irq_pending, but we don't store the vcpu id. Thus, we know in which LR they are, but we don't know the LR of which cpu. Fix this gap by adding a vcpu field in struct pending_irq. Use the bytes that are currently used for padding within the

[Xen-devel] [PATCH v2 4/4] The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr.

gic_update_one_lr is called with the vgic lock held, but it calls vgic_get_target_vcpu, which tries to obtain the rank lock. This can cause deadlocks. We already have a version of vgic_get_target_vcpu that doesn't take the rank lock: __vgic_get_target_vcpu. Solve the lock inversion problem, by

[Xen-devel] [PATCH v2 3/4] arm, vgic_migrate_irq: take the right vgic lock

Always take the vgic lock of the old vcpu. When more than one irq migration is requested before the first one completes, take the vgic lock of the oldest vcpu. Write the new vcpu id into the rank from vgic_migrate_irq, protected by the oldest vgic vcpu lock. Use barriers to ensure proper

[Xen-devel] [PATCH v2 1/4] xen/arm: fix GIC_INVALID_LR

GIC_INVALID_LR should be 0xff, but actually, defined as ~(uint8_t)0, is 0x. Fix the problem by placing the ~ operator before the cast. Signed-off-by: Stefano Stabellini --- xen/include/asm-arm/vgic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Xen-devel] [PATCH v2 0/4] xen/arm: fix rank/vgic lock inversion bug

Hi all, this patch series fixes a lock inversion bug in Xen on ARM. The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr. gic_update_one_lr is called with the vgic lock held, but it calls vgic_get_target_vcpu, which tries to

Re: [Xen-devel] [PATCH] xen/arm: fix rank/vgic locks inversion bug

On Tue, 20 Dec 2016, Stefano Stabellini wrote: > On Tue, 20 Dec 2016, Julien Grall wrote: > > Hi Stefano, > > > > On 20/12/2016 00:22, Stefano Stabellini wrote: > > > On Mon, 19 Dec 2016, Julien Grall wrote: > > > > Hi Stefano, > > > > > > > > On 19/12/2016 23:30, Stefano Stabellini wrote: > > >

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

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

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

On Fri, Dec 16, 2016 at 12:27:31PM +0800, George Dunlap wrote: > On Fri, Dec 16, 2016 at 7:20 AM, Ronald Rojas wrote: > > Create a basic Makefile to build and install libxenlight Golang > > bindings. Also add a template. > > What's this template again? I use 'template' to

[Xen-devel] Xen Community Call on new PV protocols, 11th Jan 9AM PST

Hi all, the 4.9 development cycle is open, and we a number of new outstanding PV driver protocols on the agenda. I published a proposal on the lifecycle of PV drivers that might help speed up the process. I suggest we have a conference call to discuss how to proceed. Which PV protocol designs

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Wed, 21 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 20/12/2016 20:53, Stefano Stabellini wrote: > > On Tue, 20 Dec 2016, Julien Grall wrote: > > > On 19/12/2016 21:24, Stefano Stabellini wrote: > > > > On Mon, 19 Dec 2016, Christoffer Dall wrote: > > > > > On Fri, Dec 16, 2016 at

[Xen-devel] [xen-4.4-testing test] 103782: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 103782 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103782/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 103772 pass in 103782

Re: [Xen-devel] [PATCH v3] libacpi: Don't build x86-only AML for ARM64 mk_dsdt

On Wed, 21 Dec 2016, Boris Ostrovsky wrote: > Commit d6ac8e22c7c5 ("acpi/x86: define ACPI IO registers for > PVH guests") broke ARM64 build of mk_dsdt.c due to introduction > of XEN_ACPI_CPU_MAP[_LEN] macros that are needed only for x86 > guests. > > We could fix the build by dealing specifically

Re: [Xen-devel] [XEN KEXEC PATCH] Corrected comment typo "count not" to "could not"

On Wed, Dec 21, 2016 at 01:37:31PM -0800, Eric DeVolder wrote: > Fix cut-n-paste typo; changed the words "count not" to "could not". > > No functional changes > > Signed-off-by: Eric DeVolder Reviewed-by: Konrad Rzeszutek Wilk > > --- >

[Xen-devel] [XEN KEXEC PATCH] Corrected comment typo "count not" to "could not"

Fix cut-n-paste typo; changed the words "count not" to "could not". No functional changes Signed-off-by: Eric DeVolder --- tools/libxc/xc_kexec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxc/xc_kexec.c b/tools/libxc/xc_kexec.c

[Xen-devel] [xen-4.6-testing test] 103783: tolerable trouble: broken/fail/pass - PUSHED

flight 103783 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/103783/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-2 3 host-install(3) broken in 103753 pass in 103783

[Xen-devel] [PATCH v3] libacpi: Don't build x86-only AML for ARM64 mk_dsdt

Commit d6ac8e22c7c5 ("acpi/x86: define ACPI IO registers for PVH guests") broke ARM64 build of mk_dsdt.c due to introduction of XEN_ACPI_CPU_MAP[_LEN] macros that are needed only for x86 guests. We could fix the build by dealing specifically with those macros but since post-MADT code is not

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

Hi Stefano, On 20/12/2016 22:33, Stefano Stabellini wrote: On Tue, 20 Dec 2016, Christoffer Dall wrote: On Mon, Dec 19, 2016 at 12:24:18PM -0800, Stefano Stabellini wrote: On Mon, 19 Dec 2016, Christoffer Dall wrote: On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote: hvm_param is

Re: [Xen-devel] [PATCH v2] libacpi: Don't build x86-only AML for ARM64 mk_dsdt

On Tue, 20 Dec 2016, Boris Ostrovsky wrote: > Commit d6ac8e22c7c5 ("acpi/x86: define ACPI IO registers for > PVH guests") broke ARM64 build of mk_dsdt.c due to introduction > of XEN_ACPI_CPU_MAP[_LEN] macros that are needed only for x86 > guests. > > We could fix the build by dealing specifically

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

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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

Hi Stefano, On 20/12/2016 20:53, Stefano Stabellini wrote: On Tue, 20 Dec 2016, Julien Grall wrote: On 19/12/2016 21:24, Stefano Stabellini wrote: On Mon, 19 Dec 2016, Christoffer Dall wrote: On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote: Finally, we cannot hijack one of the

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Map mmio-sram nodes as cached memory

On Wed, 21 Dec 2016, Julien Grall wrote: > Hi Edgar, > > On 20/12/2016 13:53, Edgar E. Iglesias wrote: > > On Mon, Dec 19, 2016 at 04:01:00PM -0800, Stefano Stabellini wrote: > > > On Mon, 19 Dec 2016, Julien Grall wrote: > > > > Hi Edgar, > > > > > > > > On 16/12/2016 18:04, Edgar E. Iglesias

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

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

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

>>> On 21.12.16 at 17:32, wrote: > On Mon, Dec 12, 2016 at 06:56:36AM -0700, Jan Beulich wrote: >> >>> On 30.11.16 at 17:49, wrote: >> > +static int __init hvm_setup_acpi_madt(struct domain *d, paddr_t *addr) >> > +{ >> > +struct acpi_table_madt

Re: [Xen-devel] [PATCH] init/FreeBSD: fix incorrect usage of $rc_pids in xendriverdomain

On Wed, Dec 21, 2016 at 04:47:26PM +, Roger Pau Monne wrote: > It should be rc_pid. > > Signed-off-by: Roger Pau Monné > Reported-by: Nathan Friess Acked + applied. I suspect all the patches to fix FreeBSD init script should be backported? >

[Xen-devel] [PATCH] init/FreeBSD: fix incorrect usage of $rc_pids in xendriverdomain

It should be rc_pid. Signed-off-by: Roger Pau Monné Reported-by: Nathan Friess --- Cc: Ian Jackson Cc: Wei Liu --- tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 4 ++-- 1 file changed, 2

[Xen-devel] [PATCH 0/2] More fixes for lto option

Wei Liu (2): config/StdGNU.mk: use CONFIG_LTO INSTALL: remove stale lto build instruction INSTALL | 4 config/StdGNU.mk | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-) -- 2.1.4 ___ Xen-devel mailing list

[Xen-devel] [PATCH 2/2] build: use debug_symbols to add -g3

While doing archeology I found 38ce7ce3, we should also make sure debug_symbols is the responsible for adding "-g" to CFLAGS. Move adding "-g3" from being guarded by debug to being guarded by debug_symbols. Signed-off-by: Wei Liu --- Cc: Andrew Cooper

[Xen-devel] [PATCH 1/2] config/StdGNU.mk: use CONFIG_LTO

The lto symbol is superseded by CONFIG_LTO now. Signed-off-by: Wei Liu --- Discovered while reviewing some other patches. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan

[Xen-devel] [PATCH 1/2] build: move debug_symbols to tools/Rules.mk

31d41d7b tried to make debug affect tools build only but failed to move debug_symbols (which appends "-g" to CFLAGS) to tools/Rules.mk. Do that in this patch. Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap

[Xen-devel] [PATCH 0/2] build: minor adjustment

Wei Liu (2): build: move debug_symbols to tools/Rules.mk build: use debug_symbols to add -g3 Config.mk | 5 - tools/Rules.mk | 7 ++- 2 files changed, 6 insertions(+), 6 deletions(-) -- 2.1.4 ___ Xen-devel mailing list

[Xen-devel] [PATCH 2/2] INSTALL: remove stale lto build instruction

Signed-off-by: Wei Liu --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini

Re: [Xen-devel] [PATCH 4/4] init/FreeBSD: add rc control variables

On Wed, Dec 21, 2016 at 12:12:06PM +, Roger Pau Monne wrote: > On Wed, Dec 21, 2016 at 11:49:29AM +, Wei Liu wrote: > > On Mon, Dec 19, 2016 at 03:02:04PM +, Roger Pau Monne wrote: > > > Those are used in order to decide which scripts are executed at init. > > > > > > Signed-off-by:

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

On Mon, Dec 12, 2016 at 06:56:36AM -0700, Jan Beulich wrote: > >>> On 30.11.16 at 17:49, wrote: > > @@ -567,7 +573,7 @@ static __init void hvm_setup_e820(struct domain *d, > > unsigned long nr_pages) > > /* > > * Craft the e820 memory map for Dom0 based on the

[Xen-devel] [PATCH 1/2] x86/emul: Correct the return value handling of VMFUNC

The bracketing of x86_emulate() calling the ops->vmfunc() hook is wrong with respect to the assignment to rc, which can trip the new assertions in x86_emulate_wrapper(). The hvmemul_vmfunc() hook should only raise #UD if X86EMUL_EXCEPTION is returned. This is only a latent bug at the moment.

[Xen-devel] [PATCH 2/2] x86/emul: Pass shadow register state to the vmfunc() hook

vmfunc can in principle modify register state, so should operate on the shadow register state rather than the starting state of emulation. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Paul Durrant ---

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

On 21/12/2016 15:15, Eduardo Habkost wrote: >> >> ifeq ($(CONFIG_SOFTMMU),y) >> obj-$(CONFIG_KVM) += kvm-all.c >> obj-$(call lnot, $(CONFIG_KVM)) += kvm-stub.c >> endif >> >> similar to what is done already in Makefile.objs? > I assume you mean: > > ifeq ($(CONFIG_SOFTMMU),y) >

Re: [Xen-devel] [PATCH 05/10] x86/HVM: use unambiguous register names

>>> On 20.12.16 at 18:39, wrote: > On 20/12/2016 10:39, Jan Beulich wrote: >> @@ -3032,16 +3032,16 @@ void hvm_task_switch( >> if ( hvm_set_cr3(tss.cr3, 1) ) >> goto out; >> >> -regs->eip= tss.eip; >> -regs->eflags = tss.eflags | 2; >> -

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

On Wed, Dec 21, 2016 at 02:47:54PM +0100, Paolo Bonzini wrote: > > > On 21/12/2016 14:14, Eduardo Habkost wrote: > > On Wed, Dec 21, 2016 at 12:21:44PM +0100, Paolo Bonzini wrote: > >> > >> > >> On 20/12/2016 18:43, Eduardo Habkost wrote: > >>> This moves the KVM and Xen files to the an accel/

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

On 21/12/2016 14:14, Eduardo Habkost wrote: > On Wed, Dec 21, 2016 at 12:21:44PM +0100, Paolo Bonzini wrote: >> >> >> On 20/12/2016 18:43, Eduardo Habkost wrote: >>> This moves the KVM and Xen files to the an accel/ subdir. >>> >>> Instead of moving the *-stubs.c file to accel/ as-is, I tried to

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

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

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

On Wed, Dec 21, 2016 at 12:21:44PM +0100, Paolo Bonzini wrote: > > > On 20/12/2016 18:43, Eduardo Habkost wrote: > > This moves the KVM and Xen files to the an accel/ subdir. > > > > Instead of moving the *-stubs.c file to accel/ as-is, I tried to > > move most of the stub code to

Re: [Xen-devel] [PATCH 2/4] init/FreeBSD: remove xendriverdomain_precmd

On Wed, Dec 21, 2016 at 11:48:40AM +, Wei Liu wrote: > On Mon, Dec 19, 2016 at 03:02:02PM +, Roger Pau Monne wrote: > > ...because it's empty. While there also rename xendriverdomain_startcmd to > > xendriverdomain_start in order to match the nomenclature of the file. > > > >

Re: [Xen-devel] [PATCH 4/4] init/FreeBSD: add rc control variables

On Wed, Dec 21, 2016 at 11:49:29AM +, Wei Liu wrote: > On Mon, Dec 19, 2016 at 03:02:04PM +, Roger Pau Monne wrote: > > Those are used in order to decide which scripts are executed at init. > > > > Signed-off-by: Roger Pau Monné > > > Can't say I know much about

Re: [Xen-devel] [PATCH v2 2/5] config/StdGNU.mk: Allows users to pass in EXTRA_CFLAGS

On Tue, Dec 20, 2016 at 11:46:57AM -0800, Alistair Francis wrote: > Signed-off-by: Alistair Francis > --- > config/StdGNU.mk | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/config/StdGNU.mk b/config/StdGNU.mk > index 6be8233..a6cdd82 100644 > ---

[Xen-devel] Xen Security Advisory 202 (CVE-2016-10024) - x86 PV guests may be able to mask interrupts

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-10024 / XSA-202 version 3 x86 PV guests may be able to mask interrupts UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION

[Xen-devel] Xen Security Advisory 203 (CVE-2016-10025) - x86: missing NULL pointer check in VMFUNC emulation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-10025 / XSA-203 version 3 x86: missing NULL pointer check in VMFUNC emulation UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

Doug Goldstein writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking"): > I agree with you Andrew that its good for kernel/hypervisor development. > I also agree its good for userspace code prior to being committed or > part of a CI loop. Where I wish there was a switch

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

On Tue, Dec 20, 2016 at 01:33:39PM -0800, Stefano Stabellini wrote: > On Tue, 20 Dec 2016, Christoffer Dall wrote: > > Hi Stefano, > > > > On Mon, Dec 19, 2016 at 12:24:18PM -0800, Stefano Stabellini wrote: > > > On Mon, 19 Dec 2016, Christoffer Dall wrote: > > > > On Fri, Dec 16, 2016 at

Re: [Xen-devel] [PATCH 4/4] init/FreeBSD: add rc control variables

On Mon, Dec 19, 2016 at 03:02:04PM +, Roger Pau Monne wrote: > Those are used in order to decide which scripts are executed at init. > > Signed-off-by: Roger Pau Monné Can't say I know much about FreeBSD init mechanism, but I trust your judgement: Acked-by: Wei Liu

Re: [Xen-devel] [PATCH 2/4] init/FreeBSD: remove xendriverdomain_precmd

On Mon, Dec 19, 2016 at 03:02:02PM +, Roger Pau Monne wrote: > ...because it's empty. While there also rename xendriverdomain_startcmd to > xendriverdomain_start in order to match the nomenclature of the file. > > Signed-off-by: Roger Pau Monné > --- > Cc: Ian Jackson

Re: [Xen-devel] [PATCH 1/4] init/FreeBSD: set correct PATH for xl devd

On Mon, Dec 19, 2016 at 03:02:01PM +, Roger Pau Monne wrote: > FreeBSD init scripts don't have /usr/local/{bin/sbin} in it's PATH, which > prevents `xl devd` from working properly since hotplug scripts require the set > of xenstore cli tools to be in PATH. > > While there also fix the usage

Re: [Xen-devel] [PATCH 3/4] init/FreeBSD: fix xencommons so it can only be launched by Dom0

On Mon, Dec 19, 2016 at 03:02:03PM +, Roger Pau Monne wrote: > At the moment the execution of xencommons is gated on the presence of the > privcmd device, but that's not correct, since privcmd is available to all Xen > domains (privileged or unprivileged). Instead of using privcmd use the >

[Xen-devel] [distros-debian-squeeze test] 68252: tolerable FAIL

flight 68252 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68252/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 68218

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Map mmio-sram nodes as cached memory

Hi Edgar, On 20/12/2016 13:53, Edgar E. Iglesias wrote: On Mon, Dec 19, 2016 at 04:01:00PM -0800, Stefano Stabellini wrote: On Mon, 19 Dec 2016, Julien Grall wrote: Hi Edgar, On 16/12/2016 18:04, Edgar E. Iglesias wrote: On Fri, Dec 16, 2016 at 04:12:00PM +, Julien Grall wrote: On

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

On 20/12/2016 18:43, Eduardo Habkost wrote: > This moves the KVM and Xen files to the an accel/ subdir. > > Instead of moving the *-stubs.c file to accel/ as-is, I tried to > move most of the stub code to libqemustub.a. This way the obj-y > logic for accel/ is simpler: obj-y includes accel/

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

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

[Xen-devel] [ovmf baseline-only test] 68251: tolerable FAIL

This run is configured for baseline tests only. flight 68251 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68251/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install

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

Hello Dirk, Except those two issues did you face some issues with PVR KM? ANDRII ANISOV Lead Systems Engineer   Office: +380 44 390 5457 x 66766   Cell: +380 50 573 8852   Email:  andrii_ani...@epam.com Kyiv, Ukraine (GMT+3)   epam.com   CONFIDENTIALITY CAUTION AND DISCLAIMER This message

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

On 20.12.2016 19:01, Julien Grall wrote: Hi Andrii, On 20/12/2016 19:00, Andrii Anisov wrote: Sorry for the mess, I mean the xen-swiotlb issue on renesas board: Bosch: problem with xen-swiotlb. It does not work properly on renesas board. Stefano: please report the error on the ML ACTION: