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
test-amd64-i386-fre
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-b
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 8d127a5a3a23d960644d1
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
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
test-armhf-arm
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
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
test-amd64-amd64-xl-qemut-win
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&m=148218667104072.
To solve the issue, add barriers, remove an irq from the inflight
queue, only after the affinity has been set. On the other
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.
Coverity-ID
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
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 wr
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
test-amd64-amd64-xl
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
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 xe
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 deletion(-
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: Thu Jun 18 16:30:19 2015 +0100
tools: Refact
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 implemente
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
test-armhf-armhf-xl-cr
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
Reviewed-by: Kon
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**: ad
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
> sophisticated use-cases than a framebuffe
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 virtu
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 1
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]
> > >
> > >
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-for
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
R
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
>
> https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00625.html
As I stated in the thread
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 {
> > >
.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 a
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 h
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
>> Subject: Re: [PATCH v
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
> > and extract proximity f
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 arch/x86/srat.c code? Or move parts of t
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 awareness is not
> added.
>
>
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 to be the same, but not che
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
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 shou
> -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] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>
> On
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:
>>
>> 69.75%
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] call_rwsem_down
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
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;
> +
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] rwsem_down_writ
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 r
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 domai
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 v
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 gatewa
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.
Signed-of
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 compro
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 IOC
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 acces
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' sub-opti
>>> 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 set ourselves a
reasonably
> -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 discuss
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>; Edgar Iglesias (edgar.igles...@xilinx.com)
> > ; Steve
> -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 Santen
> Subject: [Xen-devel] [PATCH] xen-net
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
-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 t
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 th
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 Cooper
---
Changes since v5:
- Introduce a new limit local variable an
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 to
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 ther
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
---
Changes since v5:
- Make cpus and i unsigned in
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
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) separat
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.
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.
S
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 ord
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 41ccec58e07376fe3086d
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 __scanbit() to be always_inline appears to cause GCC to
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
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
test-
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 ca
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.
>
> Signed-o
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.
>
> Signed-off-by:
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
--- a/xen/arch/x86/time.c
+++ b/xe
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
Reviewed-by: Andrew Coo
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@lists.xen.org
https://lists.xen.org/xen-devel
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
> -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)
> ; Steve Capper ; Punit
> Agrawal ; Wei Chen ;
> Campbell Sean ; Shanker Donthineni
>>> 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 to finding out
>> what i
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 b
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 wr
>>> 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 in the thread
> (http
>>> 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 mailing
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
>>> 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),
> - g_type != mcheck_unset ? XEN
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
test-
>>> 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 in 32-bit only code pa
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 ad-hoc
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 hav
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 W
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 +
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
... 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,
(
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
+++ b/tools/tests/x
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:
> > > >
97 matches
Mail list logo
