[Xen-devel] [qemu-upstream-4.8-testing test] 105695: tolerable FAIL - PUSHED

flight 105695 qemu-upstream-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105695/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit2 3 host-install(3) broken in 105678 pass in 105695

[Xen-devel] [qemu-upstream-unstable baseline-only test] 68546: regressions - trouble: blocked/broken/fail/pass

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

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

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

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

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

[Xen-devel] [qemu-upstream-4.6-testing test] 105693: tolerable FAIL - PUSHED

flight 105693 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105693/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102708

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

flight 105697 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105697/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

[Xen-devel] [linux-3.10 test] 105694: tolerable FAIL - PUSHED

flight 105694 linux-3.10 real [real] http://logs.test-lab.xenproject.org/osstest/logs/105694/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102077

[Xen-devel] [PATCH v4 2/2] arm: proper ordering for correct execution of gic_update_one_lr and vgic_store_itargetsr

Concurrent execution of gic_update_one_lr and vgic_store_itargetsr can result in the wrong pcpu being set as irq target, see http://marc.info/?l=xen-devel=148218667104072. To solve the issue, add barriers, remove an irq from the inflight queue, only after the affinity has been set. On the other

[Xen-devel] [PATCH v4 1/2] arm: read/write rank->vcpu atomically

We don't need a lock in vgic_get_target_vcpu anymore, solving the following lock inversion bug: the rank lock should be taken first, then the vgic lock. However, gic_update_one_lr is called with the vgic lock held, and it calls vgic_get_target_vcpu, which tries to obtain the rank lock.

[Xen-devel] [qemu-upstream-4.7-testing test] 105691: trouble: blocked/broken/fail/pass

flight 105691 qemu-upstream-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105691/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3 host-install(3)broken

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

On Wed, 8 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 02/02/17 22:56, Stefano Stabellini wrote: > > On Thu, 2 Feb 2017, Julien Grall wrote: > > > On 01/02/17 23:23, Stefano Stabellini wrote: > > > > On Wed, 1 Feb 2017, Julien Grall wrote: > > > > > On 31/01/2017 23:49, Stefano Stabellini

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

flight 105687 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105687/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 59254

[Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

Hello, This e-mail is sort of follow-up to the two threads: [1] (my thread about TEE interaction) and [2] (Edgar's thread regarding handling SMC calls in platform_hvc). I want to discuss more broad topic there. Obviously, there are growing number of SMC users and current state of SMC handling in

Re: [Xen-devel] Xen Security Advisory 208 (CVE-2017-2615) - oob access in cirrus bitblt copy

On Fri, 10 Feb 2017, Xen.org security team wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2017-2615 / XSA-208 oob access in cirrus bitblt copy The qemu-xen-traditional patch is malformed, as the file it tries to patch is at the

[Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

Hey! This patch lets me compile this emulator under Xen 4.7. It probably can be done better (#ifdef magic?) but for right now this gets me past the compile errors. BTW, are there any other outstanding patches against this tree? demu.c | 7 ++- 1 file changed, 6 insertions(+), 1

[Xen-devel] [PATCH] Make it compiler under Xen 4.7.

With b7f76a699dcfadc0a52ab45b33cc72dbf3a69e7b Author: Ian Campbell Date: Mon Jun 1 16:20:09 2015 +0100 tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn. commit 32486916793fd78a41fc25e53d2b53a5aa0b1bd5 Author: Ian Campbell Date:

Re: [Xen-devel] [PATCH v6 07/24] x86: refactor psr: implement get value flow.

On Wed, Feb 08, 2017 at 04:15:59PM +0800, Yi Sun wrote: > This patch implements get value flow including L3 CAT callback > function. > > It also changes domctl interface to make it more general. > > With this patch, 'psr-cat-show' can work for L3 CAT but not for > L3 code/data which is

[Xen-devel] [qemu-upstream-unstable test] 105689: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 105689 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105689/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 3 host-install(3) broken pass in 105675

Re: [Xen-devel] [PATCH v6 06/24] x86: refactor psr: implement get hw info flow.

On Wed, Feb 08, 2017 at 04:15:58PM +0800, Yi Sun wrote: > This patch implements get HW info flow including L3 CAT callback > function. > > It also changes sysctl interface to make it more general. > > With this patch, 'psr-hwinfo' can work for L3 CAT. > > Signed-off-by: Yi Sun

Re: [Xen-devel] [DOC v8] PV Calls protocol design

On Fri, Feb 10, 2017 at 12:09:36PM -0800, Stefano Stabellini wrote: > On Fri, 10 Feb 2017, Konrad Rzeszutek Wilk wrote: > > .snip.. > > > > > Request fields: > > > > > > > > > > - **cmd** value: 0 > > > > > - additional fields: > > > > > - **id**: identifies the socket > > > > > - **addr**:

Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > This is the ABI for the two halves of a para-virtualized > display driver. > > This protocol aims to provide a unified protocol which fits more >

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

On Fri, 10 Feb 2017, Paul Durrant wrote: > > -Original Message- > [snip] > > > Neither NVIDIA vGPU nor Intel GVT-g are pass-through. They both use > > emulation to synthesize GPU devices for guests and then use the actual GPU > > to service the commands sent by the guest driver to the

[Xen-devel] [xen-4.6-testing test] 105685: tolerable FAIL - PUSHED

flight 105685 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105685/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-pair 20 guest-start/debian fail in 105673 pass in 105685 test-armhf-armhf-xl-credit2

Re: [Xen-devel] [DOC v8] PV Calls protocol design

On Fri, 10 Feb 2017, Konrad Rzeszutek Wilk wrote: > .snip.. > > > > Request fields: > > > > > > > > - **cmd** value: 0 > > > > - additional fields: > > > > - **id**: identifies the socket > > > > - **addr**: address to connect to, see [Socket families and address > > > > format] > > > > > >

Re: [Xen-devel] [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

Hi Paul, [auto build test ERROR on xen-tip/linux-next] [also build test ERROR on v4.10-rc7 next-20170210] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paul-Durrant/xen-privcmd-support

[Xen-devel] [xen-unstable test] 105683: trouble: blocked/broken/fail/pass

flight 105683 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105683/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

From: Boris Ostrovsky Date: Thu, 9 Feb 2017 08:42:59 -0500 > Are you going to take this to your tree or would you rather it goes > via Xen tree? Ok, I just did. > And the same question for > >

Re: [Xen-devel] [DOC v4] Xen transport for 9pfs

On Thu, Feb 09, 2017 at 05:31:46PM -0800, Stefano Stabellini wrote: > On Wed, 8 Feb 2017, Konrad Rzeszutek Wilk wrote: > > > ## Ring Setup > > > > > > The shared page has the following layout: > > > > > > typedef uint32_t XEN_9PFS_RING_IDX; > > > > > > struct xen_9pfs_intf { > > >

Re: [Xen-devel] [DOC v8] PV Calls protocol design

.snip.. > > > Request fields: > > > > > > - **cmd** value: 0 > > > - additional fields: > > > - **id**: identifies the socket > > > - **addr**: address to connect to, see [Socket families and address > > > format] > > > > > > Hm, so what do we do if we want to support AF_UNIX which has an

Re: [Xen-devel] Xen on ARM IRQ latency and scheduler overhead

On Fri, 10 Feb 2017, Dario Faggioli wrote: > On Thu, 2017-02-09 at 16:54 -0800, Stefano Stabellini wrote: > > Hi all, > > > Hi, > > > I have run some IRQ latency measurements on Xen on ARM on a Xilinx > > ZynqMP board (four Cortex A53 cores, GICv2). > > > > Dom0 has 1 vcpu pinned to cpu0, DomU

Re: [Xen-devel] [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On 02/10/2017 11:28 AM, Paul Durrant wrote: >> -Original Message- >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] >> Sent: 10 February 2017 16:18 >> To: Paul Durrant ; xen-de...@lists.xenproject.org; >> linux-ker...@vger.kernel.org >> Cc: Juergen Gross

Re: [Xen-devel] [RFC PATCH v1 17/21] ARM: NUMA: Extract memory proximity from SRAT table

On Fri, Feb 10, 2017 at 12:33:33PM -0500, Konrad Rzeszutek Wilk wrote: > On Thu, Feb 09, 2017 at 09:27:09PM +0530, vijay.kil...@gmail.com wrote: > > From: Vijaya Kumar K > > > > Register SRAT entry handler for type > > ACPI_SRAT_TYPE_MEMORY_AFFINITY to parse SRAT table >

Re: [Xen-devel] [RFC PATCH v1 17/21] ARM: NUMA: Extract memory proximity from SRAT table

On Thu, Feb 09, 2017 at 09:27:09PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Register SRAT entry handler for type > ACPI_SRAT_TYPE_MEMORY_AFFINITY to parse SRAT table > and extract proximity for all memory mappings. Why can't you use

Re: [Xen-devel] [RFC PATCH v1 00/21] ARM: Add Xen NUMA support

On Thu, Feb 09, 2017 at 09:26:52PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > With this RFC patch series, NUMA support is added for arm platform. > Both DT and ACPI based NUMA support is added. > Only Xen is made aware of NUMA platform. Dom0 is

Re: [Xen-devel] [PATCH v2 02/11] x86emul: flatten twobyte_table[]

On 01/02/17 11:13, Jan Beulich wrote: > +static const struct { > +opcode_desc_t desc; > +} twobyte_table[256] = { > +[0x00] = { ModRM }, This is definitely an improvement in readability, so Acked-by: Andrew Cooper (I have briefly checked that everything appears

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 02/10/2017 11:35 AM, Waiman Long wrote: > On 02/10/2017 11:19 AM, Peter Zijlstra wrote: >> On Fri, Feb 10, 2017 at 10:43:09AM -0500, Waiman Long wrote: >>> It was found when running fio sequential write test with a XFS ramdisk >>> on a VM running on a 2-socket x86-64 system, the %CPU times as

Re: [Xen-devel] [PATCH v2 01/11] x86emul: catch exceptions occurring in stubs

On 01/02/17 11:12, Jan Beulich wrote: > Before adding more use of stubs cloned from decoded guest insns, guard > ourselves against mistakes there: Should an exception (with the > noteworthy exception of #PF) occur inside the stub, forward it to the > guest. Why exclude #PF ? Nothing in a stub

Re: [Xen-devel] [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 10 February 2017 16:18 > To: Paul Durrant ; xen-de...@lists.xenproject.org; > linux-ker...@vger.kernel.org > Cc: Juergen Gross > Subject: Re: [PATCH v2 2/3]

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 02/10/2017 11:19 AM, Peter Zijlstra wrote: > On Fri, Feb 10, 2017 at 10:43:09AM -0500, Waiman Long wrote: >> It was found when running fio sequential write test with a XFS ramdisk >> on a VM running on a 2-socket x86-64 system, the %CPU times as reported >> by perf were as follows: >> >>

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On 10/02/2017 16:43, Waiman Long wrote: > It was found when running fio sequential write test with a XFS ramdisk > on a VM running on a 2-socket x86-64 system, the %CPU times as reported > by perf were as follows: > > 69.75% 0.59% fio [k] down_write > 69.15% 0.01% fio [k]

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On Fri, Feb 10, 2017 at 10:43:09AM -0500, Waiman Long wrote: > It was found when running fio sequential write test with a XFS ramdisk > on a VM running on a 2-socket x86-64 system, the %CPU times as reported > by perf were as follows: > > 69.75% 0.59% fio [k] down_write > 69.15% 0.01% fio

Re: [Xen-devel] [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

On 02/10/2017 09:24 AM, Paul Durrant wrote: > +static long privcmd_ioctl_dm_op(void __user *udata) > +{ > + struct privcmd_dm_op kdata; > + struct privcmd_dm_op_buf *kbufs; > + unsigned int nr_pages = 0; > + struct page **pages = NULL; > + struct xen_dm_op_buf *xbufs = NULL; >

[Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

It was found when running fio sequential write test with a XFS ramdisk on a VM running on a 2-socket x86-64 system, the %CPU times as reported by perf were as follows: 69.75% 0.59% fio [k] down_write 69.15% 0.01% fio [k] call_rwsem_down_write_failed 67.12% 1.12% fio [k]

[Xen-devel] [libvirt test] 105684: regressions - FAIL

flight 105684 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/105684/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 105657 Regressions which are

Re: [Xen-devel] [PATCH v6 4/7] xen/x86: parse Dom0 kernel for PVHv2

Roger Pau Monne writes ("[PATCH v6 4/7] xen/x86: parse Dom0 kernel for PVHv2"): > Introduce a helper to parse the Dom0 kernel. > > A new helper is also introduced to libelf, that's used to store the > destination vcpu of the domain. This parameter is needed when > loading the kernel on a HVM

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

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

[Xen-devel] [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism for restricting device emulators (such as QEMU) to a limited set of hypervisor operations, and being able to audit those operations in the kernel of the domain in which they run. This patch adds IOCTL_PRIVCMD_DM_OP as

[Xen-devel] [PATCH v2 1/3] xen/privcmd: return -ENOTTY for unimplemented IOCTLs

The code sets the default return code to -ENOSYS but then overrides this to -EINVAL in the switch() statement's default case, which is clearly silly. This patch removes the override and sets the default return code to -ENOTTY, which is the conventional return for an unimplemented ioctl.

[Xen-devel] [PATCH v2 3/3] xen/privcmd: add IOCTL_PRIVCMD_RESTRICT

The purpose if this ioctl is to allow a user of privcmd to restrict its operation such that it will no longer service arbitrary hypercalls via IOCTL_PRIVCMD_HYPERCALL, and will check for a matching domid when servicing IOCTL_PRIVCMD_DM_OP. The aim of this is to limit the attack surface for a

[Xen-devel] [PATCH v2 0/3] xen/privcmd: support for dm_op and restriction

This patch series follows on from my recent Xen series [1], to provide support in privcmd for de-privileging of device emulators. [1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg02558.html Paul Durrant (3): xen/privcmd: return -ENOTTY for unimplemented IOCTLs xen/privcmd: Add

Re: [Xen-devel] [PATCH v4 0/3] xen: optimize xenbus performance

On 02/09/2017 08:39 AM, Juergen Gross wrote: > The xenbus driver used for communication with Xenstore (all kernel > accesses to Xenstore and in case of Xenstore living in another domain > all accesses of the local domain to Xenstore) is rather simple > especially regarding multiple concurrent

Re: [Xen-devel] [PATCH v6 2/7] xen/x86: split Dom0 build into PV and PVHv2

On 10/02/17 12:33, Roger Pau Monne wrote: > Split the Dom0 builder into two different functions, one for PV (and classic > PVH), and another one for PVHv2. Introduce a new command line parameter called > 'dom0' that can be used to request the creation of a PVHv2 Dom0 by setting the > 'hvm'

Re: [Xen-devel] [PATCH] x86/bitops: Force __scanbit() to be always inline

>>> On 10.02.17 at 12:44, wrote: > It turns out that GCCs 4.9.2 and 6.3.0 instantiate __scanbit() in three > translation units, but never references the result. All real uses of > __scanbit() are already suitably inline. While I'm not opposed to this at all, we should

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

> -Original Message- [snip] > > Neither NVIDIA vGPU nor Intel GVT-g are pass-through. They both use > emulation to synthesize GPU devices for guests and then use the actual GPU > to service the commands sent by the guest driver to the virtual GPU. So, I > think they fall outside the

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

On Fri, Feb 10, 2017 at 10:11:53AM +, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 10 February 2017 09:49 > > To: Stefano Stabellini > > Cc: Julien Grall ; xen-devel > de...@lists.xenproject.org>;

Re: [Xen-devel] [PATCH] xen-netback: vif counters from int/long to u64

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Mart van Santen > Sent: 10 February 2017 12:02 > To: Wei Liu ; Paul Durrant ; > xen-de...@lists.xenproject.org; net...@vger.kernel.org > Cc: Mart van

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

flight 105680 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105680/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

[Xen-devel] Xen Security Advisory 208 (CVE-2017-2615) - oob access in cirrus bitblt copy

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2017-2615 / XSA-208 oob access in cirrus bitblt copy ISSUE DESCRIPTION = When doing bitblt copy backwards, qemu should negate the blit width. This avoids an oob access before

[Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

Craft the Dom0 e820 memory map and populate it. Introduce a helper to remove memory pages that are shared between Xen and a domain, and use it in order to remove low 1MB RAM regions from dom_io in order to assign them to a PVHv2 Dom0. On hardware lacking support for unrestricted mode also craft

[Xen-devel] [PATCH v6 5/7] x86/PVHv2: fix dom0_max_vcpus so it's capped to HVM_MAX_VCPUS for PVHv2 Dom0

PVHv2 Dom0 is limited to 128 vCPUs, as are all HVM guests at the moment. Fix dom0_max_vcpus so it takes this limitation into account. Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper --- Cc: Jan Beulich Cc: Andrew

[Xen-devel] [PATCH v6 2/7] xen/x86: split Dom0 build into PV and PVHv2

Split the Dom0 builder into two different functions, one for PV (and classic PVH), and another one for PVHv2. Introduce a new command line parameter called 'dom0' that can be used to request the creation of a PVHv2 Dom0 by setting the 'hvm' sub-option. A panic has also been added if a user tries

[Xen-devel] [PATCH v6 4/7] xen/x86: parse Dom0 kernel for PVHv2

Introduce a helper to parse the Dom0 kernel. A new helper is also introduced to libelf, that's used to store the destination vcpu of the domain. This parameter is needed when loading the kernel on a HVM domain (PVHv2), since hvm_copy_to_guest_phys requires passing the destination vcpu. While

[Xen-devel] [PATCH v6 6/7] xen/x86: Setup PVHv2 Dom0 CPUs

Initialize Dom0 BSP/APs and setup the memory and IO permissions. This also sets the initial BSP state in order to match the protocol specified in docs/misc/hvmlite.markdown. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH v6 1/7] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

PVHv2 guests, unlike HVM guests, won't have the option to route interrupts from physical or emulated devices over event channels using PIRQs. This applies to both DomU and Dom0 PVHv2 guests. Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can route physical interrupts (even

[Xen-devel] [PATCH v6 0/7] Initial PVHv2 Dom0 support

Hello, This is the first batch of the PVHv2 Dom0 support series that includes everything up to the point where ACPI tables for Dom0 are crafted. I've decided to left the last part of the series (the one that contains the PCI config space handlers, and other emulation/trapping related code)

[Xen-devel] [PATCH v6 7/7] xen/x86: setup PVHv2 Dom0 ACPI tables

Create a new MADT table that contains the topology exposed to the guest. A new XSDT table is also created, in order to filter the tables that we want to expose to the guest, plus the Xen crafted MADT. This in turn requires Xen to also create a new RSDP in order to make it point to the custom XSDT.

[Xen-devel] [PATCH] xen-netback: vif counters from int/long to u64

This patch fixes an issue where the type of counters in the queue(s) and interface are not in sync (queue counters are int, interface counters are long), causing incorrect reporting of tx/rx values of the vif interface and unclear counter overflows. This patch sets both counters to the u64 type.

Re: [Xen-devel] [PATCH] x86/time: tsc_check_writability() may need to be run a second time

On 02/10/2017 11:17 AM, Andrew Cooper wrote: > On 10/02/17 11:11, Joao Martins wrote: >> On 02/10/2017 11:03 AM, Jan Beulich wrote: >>> While we shouldn't remove its current invocation, we need to re-run it >>> for the case that the X86_FEATURE_TSC_RELIABLE feature flag has been >>> cleared, in

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

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

[Xen-devel] [PATCH] x86/bitops: Force __scanbit() to be always inline

It turns out that GCCs 4.9.2 and 6.3.0 instantiate __scanbit() in three translation units, but never references the result. All real uses of __scanbit() are already suitably inline. Signed-off-by: Andrew Cooper --- CC: Jan Beulich Forcing

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

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

[Xen-devel] [qemu-upstream-4.8-testing test] 105678: regressions - trouble: blocked/broken/fail/pass

flight 105678 qemu-upstream-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105678/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 3 host-install(3)broken REGR. vs. 102941

Re: [Xen-devel] [PATCH] x86/time: tsc_check_writability() may need to be run a second time

On 10/02/17 11:11, Joao Martins wrote: > On 02/10/2017 11:03 AM, Jan Beulich wrote: >> While we shouldn't remove its current invocation, we need to re-run it >> for the case that the X86_FEATURE_TSC_RELIABLE feature flag has been >> cleared, in order to avoid using the TSC rendezvous function in

Re: [Xen-devel] [PATCH] x86/time: tsc_check_writability() may need to be run a second time

On 02/10/2017 11:03 AM, Jan Beulich wrote: > While we shouldn't remove its current invocation, we need to re-run it > for the case that the X86_FEATURE_TSC_RELIABLE feature flag has been > cleared, in order to avoid using the TSC rendezvous function in case > the TSC can't be written. > >

Re: [Xen-devel] [PATCH] x86/time: tsc_check_writability() may need to be run a second time

On 10/02/17 11:03, Jan Beulich wrote: > While we shouldn't remove its current invocation, we need to re-run it > for the case that the X86_FEATURE_TSC_RELIABLE feature flag has been > cleared, in order to avoid using the TSC rendezvous function in case > the TSC can't be written. > >

[Xen-devel] [PATCH] x86/time: tsc_check_writability() may need to be run a second time

While we shouldn't remove its current invocation, we need to re-run it for the case that the X86_FEATURE_TSC_RELIABLE feature flag has been cleared, in order to avoid using the TSC rendezvous function in case the TSC can't be written. Signed-off-by: Jan Beulich ---

Re: [Xen-devel] [PATCH] x86emul/test: fix 32-bit build

On 10/02/17 07:38, Jan Beulich wrote: > Commit 7603eb256 ("x86emul: use eflags definitions in x86-defns.h") > removed the EFLG_* definitions without updating the use sites (which > - oddly enough - happen to all be in 32-bit only code paths). > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH] x86emul: always init mmval

On 10/02/17 07:39, Jan Beulich wrote: > ... to avoid buggy read/write sizes becoming info leaks. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list

[Xen-devel] [qemu-upstream-4.6-testing test] 105677: trouble: broken/fail/pass

flight 105677 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105677/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 3 host-install(3)broken

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

> -Original Message- > From: Roger Pau Monne > Sent: 10 February 2017 09:49 > To: Stefano Stabellini > Cc: Julien Grall ; xen-devel de...@lists.xenproject.org>; Edgar Iglesias (edgar.igles...@xilinx.com) > ;

Re: [Xen-devel] qemu-upstream triggering OOM killer

>>> On 09.02.17 at 23:24, wrote: > On Thu, 9 Feb 2017, Jan Beulich wrote: >> the recent qemuu update results in the produced binary triggering the >> OOM killer on the first system I tried the updated code on. Is there >> anything known in this area? Are there any hints as

Re: [Xen-devel] kernel BUG at block/bio.c:1786 -- (xen_blkif_schedule on the stack)

On Fri, Feb 10, 2017 at 09:27:46AM +0100, Håkon Alstadheim wrote: > I just tried to provoke the bug, after applying your patch and > re-enabling tmem, but it seems there are more variables in the equation > to make a crash happen. Before this week the VM in question would > reliably crash/hang on

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

On Wed, Feb 01, 2017 at 10:50:49AM -0800, Stefano Stabellini wrote: > On Wed, 1 Feb 2017, Roger Pau Monné wrote: > > On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 24/01/17 20:07, Stefano Stabellini wrote: > > > > On Tue, 24 Jan 2017, Julien Grall

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

>>> On 07.02.17 at 00:32, wrote: > Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has > added a assertion that intack.vector is the highest priority vector. But > according to the osstest, the assertion failed sometimes. More discussion can > be found

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

>>> On 08.02.17 at 08:49, wrote: > Curious how this issue was initially caught? Would same practice make > sure next fail catching our eye? I guess Andrew just happened to look at the logs of a spurious failure of some test. Jan

[Xen-devel] [distros-debian-jessie test] 68543: tolerable trouble: blocked/broken/pass

flight 68543 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68543/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a build-arm64

Re: [Xen-devel] [PATCH] build/printf: fix incorrect format specifiers

>>> On 09.02.17 at 17:35, wrote: > --- a/xen/arch/x86/cpu/mcheck/mce.c > +++ b/xen/arch/x86/cpu/mcheck/mce.c > @@ -596,8 +596,8 @@ int show_mca_info(int inited, struct cpuinfo_x86 *c) > }; > > snprintf(prefix, ARRAY_SIZE(prefix), > -

[Xen-devel] [qemu-upstream-4.7-testing test] 105676: regressions - FAIL

flight 105676 qemu-upstream-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 102701

Re: [Xen-devel] [PATCH] x86emul/test: fix 32-bit build

>>> On 10.02.17 at 09:15, wrote: > On Fri, Feb 10, 2017 at 12:38:51AM -0700, Jan Beulich wrote: >> Commit 7603eb256 ("x86emul: use eflags definitions in x86-defns.h") >> removed the EFLG_* definitions without updating the use sites (which >> - oddly enough - happen to all be

Re: [Xen-devel] Xen on ARM IRQ latency and scheduler overhead

On Thu, 2017-02-09 at 16:54 -0800, Stefano Stabellini wrote: > Hi all, > Hi, > I have run some IRQ latency measurements on Xen on ARM on a Xilinx > ZynqMP board (four Cortex A53 cores, GICv2). > > Dom0 has 1 vcpu pinned to cpu0, DomU has 1 vcpu pinned to cpu2. > Dom0 is Ubuntu. DomU is an

Re: [Xen-devel] kernel BUG at block/bio.c:1786 -- (xen_blkif_schedule on the stack)

I just tried to provoke the bug, after applying your patch and re-enabling tmem, but it seems there are more variables in the equation to make a crash happen. Before this week the VM in question would reliably crash/hang on boot during the past month and through several re-boots of the dom0. I

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

On Fri, Feb 10, 2017 at 08:11:20AM +, Wei Liu wrote: > On Fri, Feb 10, 2017 at 10:37:44AM +0800, Haozhong Zhang wrote: > > On 02/09/17 10:13 +, Wei Liu wrote: > > > On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote: > > > > On 02/08/17 10:31 +, Wei Liu wrote: > > > > > On

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

On 02/10/17 08:11 +, Wei Liu wrote: On Fri, Feb 10, 2017 at 10:37:44AM +0800, Haozhong Zhang wrote: On 02/09/17 10:13 +, Wei Liu wrote: > On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote: > > On 02/08/17 10:31 +, Wei Liu wrote: > > > On Wed, Feb 08, 2017 at 02:07:26PM

Re: [Xen-devel] [PATCH] x86emul/test: fix 32-bit build

On Fri, Feb 10, 2017 at 12:38:51AM -0700, Jan Beulich wrote: > Commit 7603eb256 ("x86emul: use eflags definitions in x86-defns.h") > removed the EFLG_* definitions without updating the use sites (which > - oddly enough - happen to all be in 32-bit only code paths). > > Signed-off-by: Jan Beulich

[Xen-devel] [PATCH] x86emul: always init mmval

... to avoid buggy read/write sizes becoming info leaks. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -2671,6 +2671,8 @@ x86_emulate( ea.reg = decode_register(modrm_rm, &_regs,

[Xen-devel] [PATCH] x86emul/test: fix 32-bit build

Commit 7603eb256 ("x86emul: use eflags definitions in x86-defns.h") removed the EFLG_* definitions without updating the use sites (which - oddly enough - happen to all be in 32-bit only code paths). Signed-off-by: Jan Beulich --- a/tools/tests/x86_emulator/test_x86_emulator.c

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

On Fri, Feb 10, 2017 at 10:37:44AM +0800, Haozhong Zhang wrote: > On 02/09/17 10:13 +, Wei Liu wrote: > > On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote: > > > On 02/08/17 10:31 +, Wei Liu wrote: > > > > On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote: > > >