Re: [Xen-devel] [PATCH v2] x86/monitor: Notify monitor if an emulation fails.

On Tue, Jul 11, 2017 at 8:53 AM, Petre Pircalabu wrote: > If case of a vm_event with the emulate_flags set, if the instruction > cannot be emulated, the monitor should be notified instead of directly > injecting a hw exception. > This behavior can be used to re-execute

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

On 2017年07月08日 00:16, Julien Grall wrote: > Hi, > > On 06/07/17 07:20, Lan Tianyu wrote: >> On 2017年07月05日 21:25, Julien Grall wrote: >>> Furthermore, on ARM we would be able to create the vIOMMU but it would >>> be unusable. Indeed, IOMMU are only used to protect devices. But you >>> don't see

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

On Tue, 11 Jul 2017 15:35:15 -0700, Linus Torvalds wrote: > I do suspect I'll make "-Wformat-truncation" (as opposed to > "-Wformat-overflow") be a "V=1" kind of warning. But let's see how > many of these we can fix, ok? Somehow related - what's the stand on -Wimplicit-fallthrough? I run into

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

Hi Linus, > At the same time, others aren't quite as insane, and in many cases the > warnings might be easy to just fix. > > And some actually look valid, although they might still require odd input: > > net/bluetooth/smp.c: In function ‘le_max_key_size_read’: > net/bluetooth/smp.c:3372:29:

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

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

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

On Tue, Jul 11, 2017 at 06:41:29PM +, Bart Van Assche wrote: > On Wed, 2017-07-12 at 02:20 +0800, Ming Lei wrote: > > This interfaces will be removed soon, so use quiesce and > > unquiesce instead, which should be more safe. > > > > The only one usage will be removed in the following > >

[Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

This interfaces will be removed soon, so use quiesce and unquiesce instead, which should be more safe. The only one usage will be removed in the following congestion control patches. Cc: Konrad Rzeszutek Wilk Cc: "Roger Pau Monné" Cc: Boris

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

On Wed, 2017-07-12 at 02:20 +0800, Ming Lei wrote: > This interfaces will be removed soon, so use quiesce and > unquiesce instead, which should be more safe. > > The only one usage will be removed in the following > congestion control patches. Hello Ming, The title of this patch is misleading

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

On Tue, Jul 11, 2017 at 02:41:05PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote: > > This interfaces will be removed soon, so use quiesce and > > unquiesce instead, which should be more safe. > > 'should be'? That does not sound encouraging?

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

On Tue, Jul 11, 2017 at 11:24:44PM +0200, Roger Pau Monné wrote: > On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote: > > This interfaces will be removed soon, so use quiesce and > > unquiesce instead, which should be more safe. > > > > The only one usage will be removed in the following >

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

On Tue, Jul 11, 2017 at 06:41:29PM +, Bart Van Assche wrote: > On Wed, 2017-07-12 at 02:20 +0800, Ming Lei wrote: > > This interfaces will be removed soon, so use quiesce and > > unquiesce instead, which should be more safe. > > > > The only one usage will be removed in the following > >

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

On Tue, Jul 11, 2017 at 8:17 PM, Linus Torvalds wrote: > > If that's the case, I'd prefer just turning off the format-truncation > (but not overflow) warning with '-Wno-format-trunction". Doing KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation) in

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

On Tue, Jul 11, 2017 at 8:10 PM, Guenter Roeck wrote: > > The hwmon warnings are all about supporting no more than 9,999 sensors > (applesmc) to 999,999,999 sensors (scpi) of a given type. Yeah, I think that's enough. > Easy "fix" would be to replace snprintf() with

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

On 2017年07月08日 00:08, Julien Grall wrote: >> Because we now just have onE vIOMMU, all virtual interrupt will be bound >> to it. If need to support mult-vIOMMU, we can add device-scope >> field(sbdf array or some thing like that) in the structure and specify >> what devices should be under one

Re: [Xen-devel] Lots of new warnings with gcc-7.1.1

On 07/11/2017 03:35 PM, Linus Torvalds wrote: [ Very random list of maintainers and mailing lists, at least partially by number of warnings generated by gcc-7.1.1 that is then correlated with the get_maintainers script ] So I upgraded one of my boxes to F26, which upgraded the compiler to

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

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

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

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

Re: [Xen-devel] [x86/time] f61a8e12b5: ACPI_Error:Table[DMAR]is_not_invalidated_during_early_boot_stage(#/tbxface-#)

Hi, Xiaolong Thank you very much for testing. I have got the reason why the ACPI error happened and will give a fix patch below. Also cc ACPI maintainers.. At 07/08/2017 11:48 AM, kernel test robot wrote: FYI, we noticed the following commit: commit: f61a8e12b5972879f8decfe059e54c813dc4416b

[Xen-devel] [PATCH v9 7/7] tools/xen-mceinj: add support of injecting LMCE

If option '-l' or '--lmce' is specified and the host supports LMCE, xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c' is not present). Signed-off-by: Haozhong Zhang Acked-by: Wei Liu --- Cc: Ian Jackson

[Xen-devel] [PATCH v9 5/7] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/cpu/mcheck/mce.c | 24 +++-

[Xen-devel] [PATCH v9 2/7] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest to read/write MSR_IA32_MCG_EXT_CTL. Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper ---

[Xen-devel] [PATCH v9 6/7] tools/libxc: add support of injecting MC# to specified CPUs

Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the current xc_mca_op() does not use this feature and not provide an interface to callers. This commit add a new xc_mca_op_inject_v2() that receives a cpumap providing the set of target CPUs. Signed-off-by: Haozhong Zhang

[Xen-devel] [PATCH v9 1/7] x86/domctl: generalize the restore of vMCE parameters

vMCE parameters in struct xen_domctl_ext_vcpucontext were extended in the past, and is likely to be extended in the future. When migrating a PV domain from old Xen, XEN_DOMCTL_set_ext_vcpucontext should handle the differences. Instead of adding ad-hoc handling code at each extension, we introduce

[Xen-devel] [PATCH v9 0/7] Add LMCE support

Changes in v9: * Minor updates in patch 1 per Jan's comments. * Collect Jan's R-b in patch 2. Haozhong Zhang (7): [M ] x86/domctl: generalize the restore of vMCE parameters [ R ] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL [ R ] x86/vmce: enable injecting LMCE to guest on Intel host [

[Xen-devel] [PATCH v9 4/7] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP. By default, LMCE is not exposed to guest so as to keep the backwards migration compatibility. Signed-off-by: Haozhong Zhang

[Xen-devel] [PATCH v9 3/7] x86/vmce: enable injecting LMCE to guest on Intel host

Inject LMCE to guest if the host MCE is LMCE and the affected vcpu is known. Otherwise, broadcast MCE to all vcpus on Intel host. Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

Hi Julien, Thanks for pointing out. I'll move to x86 specific. I've cc-ed all maintainers reported by ./scripts/get_maintainer.pl, looks this script doesn't report all maintainers. Sorry. I'll add ARM maintainers next time. Thanks, -Kai On 7/12/2017 8:14 AM, Julien Grall wrote: Hi, On

[Xen-devel] [seabios baseline-only test] 71681: regressions - FAIL

This run is configured for baseline tests only. flight 71681 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71681/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17

Re: [Xen-devel] [PATCH v3] xen-platform: separate unplugging of NVMe disks

On Mon, 10 Jul 2017, Anthony PERARD wrote: > Hi Stefano, > > Looks like this patch can be applied. Thank you for pointing it out to me, because this email has inexplicably disappeared from my inbox. I have now marked it appropriately to be committed. > > On Fri, Mar 24, 2017 at 01:40:25PM

[Xen-devel] Lots of new warnings with gcc-7.1.1

[ Very random list of maintainers and mailing lists, at least partially by number of warnings generated by gcc-7.1.1 that is then correlated with the get_maintainers script ] So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1 Which in turn means that my nice clean

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

flight 111673 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 REGR. vs. 110441

[Xen-devel] [ovmf test] 111694: regressions - FAIL

flight 111694 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111694/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 111665 build-i386-xsm

[Xen-devel] [seabios test] 111687: tolerable FAIL - PUSHED

flight 111687 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/111687/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 111330 test-amd64-i386-xl-qemuu-win7-amd64 17

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

flight 111667 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/111667/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 111403

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote: > This interfaces will be removed soon, so use quiesce and > unquiesce instead, which should be more safe. > > The only one usage will be removed in the following > congestion control patches. Would it be better to simply fix

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-qcow2

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-qcow2 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git

Re: [Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

On Tue, Jul 11, 2017 at 02:06:09PM -0600, Jan Beulich wrote: > >>> Konrad Rzeszutek Wilk 07/11/17 6:53 PM >>> > >This issue was observed on ARM32 with a cross compiler for the > >livepatches. Mainly the livepatches .data section size was not > >aligned to the section

Re: [Xen-devel] [PATCH v8 2/7] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

>>> Haozhong Zhang 07/10/17 4:53 AM >>> >If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest >to read/write MSR_IA32_MCG_EXT_CTL. > >Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v8 1/7] x86/domctl: generalize the restore of vMCE parameters

>>> Haozhong Zhang 07/10/17 4:53 AM >>> >--- a/xen/arch/x86/domctl.c >+++ b/xen/arch/x86/domctl.c >@@ -302,6 +302,42 @@ static int update_domain_cpuid_info(struct domain *d, >return 0; >} > >+static int vcpu_set_vmce(struct vcpu *v, >+

Re: [Xen-devel] [PATCH 04/15] xen: mm: add ioremap_cache

Hi, On 07/09/2017 09:10 AM, Kai Huang wrote: Currently Xen only has non-cacheable version of ioremap. Although EPC is reported as reserved memory in e820 but it can be mapped as cacheable. This patch adds ioremap_cache (cacheable version of ioremap). Signed-off-by: Kai Huang

Re: [Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

>>> Konrad Rzeszutek Wilk 07/11/17 6:53 PM >>> >This issue was observed on ARM32 with a cross compiler for the >livepatches. Mainly the livepatches .data section size was not >aligned to the section alignment: > >ARM32 native: >Contents of section .rodata: > 68695f66

Re: [Xen-devel] [PATCH v1 2/3] livepatch: Include sizes when an mismatch occurs

>>> Konrad Rzeszutek Wilk 07/11/17 6:53 PM >>> >--- a/xen/common/livepatch.c >+++ b/xen/common/livepatch.c >@@ -520,8 +520,8 @@ static int prepare_payload(struct payload *payload, >ASSERT(sec); >if ( sec->sec->sh_size % sizeof(*payload->funcs) ) >{ >-

Re: [Xen-devel] [PATCH v1 1/3] xen/livepatch: Tighten alignment checks.

>>> Konrad Rzeszutek Wilk 07/11/17 6:53 PM >>> >--- a/xen/common/livepatch.c >+++ b/xen/common/livepatch.c >@@ -406,6 +406,15 @@ static int move_payload(struct payload *payload, struct >livepatch_elf *elf) >ASSERT(offset[i] != UINT_MAX); >

[Xen-devel] [PATCH][xen-next] xen/pvcalls: fix null pointer reference on sock_release call

From: Colin Ian King Currently a sock_release on map->sock will result in a null pointer deference on map when map is null. Instead, the sock_relase sould be on sock and not map->sock. Detected by CoverityScan, CID#1450169 ("Dereference after null check") Fixes:

[Xen-devel] [xen-unstable test] 111664: regressions - FAIL

flight 111664 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/111664/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111645 REGR. vs. 111506

[Xen-devel] [ovmf test] 111688: regressions - FAIL

flight 111688 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111688/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 111665 build-i386-xsm

Re: [Xen-devel] [PATCH 1/6] xen-blkfront: avoid to use start/stop queue

On Wed, Jul 12, 2017 at 02:20:58AM +0800, Ming Lei wrote: > This interfaces will be removed soon, so use quiesce and > unquiesce instead, which should be more safe. 'should be'? That does not sound encouraging? > > The only one usage will be removed in the following > congestion control

[Xen-devel] [PATCH v1 2/3] livepatch: Include sizes when an mismatch occurs

If the .bug.frames.X or .livepatch.funcs sizes are different than what the hypervisor expects - we fail the payload. To help in diagnosing this include the expected and the payload sizes. Signed-off-by: Konrad Rzeszutek Wilk --- xen/common/livepatch.c | 9 + 1

[Xen-devel] [PATCH v1 1/3] xen/livepatch: Tighten alignment checks.

The ELF specification mentions nothing about the sh_size being modulo the sh_addralign. Only that sh_addr MUST be aligned on sh_addralign if sh_addralign is not zero or one. We on loading did not take this in-to account so this patch adds two checks: One on the ELF file itself as it is being

[Xen-devel] [PATCH v1 3/3] xen/livepatch/ARM32: Don't crash on livepatches loaded with wrong alignment.

This issue was observed on ARM32 with a cross compiler for the livepatches. Mainly the livepatches .data section size was not aligned to the section alignment: ARM32 native: Contents of section .rodata: 68695f66 756e6300 63686563 6b5f666e hi_func.check_fn 0010 6300 78656e5f 65787472

[Xen-devel] [PATCH] Livepatch ARM32 fixes thanks to cross-compiler.

Hey, A long time ago, in a far away galaxy where ARM CubieTrucks ruled the world a cross compiled livepatch was attempted to be loaded. And behold. It crashed the hypervisor with an alignment error. This set of three patches tightens the checks around alignment to make sure that we catch such

[Xen-devel] [ovmf test] 111680: regressions - FAIL

flight 111680 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111680/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 111665 build-i386-xsm

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On 7/11/2017 10:38 AM, Brian Gerst wrote: On Tue, Jul 11, 2017 at 11:02 AM, Tom Lendacky wrote: On 7/10/2017 11:58 PM, Brian Gerst wrote: On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote: On 7/8/2017 7:57 AM, Brian Gerst wrote: On

[Xen-devel] Call for Comment (by July 14) - NIST Platform Firmware Resiliency Guidelines

If you are working on EFI, secure boot or measured launch, this document may influence future hardware devices. You can submit comments until this Friday. https://beta.csrc.nist.gov/News/2017/NIST-Releases-Draft-SP-800-193-for-Public-Comment --- NIST announces the public comment release of

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On Tue, Jul 11, 2017 at 11:02 AM, Tom Lendacky wrote: > On 7/10/2017 11:58 PM, Brian Gerst wrote: >> >> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky >> wrote: >>> >>> On 7/8/2017 7:57 AM, Brian Gerst wrote: On Fri, Jul 7, 2017 at

Re: [Xen-devel] [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On 7/11/2017 12:56 AM, Borislav Petkov wrote: On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote: If I make the scattered feature support conditional on CONFIG_X86_64 (based on comment below) then cpu_has() will always be false unless CONFIG_X86_64 is enabled. So this won't need to be

Re: [Xen-devel] [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On 7/11/2017 12:07 AM, Brian Gerst wrote: On Mon, Jul 10, 2017 at 3:41 PM, Tom Lendacky wrote: On 7/8/2017 7:50 AM, Brian Gerst wrote: On Fri, Jul 7, 2017 at 9:38 AM, Tom Lendacky wrote: Update the CPU features to include identifying and

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On 7/10/2017 11:58 PM, Brian Gerst wrote: On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote: On 7/8/2017 7:57 AM, Brian Gerst wrote: On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky wrote: Currently there is a check if the address being

[Xen-devel] [libvirt test] 111662: tolerable all pass - PUSHED

flight 111662 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/111662/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 111604 test-armhf-armhf-libvirt-xsm 14

[Xen-devel] [PATCH v2] x86/monitor: Notify monitor if an emulation fails.

If case of a vm_event with the emulate_flags set, if the instruction cannot be emulated, the monitor should be notified instead of directly injecting a hw exception. This behavior can be used to re-execute an instruction not supported by the emulator using the real processor (e.g. altp2m) instead

Re: [Xen-devel] [PATCH] x86/monitor: Notify monitor if an emulation fails.

On Lu, 2017-07-10 at 12:30 -0600, Tamas K Lengyel wrote: > On Mon, Jul 10, 2017 at 11:07 AM, Petre Pircalabu > wrote: > > > > If case of a vm_event with the emulate_flags set, if the > > instruction > > cannot be emulated, the monitor should be notified instead of > >

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

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

Re: [Xen-devel] [RFC PATCH 00/15] RFC: SGX virtualization design and draft patches

On 09/07/17 09:03, Kai Huang wrote: Hi all, This series is RFC Xen SGX virtualization support design and RFC draft patches. Thankyou very much for this design doc. 2. SGX Virtualization Design 2.1 High Level Toolstack Changes: 2.1.1 New 'epc' parameter EPC is limited resource. In order

Re: [Xen-devel] [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore

Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 1499726403-10129-1-git-send-email-igor.druzhi...@citrix.com Type: series Subject: [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore === TEST SCRIPT

[Xen-devel] [ovmf test] 111676: regressions - FAIL

flight 111676 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 111665 build-i386-xsm

Re: [Xen-devel] [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore

Hi, This series failed build test on s390x host. Please find the details below. Type: series Subject: [Qemu-devel] [PATCH v3 0/4] xen: don't save/restore the physmap on VM save/restore Message-id: 1499726403-10129-1-git-send-email-igor.druzhi...@citrix.com === TEST SCRIPT BEGIN === #!/bin/bash

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

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

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On Tue, Jul 11, 2017 at 4:35 AM, Arnd Bergmann wrote: > On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst wrote: >> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky >> wrote: >>> On 7/8/2017 7:57 AM, Brian Gerst wrote: On Fri, Jul 7, 2017

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

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

[Xen-devel] [distros-debian-snapshot test] 71679: tolerable trouble: blocked/broken/fail/pass

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

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

flight 111655 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111655/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 REGR. vs. 110441

Re: [Xen-devel] [RFC PATCH v2 03/25] x86: NUMA: Rename and sanitize some common functions

Hi Jan, Sorry for late reply. On Fri, Jun 30, 2017 at 7:35 PM, Jan Beulich wrote: 03/28/17 5:54 PM >>> >> --- a/xen/arch/x86/numa.c >> +++ b/xen/arch/x86/numa.c >> @@ -53,15 +53,15 @@ int srat_disabled(void) >> /* >> * Given a shift value,

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

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

Re: [Xen-devel] [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst wrote: > On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote: >> On 7/8/2017 7:57 AM, Brian Gerst wrote: >>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky >> >> I originally had a

Re: [Xen-devel] [PATCH v3 4/4] xen: don't use xenstore to save/restore physmap anymore

> -Original Message- > From: Igor Druzhinin > Sent: 11 July 2017 00:40 > To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org > Cc: Igor Druzhinin ; sstabell...@kernel.org; > Anthony Perard ; Paul Durrant >

Re: [Xen-devel] [PATCH v3 3/4] xen/mapcache: introduce xen_replace_cache_entry()

> -Original Message- > From: Igor Druzhinin > Sent: 11 July 2017 00:40 > To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org > Cc: Igor Druzhinin ; sstabell...@kernel.org; > Anthony Perard ; Paul Durrant >

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

flight 111648 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/111648/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 111403

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

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