[Xen-devel] [xen-4.9-testing test] 125605: regressions - FAIL

flight 125605 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125605/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 125253 REGR. vs. 124248

Re: [Xen-devel] [PATCH v2 19/21] xen/arm: introduce create_domUs

On Tue, 24 Jul 2018, Julien Grall wrote: > Hi Stefano, > > On 07/07/18 00:12, Stefano Stabellini wrote: > > Call a new function, "create_domUs", from setup_xen to start DomU VMs. > > > > Introduce support for the "xen,domU" compatible node on device tree. > > Create new DomU VMs based on the

[Xen-devel] [linux-3.18 test] 125600: regressions - FAIL

flight 125600 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125600/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-xsm 18 guest-localmigrate/x10 fail REGR. vs. 125138 Tests which are

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

On Fri, 27 Jul 2018, Julien Grall wrote: > Hi Stefano, > Sorry for the top posting. > > I think Andrii made a good point. With your new code MPSOC will get built on > Arm 32 bit as well. > > This was not the case before this patch. > > So I would like at least that to be fixed before any

Re: [Xen-devel] [PATCH v2 17/21] xen/arm: refactor vpl011_data_avail

On Tue, 24 Jul 2018, Julien Grall wrote: > Hi Stefano, > > On 07/07/18 00:12, Stefano Stabellini wrote: > > Move the code to calculate in_fifo_level and out_fifo_level out of > > vpl011_data_avail, to the caller. > > This change will make it possible to reuse vpl011_data_avail with > > different

[Xen-devel] [qemu-mainline test] 125598: regressions - trouble: broken/fail/pass

flight 125598 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/125598/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-rtds broken test-amd64-i386-qemuu-rhel6hvm-amd 10

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

Hi Stefano, Sorry for the top posting. I think Andrii made a good point. With your new code MPSOC will get built on Arm 32 bit as well. This was not the case before this patch. So I would like at least that to be fixed before any commit. Cheers, On Fri, 27 Jul 2018, 22:38 Stefano Stabellini,

Re: [Xen-devel] [PATCH v2 18/21] xen/arm: Allow vpl011 to be used by DomU

On Fri, 27 Jul 2018, Julien Grall wrote: > Hi Stefano, > > On 27/07/18 01:10, Stefano Stabellini wrote: > > On Tue, 24 Jul 2018, Julien Grall wrote: > > > On 07/07/18 00:12, Stefano Stabellini wrote: > > > > +VPL011_UNLOCK(d, flags); > > > > +} > > > > + > > > > +static void

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

On Fri, 27 Jul 2018, Andrii Anisov wrote: > Hello Stefano, > > On 27.07.18 20:11, Stefano Stabellini wrote: > > Yes, it does. > > > > Let's say that you chose ALL at the menu choice. MPSOC_PLATFORM gets > > selected, that trigger the build of the MPSOC platform file. > > > > If you do "make

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

This run is configured for baseline tests only. flight 75018 ovmf real [real] http://osstest.xensource.com/osstest/logs/75018/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75017

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

flight 125585 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125585/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 123554

Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually

On 07/27/2018 05:56 AM, Xiao Liang wrote: > When loading module manually, after call xenbus_switch_state to initializes > the state of the netfront device, the driver state did not change so fast > that may lead no dev created in latest kernel. This patch adds wait to make > sure xenbus knows the

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

Hello Stefano, On 27.07.18 20:11, Stefano Stabellini wrote: Yes, it does. Let's say that you chose ALL at the menu choice. MPSOC_PLATFORM gets selected, that trigger the build of the MPSOC platform file. If you do "make menuconfig" again and select RCAR3 instead, MPSOC_PLATFORM is removed

[Xen-devel] [qemu-upstream-4.11-testing baseline-only test] 75016: tolerable FAIL

This run is configured for baseline tests only. flight 75016 qemu-upstream-4.11-testing real [real] http://osstest.xensource.com/osstest/logs/75016/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

On Fri, 27 Jul 2018, Andrii Anisov wrote: > On 27.07.18 01:46, Stefano Stabellini wrote: > > On Tue, 24 Jul 2018, Andrii Anisov wrote: > > > On 07.07.18 02:13, Stefano Stabellini wrote: > > > > Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3, > > > > MPSOC and ALL. They

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

This run is configured for baseline tests only. flight 75017 ovmf real [real] http://osstest.xensource.com/osstest/logs/75017/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75014

[Xen-devel] Xen 4.12 Development Update

