flight 123756 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123756/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken in 123636
test-amd64-amd64-rumprun-am
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, June 1, 2018 12:03 AM
>
> This is essentially a "take 2" of c/s 82540b66ce "x86/VT-x: Fix determination
> of EFER.LMA in vmcs_dump_vcpu()" because in hindight, that change was
> more
> problematic than useful.
>
> The origin
flight 123733 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 123144
test-amd64-i386
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> /* -- */
>
> +static int
> +dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
> + int count, int domid)
> +{
> + grant_ref_t priv
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add UAPI and IOCTLs for dma-buf grant device driver extension:
> the extension allows userspace processes and kernel modules to
> use Xen backed dma-buf implementation. With this extension grant
> references
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Allow creating grant device context for use by kernel modules which
> require functionality, provided by gntdev. Export symbols for dma-buf
> API provided by the module.
Can you give an example of who'd be
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Create a dma-buf from grant references provided by the foreign
>domain. By default dma-buf is backed by system memory pages, but
>by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
>
flight 123701 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123701/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 broken in 123492
test-amd64-amd64-xl-qemuu-o
flight 123791 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123791/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 38c977c148e92e2af17c5d346d9b4b2e7a18680a
baseline version:
ovmf c4061d18ef531147a5807
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h
> new file mode 100644
> index ..a727d65a1e61
> --- /dev/null
> +++ b/include/xen/mem-reservation.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Allow mappings for DMA backed buffers if grant table module
> supports such: this extends grant device to not only map buffers
> made of balloon pages, but also from buffers allocated with
> dma_alloc_xxx.
Any opinions regarding this patch?
>>> On 5/15/2018 at 11:34 AM, Charles Arnold wrote:
> Some time ago this bug was written up,
>
> https://bugs.xenproject.org/xen/bug/46
> "qemu-upstream: limitation on 4 emulated NICs prevents guest from starting
> unless PV override is used."
>
> While there
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Extend grant table module API to allow allocating buffers that can
> be used for DMA operations and mapping foreign grant references
> on top of those.
> The resulting buffer is similar to the one allocated
On Fri, May 18, 2018 at 06:01:42PM +0100, Wei Liu wrote:
> Cc Anthony.
>
> On Thu, May 17, 2018 at 05:51:08PM +0200, Olaf Hering wrote:
> > If a domU has a qemu-xen instance attached, it is required to call qemus
> > "xen-save-devices-state" method. Without it, the receiving side of a PV
> > migra
HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- no changes
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 4 ++--
The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.
Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
useful anymore.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabelli
All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.
Add an x86 dependency to HAS_EHCI: EHCI PCI has not been used on ARM. In
fact, it depends on PCI, and moreover we have drivers for several
embedded UARTs for various ARM boards.
Signed-of
Hi all,
This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.
First, the series makes a few changes to allow disabling more kconfig
options: most of them already exist but cannot be disabled.
Then, it introduces a reference kconfig for Renesas RCa
Select MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS is not
configurable on x86. Avoid selecting it on ARM.
Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere. Add a prompt and a
description to MEM_ACCESS in xen/common/Kconfig.
The result is that the user-visible option is MEM_ACCESS, and it is
Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
Acked-by: Jan Beulich
CC: jbeul...@suse.com
---
Changes in v3:
- rename SMMUv2 to ARM_SMMU
- improve help message
- use if ARM
Changes in v2:
- rename HAS_SMMUv2 to SMMUv2
Add a Xen build target to count the lines of code of the source files
built. Uses `cloc' to do the job.
With Xen on ARM taking off in embedded, IoT, and automotive, we are
seeing more and more uses of Xen in constrained environments. Users and
system integrators want the smallest Xen and Dom0 conf
Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
MPSOC and ALL. They enable the required options for their hardware
platform. ALL enables all available platforms and it's the default. It
doesn't automatically select any of the related drivers, otherwise they
cannot be disable
Today it is a silent option. This patch adds a one line description and
makes it optional.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- remove any changes to MEM_ACCESS
- update commit message
Changes in v2:
- make HAS_GICv3 depend on ARM_64
- remove modificati
Add a tiny kconfig configuration. Enabled NULL and Credit schedulers.
Support only 8 cpus. It only carries non-default options (use make
olddefconfig to produce a complete .config file).
Signed-off-by: Stefano Stabellini
---
---
xen/arch/arm/configs/tiny.conf | 43 ++
Add specific per-platform defaults for NR_CPUS. Note that the order of
the defaults matter: they need to go first, otherwise the generic
defaults will be applied.
This is done so that Xen builds customized for a specific hardware
platform can have the right NR_CPUS number.
Signed-off-by: Stefano
On 04/06/18 18:09, Razvan Cojocaru wrote:
> On 06/04/2018 06:39 PM, Andrew Cooper wrote:
>> On 04/06/18 14:59, Andrew Cooper wrote:
>>> So this started as a small fix for the vmentry failure (penultimate patch),
>>> and has snowballed...
>>>
>>> I'm fairly confident that everything involving DEBUGC
On 06/04/2018 06:39 PM, Andrew Cooper wrote:
> On 04/06/18 14:59, Andrew Cooper wrote:
>> So this started as a small fix for the vmentry failure (penultimate patch),
>> and has snowballed...
>>
>> I'm fairly confident that everything involving DEBUGCTL.BTF is broken, and
>> there are definitely bug
On 06/04/2018 07:37 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h
new file mode 100644
index ..a727d65a1e61
--- /dev/null
+++ b/include/xen/mem-reservation.h
@@ -0,0 +1,65 @
flight 123683 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-build fail in 123594 REGR. vs. 123274
Tests which are fail
On 06/01/2018 09:51 PM, Stefano Stabellini wrote:
On Fri, 1 Jun 2018, Julien Grall wrote:
Hi Stefano,
Sorry for formatting.
On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote:
Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
RCAR3 and MPSOC. They enabl
On 05/31/2018 10:38 PM, Stefano Stabellini wrote:
On Wed, 30 May 2018, Julien Grall wrote:
On 30/05/2018 22:39, Stefano Stabellini wrote:
On Tue, 29 May 2018, Julien Grall wrote:
Hi Stefano,
On 23/05/18 01:25, Stefano Stabellini wrote:
Add a "Platform Support" menu with three umbrella kcon
Hi Stefano,
On 06/01/2018 09:53 PM, Stefano Stabellini wrote:
On Fri, 1 Jun 2018, Julien Grall wrote:
Hi,
Sorry for the formatting. I am pretty sure you need to CC "THE REST" here.
On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote:
Add specific per-platform defaults for NR_CPUS. Not
On 04/06/18 14:59, Andrew Cooper wrote:
> So this started as a small fix for the vmentry failure (penultimate patch),
> and has snowballed...
>
> I'm fairly confident that everything involving DEBUGCTL.BTF is broken, and
> there are definitely bugs with configuring DEBUGCTL.RTM (which really isn't
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
_
On 06/04/2018 05:53 PM, Razvan Cojocaru wrote:
> On 06/04/2018 04:59 PM, Andrew Cooper wrote:
>> Currently, there is a lot of functionality in the #DB intercepts, and some
>> repeated functionality in the *_inject_event() logic.
>>
>> The gdbsx code is implemented at both levels (albeit different
Hi all,
I tried to summarize this thread (also see
https://lists.xenproject.org/archives/html/xen-devel/2018-05/threads.html#01127),
CC'ing everyone that contributed or requested to be on the thread. I also
moved comments into
https://docs.google.com/document/d/1FbGV4ZZB9OU8SI4b9ntnM-l6NaQLND
On 06/04/2018 04:59 PM, Andrew Cooper wrote:
> Currently, there is a lot of functionality in the #DB intercepts, and some
> repeated functionality in the *_inject_event() logic.
>
> The gdbsx code is implemented at both levels (albeit differently for #BP,
> which is presumably due to the fact that
See the code comment for the details.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
Jun/Kevin: This workaround is as suggested by Gil, and there is expected to be
an SDM update discussing the corner case.
Note that, like elsewhere dealing with eflags.tf, th
Replace the few remaining uses with X86_DR6_* constants.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/pv/emul-priv-op.c | 2 +-
xen/arch/x86/traps.c | 2 +-
xen/include/asm-x86/debugreg.h | 17 -
3 files changed,
So this started as a small fix for the vmentry failure (penultimate patch),
and has snowballed...
I'm fairly confident that everything involving DEBUGCTL.BTF is broken, and
there are definitely bugs with configuring DEBUGCTL.RTM (which really isn't
helped by the fact that the GCC TSX intrinsics re
In particular, initialising %dr6 with the value 0 is buggy, because on
hardware supporting Transnational Memory, it will cause the sticky RTM bit to
be asserted, even though a debug event from a transaction hasn't actually been
observed.
Introduce X86_DR7_DEFAULT to match the existing X86_DR6_DEFA
c/s 4f36452b63 introduced a write to %dr6 in the #DB intercept case, but the
guests debug registers may be lazy at this point, at which point the guests
later attempt to read %dr6 will discard this value and use the older stale
value.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
All #DB exceptions result in an update of %dr6, but this isn't captured in
Xen's handling.
PV guests generally work by modifying %dr6 before raising #DB, whereas HVM
guests do nothing and have a single-step special case in the lowest levels of
{vmx,svm}_inject_event(). All of this is buggy, but i
No functional change (as curr->arch.debugreg[5] is zero when DE is clear), but
this change simplifies the following patch.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/x86_emulate.c | 24 +++-
1 file changed, 15 insertio
The current logic used to update %dr6 when injecting #DB is buggy. The
architectural behaviour is to overwrite B{0..3} (rather than accumulate) and
accumulate all other bits.
Introduce a new merge_dr6() helper, which also takes care of handing RTM
correctly.
Signed-off-by: Andrew Cooper
---
CC:
Reusing debugreg[5] for the PV emulated IO breakpoint information is confusing
to read. Instead, introduce a dr7_emul field in pv_vcpu for the pupose.
With the PV emulation out of the way, debugreg[4,5] are entirely unused and
don't need to be stored.
Rename debugreg[0..3] to dr[0..3] to reduce
The reserved bit calculations for %dr6 and %dr7 depend on whether the VM has
the Restricted Transnational Memory feature available.
Introduce adjust_dr{6,7}_rsvd() and replace the opencoded logic and constants
(except for DR_STATUS_RESERVED_ONE which is (mis)used elsewhere and will be
removed afte
* State adjustments (and debug tracing) for #DB/#BP/#PF should not be done
for `int $n` instructions. Updates to %cr2 occur even if the exception
combines to #DF.
* Don't opencode DR_STEP when updating %dr6.
* Simplify the logic for calling svm_emul_swint_injection() as in the common
c
On Tue, May 15, 2018 at 07:22:43PM +0100, Wei Liu wrote:
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 0826af8cbc..8e4b173d6f 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -241,6 +242,23 @@ AS_IF([test "x$ovmf" = "xy" -o -n "$ovmf_path" ], [
>
Currently, there is a lot of functionality in the #DB intercepts, and some
repeated functionality in the *_inject_event() logic.
The gdbsx code is implemented at both levels (albeit differently for #BP,
which is presumably due to the fact that the old emulator behaviour used to be
to move %rip for
flight 123676 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123122
Tests which are
On Tue, May 15, 2018 at 07:22:42PM +0100, Wei Liu wrote:
> diff --git a/tools/firmware/hvmloader/hvmloader.c
> b/tools/firmware/hvmloader/hvmloader.c
> index f603f68ded..f546cfb3ab 100644
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -368,7 +368,13
flight 123798 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123798/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 123670 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123670/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123569
test-amd64-amd64-xl-qemuu-win7-amd64
flight 74777 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74777/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 74754
test-armhf-armhf-armhf-sid-n
On 01/06/18 13:41, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
> while all the rest are exported as EXPORT_SYMBOL_GPL, thus
> effectively making it not possible for non-GPL driver modules
> to use grant table modu
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 29 May 2018 15:59
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v5 8/8] x86/domctl: Don't pause th
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 29 May 2018 15:59
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v5 7/8] x86/hvm: Introduce virid
> -Original Message-
> From: Alexandru Isaila [mailto:aisa...@bitdefender.com]
> Sent: 29 May 2018 15:59
> To: xen-de...@lists.xen.org
> Cc: Ian Jackson ; Wei Liu ;
> jbeul...@suse.com; Andrew Cooper ; Paul
> Durrant ; Alexandru Isaila
>
> Subject: [PATCH v5 5/8] x86/hvm: Introduce hvm_sav
flight 123655 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123655/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123554
test-amd64-amd64-xl
60 matches
Mail list logo