This email only tracks big items for xen.git tree. Please reply for items you would like to see in 4.12 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a

Re: [Xen-devel] Xen 4.12 release planning

On 27/07/18 17:50, Stefano Stabellini wrote: > On Fri, 27 Jul 2018, Juergen Gross wrote: >> On 27/07/18 12:32, Lars Kurth wrote: >>> >>> On 27 Jul 2018, at 08:51, Juergen Gross >>> > wrote: On 27/07/18 00:13, Stefano Stabellini wrote: > On Wed, 25 Jul

Re: [Xen-devel] Xen 4.12 release planning

On Fri, 27 Jul 2018, Juergen Gross wrote: > On 27/07/18 12:32, Lars Kurth wrote: > > > > > >> On 27 Jul 2018, at 08:51, Juergen Gross >> > wrote: > >> > >> On 27/07/18 00:13, Stefano Stabellini wrote: > >>> On Wed, 25 Jul 2018, Juergen Gross wrote: > Its time to

[Xen-devel] [PATCH 0/4] x86/iommu: PVH Dom0 workarounds for missing RMRR/IRSV entries

Hello, The following series implement a workaround for missing RMRR/IRSV entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd option, which is generalized to be used by both VTd and AMD-Vi hardware. The PVH workaround identity maps all regions marked as reserved in the memory

[Xen-devel] [PATCH 1/4] iommu: remove unneeded return from iommu_hwdom_init

Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich --- xen/drivers/passthrough/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index 2c44fabf99..70d218f910 100644 --- a/xen/drivers/passthrough/iommu.c

[Xen-devel] [PATCH 3/4] x86/iommu: reorder conditions used in the inclusive iommu mappings

In order to place all the map conditions in a single if ... else conditional. No functional change. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich --- xen/drivers/passthrough/x86/iommu.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git

[Xen-devel] [PATCH 2/4] iommu: generalize iommu_inclusive_mapping

Introduce a new iommu=inclusive generic option that supersedes iommu_inclusive_mapping. This should be a non-functional change on Intel hardware, while AMD hardware will gain the same functionality of mapping almost everything below the 4GB boundary. Note that is a noop for ARM hardware.

[Xen-devel] [PATCH 4/4] x86/iommu: add PVH support to the inclusive options

Several people have reported hardware issues (malfunctioning USB controllers) due to iommu page faults. Those faults are caused by missing RMRR (VTd) or IRVS (AMD-Vi) entries in the ACPI tables. Those can be worked around on VTd hardware by manually adding RMRR entries on the command line, this is

[Xen-devel] [PATCH v4 25/32] libxl_exec: Add libxl__spawn_initiate_failure

This function can be use by user libxl__spawn_* when they setup a notification other than xenstore. The parent can already called success via libxl__spawn_initiate_detach(), this new function can be used for failure instead of waiting for the timeout. Signed-off-by: Anthony PERARD ---

[Xen-devel] [PATCH v4 20/32] libxl_qmp: Handle write to QMP socket

The libxl__ev_qmp_* will now send the command to QEMU when the socket is ready for writes. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_qmp.c | 44 + 1 file changed, 44 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c

[Xen-devel] [PATCH v4 13/32] libxl_qmp: Connect to QMP socket

This is a first patch to implement libxl__ev_qmp, it only connect to the QMP socket of QEMU and register a fd callback that does nothing. Callback functions will be implemented in following patches. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.h | 11 +

[Xen-devel] [PATCH v4 12/32] libxl: Design of an async API to issue QMP commands to QEMU

All the functions will be implemented in later patches. This patch includes the API that libxl can use to send QMP commands to QEMU. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.h | 76 +++- 1 file changed, 74 insertions(+), 2 deletions(-) diff

[Xen-devel] [PATCH v4 10/32] libxl_json: constify libxl__json_object_to_yajl_gen arguments

Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_internal.h | 2 +- tools/libxl/libxl_json.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index ab1de80522..72ab177ce5 100644 ---

[Xen-devel] [PATCH v4 32/32] libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp

So when QEMU is involve, the operation will be asynchrone and will finish later. This path reimplement libxl__qmp_insert_cdrom to make use of the new libxl__ev_qmp API. It also open the cdrom in libxl and send the FD via QMP, so QEMU doesn't need access permition on the cdrom file.

[Xen-devel] [PATCH v4 24/32] libxl_qmp: Disable beautify for QMP generated cmd

There is no need for it. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_qmp.c | 5 + 1 file changed, 5 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 83afce3192..d7aedb56a8 100644 --- a/tools/libxl/libxl_qmp.c +++

[Xen-devel] [PATCH v4 26/32] libxl_dm: Pre-open QMP socket for QEMU

When starting QEMU with dm_restrict=1, pre-open the QMP socket before exec QEMU. That socket will be usefull to findout if QEMU is ready, and pre-opening it means that libxl can connect to it without waiting for QEMU to create it. The pre-openning is conditionnal, based on the use of dm_restrict

[Xen-devel] [PATCH v4 23/32] libxl_qmp: Respond to QMP greeting

Signed-off-by: Anthony PERARD --- tools/libxl/libxl_qmp.c | 36 ++-- 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index e649b8054d..83afce3192 100644 --- a/tools/libxl/libxl_qmp.c +++

[Xen-devel] [PATCH v4 21/32] libxl_qmp: Simplify qmp_response_type() prototype

Remove the libxl__qmp_handler* argument so the function can be reused later in a different context. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_qmp.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_qmp.c

[Xen-devel] [PATCH v4 19/32] libxl_qmp: Prepare the command to be sent

The actual sent will be done in a separate patch. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.h | 4 tools/libxl/libxl_qmp.c | 37 2 files changed, 41 insertions(+) diff --git a/tools/libxl/libxl_internal.h

[Xen-devel] [PATCH v4 18/32] libxl_qmp: Separate QMP message generation from qmp_send_prepare

To be able to re-use qmp_prepare_qmp_cmd with libxl__ev_qmp. Also, add the QMP end of command '\r\n' into the generated string. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_qmp.c | 62 + 1 file changed, 44 insertions(+), 18 deletions(-) diff

[Xen-devel] [PATCH v4 27/32] libxl: QEMU startup sync based on QMP

This is only activated when dm_restrict=1, as explained in the previous patch "libxl_dm: Pre-open QMP socket for QEMU" Signed-off-by: Anthony PERARD --- Notes: v4: moved to libxl__dm_spawn_* from libxl__spawn_* tools/libxl/libxl_dm.c | 52

[Xen-devel] [PATCH v4 15/32] libxl_json: Enable yajl_allow_trailing_garbage

This allow to parse a string that is not NUL-terminated. With that options disabled, YAJL v2 would look ahead on completion to find out if there is more to parse. YAJL v1 doesn't have this behavior. Any function function that allocate a yajl_handle via this function either parse a NUL-terminated

[Xen-devel] [PATCH v4 16/32] libxl_json: libxl__json_object_to_json

Allow to generate a JSON string from a libxl__json_object, usefull for debugging. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_internal.h | 3 +++ tools/libxl/libxl_json.c | 36 2 files changed, 39 insertions(+) diff --git

[Xen-devel] [PATCH v4 17/32] libxl_qmp: Parse JSON input from QMP

Signed-off-by: Anthony PERARD --- Notes: v4: simplification of the patch due to use of a single allocated space for the receive buffer. tools/libxl/libxl_qmp.c | 54 + 1 file changed, 54 insertions(+) diff --git

[Xen-devel] [PATCH v4 14/32] libxl_qmp: Implement fd callback and read data

First step into taking care of the input from QEMU's QMP socket. For now, we read data and store them in a buffer. Parsing of the data will be done in the following patches. Signed-off-by: Anthony PERARD --- Notes: v4: remove use of a linked list of receive buffer, and use realloc

[Xen-devel] [PATCH v4 28/32] libxl_qmp: Store advertised QEMU version in libxl__ev_qmp

This will be used in a later patch. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_internal.h | 7 +++ tools/libxl/libxl_qmp.c | 16 2 files changed, 23 insertions(+) diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index

[Xen-devel] [PATCH v4 31/32] libxl_disk: Cut libxl_cdrom_insert into step

This is to prepare libxl_cdrom_insert to be able to send commands to QEMU via the libxl__ev_qmp. The next patch is going to make use of it. Signed-off-by: Anthony PERARD --- tools/libxl/libxl_disk.c | 194 +++ 1 file changed, 137 insertions(+), 57

[Xen-devel] [PATCH v4 30/32] libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp

The re-implementation is done because we want to be able to send the file description that QEMU can use to save its state. When QEMU is restricted, it would not be able to write to a path. This replace both libxl__qmp_stop() and libxl__qmp_save(). qmp_qemu_check_version() was only used by

[Xen-devel] [PATCH v4 29/32] libxl: Change libxl__domain_suspend_device_model() to be async.

This create an extra step for the two calls sites of the function. Signed-off-by: Anthony PERARD --- libxl_domain_soft_reset() haven't been tested, as it doesn't appear to possible to call the function from xl. --- tools/libxl/libxl_create.c | 30 ++

[Xen-devel] [PATCH v4 11/32] libxl_dm: Add libxl__qemu_qmp_path()

... which generate the path to a QMP socket that libxl uses. Signed-off-by: Anthony PERARD --- Notes: New in v4. tools/libxl/libxl_dm.c | 9 +++-- tools/libxl/libxl_internal.h | 1 + 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_dm.c

[Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle messages from QEMU

This will handles messages received, and calls callbacks associated with the libxl__ev_qmp when the expected response is received. This also print error messages from QMP on behalf of the callback. Signed-off-by: Anthony PERARD --- Notes: v4: Provide an libxl error code to

[Xen-devel] [PATCH RFC] x86/HVM: also stuff RSB upon exit to guest

In order to mostly eliminate abuse of what Xen leaves in the RSB by guest level attackers, fill the RSB with almost-NULL pointers right before entering guest context. The placement of the initialization code is intentional: If it was put in e.g. hvm_enable(), we'd have to be more careful wrt.

Re: [Xen-devel] [PATCH RFC] tools/kdd: avoid adversarial optimisation hazard

One interesting observation is that if I revert 2de2b10b225 which turns the type of offset from uint32_t back to uint64_t, kdd.c will build with 32 bit, but then of course 64 bit build is broken. :-/ Wei. ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

>>> On 27.07.18 at 11:37, wrote: > Before 4.9, the calls to {hvm,pv}_cpuid() are needed to because the > information can't be read directly out of d->arch.cpuids[]. The restore > boolean is needed because this array will be empty at the time it is > accessed on the restore path. Would you mind

[Xen-devel] [PATCH v4 08/32] libxl: Add libxl__prepare_sockaddr_un() helper

There is going to be a few more users that want to use UNIX socket, this helper is to prepare the `struct sockaddr_un` and check that the path isn't too long. Also start to use it in libxl_qmp.c. Signed-off-by: Anthony PERARD --- Notes: New in v4. tools/libxl/libxl_internal.h | 4

[Xen-devel] [PATCH v4 03/32] libxl_qmp: Fix use of DEBUG_RECEIVED

This patch fix complilation error with #define DEBUG_RECEIVED of the macro DEBUG_REPORT_RECEIVED. error: field precision specifier ‘.*’ expects argument of type ‘int’, but argument 9 has type ‘ssize_t {aka long int}’ Signed-off-by: Anthony PERARD Acked-by: Wei Liu Acked-by: Ian Jackson ---

[Xen-devel] [PATCH v4 09/32] libxl_qmp: Remove unused yajl_ctx from handler

Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- Notes: v4: - Acked - Fix subject s/form/from/ tools/libxl/libxl_qmp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 7965ee37b9..c5e05e5679 100644 ---

[Xen-devel] [PATCH v4 07/32] libxl_qmp: Move struct sockaddr_un variable to qmp_open()

This variable is only used once, no need to keep it in the handler. Also fix coding style (remove space after sizeof). And allow strncpy to use all the space in sun_path. Signed-off-by: Anthony PERARD --- Notes: v4: actually allow strncpy to use all the space in sun_path.

[Xen-devel] [PATCH v4 05/32] libxl_qmp: Move the buffer realloc to the same scope level as read

In qmp_next(), the inner loop should only try to parse messages from QMP, if there is more than one. The handling of the receive buffer ('incomplete'), should be done at the same scope level as read(). It doesn't need to be handle more that once after a read. Before this patch, when on message

[Xen-devel] [PATCH v4 02/32] libxl_qmp: Documentation of the logic of the QMP client

Signed-off-by: Anthony PERARD Acked-by: Wei Liu Acked-by: Ian Jackson --- Notes: v3: - Add documentation of the qmp_callback_t type. New in RFC v2 tools/libxl/libxl_qmp.c | 42 + 1 file changed, 42 insertions(+) diff --git

[Xen-devel] [PATCH v4 06/32] libxl_qmp: Add a warning to not trust QEMU

... even if it is not the case for the current code. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- tools/libxl/libxl_qmp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index 5b608f47e5..987bf0232e 100644 ---

[Xen-devel] [PATCH v4 04/32] libxl_json: fix build with DEBUG_ANSWER

Also replace LIBXL__LOG_DEBUG by XTL_DEBUG, because it's shorter and more often used in libxl. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- Notes: v4: explain s/LIBXL__LOG_DEBUG/XTL_DEBUG/. acked tools/libxl/libxl_json.c | 4 ++-- 1 file changed, 2

[Xen-devel] [PATCH v4 00/32] libxl: Enable save/restore/migration of a restricted QEMU + libxl__ev_qmp_*

In order for libxl to be able to manage QEMU while it is restricted, a few changes are needed. We need a new way to get a startup notification from QEMU as xenstore may not be accessible when QEMU is ready. We also need to a different way to have QEMU save it's state and to insert cdrom as a

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

flight 125586 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125586/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt

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

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

Re: [Xen-devel] [PATCH v3 2/2] x86/xstate: Make errors in xstate calculations more obvious by crashing the domain

On 27/07/18 14:24, Jan Beulich wrote: On 19.07.18 at 13:44, wrote: >> --- a/xen/arch/x86/xstate.c >> +++ b/xen/arch/x86/xstate.c >> @@ -707,12 +707,32 @@ int handle_xsetbv(u32 index, u64 new_bv) >> if ( index != XCR_XFEATURE_ENABLED_MASK ) >> return -EOPNOTSUPP; >> >> -if

Re: [Xen-devel] [PATCH v3 2/2] x86/xstate: Make errors in xstate calculations more obvious by crashing the domain

>>> On 19.07.18 at 13:44, wrote: > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -707,12 +707,32 @@ int handle_xsetbv(u32 index, u64 new_bv) > if ( index != XCR_XFEATURE_ENABLED_MASK ) > return -EOPNOTSUPP; > > -if ( (new_bv & ~xcr0_max) || > - (new_bv

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

On 27/07/18 12:34, Andrii Anisov wrote: Hello Julien, On 27.07.18 14:27, Julien Grall wrote: There are no need for duplication. You can instead do something like: config ALL_64     default (ALL && ARM_64) config ALL_32     default (ALL && ARM_32) config MPSOC_PLATFORM     bool    

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

Hello Julien, On 27.07.18 14:27, Julien Grall wrote: There are no need for duplication. You can instead do something like: config ALL_64     default (ALL && ARM_64) config ALL_32     default (ALL && ARM_32) config MPSOC_PLATFORM     bool     default (ALL_64 || MPSOC) Yep, but then "config

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

Hi, On 27/07/18 12:21, Andrii Anisov wrote: I would suggest something like: diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 06ba4a4..794f06e 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -218,6 +218,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR  config

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

I would suggest something like: diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 06ba4a4..794f06e 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -218,6 +218,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR  config ARM32_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_32 &&

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

Hi, On 27/07/18 11:30, Andrii Anisov wrote: On 27.07.18 01:46, Stefano Stabellini wrote: On 07.07.18 02:13, Stefano Stabellini wrote: Shouldn't MPSOC_PLATFORM be dependent on ARM64? Yes, and it is, see "config MPSOC" few lines above. Few lines above, only "config MPSOC" is dependent on ARM64.

[Xen-devel] [freebsd-master test] 125620: regressions - trouble: blocked/fail

flight 125620 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125620/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317 Tests which did

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

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

Re: [Xen-devel] [PATCH v2 18/21] xen/arm: Allow vpl011 to be used by DomU

Hi Stefano, On 27/07/18 01:10, Stefano Stabellini wrote: On Tue, 24 Jul 2018, Julien Grall wrote: On 07/07/18 00:12, Stefano Stabellini wrote: +VPL011_UNLOCK(d, flags); +} + +static void vpl011_write_data_noring(struct domain *d, uint8_t data) +{ +unsigned long flags; +struct

Re: [Xen-devel] Xen 4.12 release planning

On 27/07/18 12:32, Lars Kurth wrote: > > >> On 27 Jul 2018, at 08:51, Juergen Gross > > wrote: >> >> On 27/07/18 00:13, Stefano Stabellini wrote: >>> On Wed, 25 Jul 2018, Juergen Gross wrote: Its time to plan the Xen 4.12 release dates. There have been

Re: [Xen-devel] [PATCH RFC] tools/kdd: avoid adversarial optimisation hazard

On Thu, Jul 26, 2018 at 01:37:45PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH RFC] tools/kdd: avoid adversarial optimisation > hazard"): > > There have been two attempts to fix kdd build with gcc 8.1 > > (437e00fe and 2de2b10b), but building with gcc 8.1 32 bit non-debug > > build still

Re: [Xen-devel] Xen 4.12 release planning

> On 27 Jul 2018, at 08:51, Juergen Gross wrote: > > On 27/07/18 00:13, Stefano Stabellini wrote: >> On Wed, 25 Jul 2018, Juergen Gross wrote: >>> Its time to plan the Xen 4.12 release dates. >>> >>> There have been concerns with the schedule of 6 months between releases, >>> as this scheme

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

Hello Stefano, On 27.07.18 01:46, Stefano Stabellini wrote: On Tue, 24 Jul 2018, Andrii Anisov wrote: On 07.07.18 02:13, Stefano Stabellini wrote: Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3, MPSOC and ALL. They enable the required options for their hardware

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

>>> On 27.07.18 at 11:37, wrote: > On 27/07/18 10:28, Jan Beulich wrote: > On 19.07.18 at 13:44, wrote: >>> It turns out that Xen has never enforced that a domain remain within the >>> xstate features advertised in CPUID. >>> >>> The check of new_bv against xfeature_mask ensures that a

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

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

[Xen-devel] [xen-4.8-testing test] 125582: regressions - FAIL

flight 125582 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125582/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken in 125165 build-armhf-libvirt

[Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually

When loading module manually, after call xenbus_switch_state to initializes the state of the netfront device, the driver state did not change so fast that may lead no dev created in latest kernel. This patch adds wait to make sure xenbus knows the driver is not in closed/unknown state. Current

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

On 27/07/18 10:28, Jan Beulich wrote: On 19.07.18 at 13:44, wrote: >> It turns out that Xen has never enforced that a domain remain within the >> xstate features advertised in CPUID. >> >> The check of new_bv against xfeature_mask ensures that a domain stays within >> the set of features

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

>>> On 19.07.18 at 13:44, wrote: > It turns out that Xen has never enforced that a domain remain within the > xstate features advertised in CPUID. > > The check of new_bv against xfeature_mask ensures that a domain stays within > the set of features that Xen has enabled in hardware (and

Re: [Xen-devel] PVH dom0 creation fails - the system freezes

On Fri, Jul 27, 2018 at 08:48:32AM +, Bercaru, Gabriel wrote: > I tried the patch and it fixes the unusable USB devices problem. > However, I captured the boot messages and the "IOMMU mapping failed" printk > seems to have been executed on each iteration of the loop. > > I attached a small

[Xen-devel] [distros-debian-jessie test] 75015: tolerable FAIL

flight 75015 distros-debian-jessie real [real] http://osstest.xensource.com/osstest/logs/75015/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74991 baseline version: flight

Re: [Xen-devel] [xen-unstable test] 125573: regressions - FAIL

On Fri, Jul 27, 2018 at 02:26:22AM -0600, Jan Beulich wrote: > >>> On 27.07.18 at 04:29, wrote: > > flight 125573 xen-unstable real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/125573/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including

Re: [Xen-devel] [PATCH v3] firmware/shim : filter output files during Xen tree setup

>>> On 26.07.18 at 23:16, wrote: > Exclude named output files from the Xen tree setup. > > The linkfarm.stamp content will differ between top level "make" > and "make install" invocations, due to the introduction of these > output files that are produced during the "make" build. > > Filter

Re: [Xen-devel] [xen-unstable test] 125573: regressions - FAIL

>>> On 27.07.18 at 04:29, wrote: > flight 125573 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/125573/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-qemuu-rhel6hvm-amd 10

Re: [Xen-devel] [xen-4.9-testing test] 125570: regressions - FAIL

>>> On 27.07.18 at 02:01, wrote: > flight 125570 xen-4.9-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/125570/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >[...] > test-amd64-i386-xl-qemut-ws16-amd64

[Xen-devel] [qemu-upstream-4.11-testing test] 125575: tolerable FAIL - PUSHED

flight 125575 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125575/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 125508 pass in 125575

Re: [Xen-devel] Xen 4.12 release planning

On 27/07/18 00:13, Stefano Stabellini wrote: > On Wed, 25 Jul 2018, Juergen Gross wrote: >> Its time to plan the Xen 4.12 release dates. >> >> There have been concerns with the schedule of 6 months between releases, >> as this scheme is leading to too many supported versions of Xen at a >> time.

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

This run is configured for baseline tests only. flight 75014 ovmf real [real] http://osstest.xensource.com/osstest/logs/75014/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75013