>>> Haozhong Zhang 07/12/17 4:05 AM >>>
>+static int vcpu_set_vmce(struct vcpu *v,
>+ const struct xen_domctl_ext_vcpucontext *evc)
>+{
>+/*
>+ * Sizes of vMCE parameters used by the current and past versions
>+ * of Xen in descending order. If vMCE parameters a
>>> Julien Grall 07/11/17 10:15 PM >>>
>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).
>>
On Fri, 2017-07-07 at 14:12 -0700, Stefano Stabellini wrote:
> On Fri, 7 Jul 2017, Volodymyr Babchuk wrote:
> > > >
> > > Since you are using Credit, can you try to disable context switch
> > > rate
> > > limiting?
> >
> > Yep. You are right. In the environment described above (Case 2) I
> > now
>
On Fri, 2017-07-07 at 14:29 -0400, Meng Xu wrote:
> On Wed, Jul 5, 2017 at 4:29 AM, Dario Faggioli
> wrote:
> >
> The total utilization can help answer if the VCPU parameters are
> feasible or not.
>
I'm just saying that we could keep track of utilization and, if on an
host with N CPUs, we reach
>>> Konrad Rzeszutek Wilk 07/11/17 10:34 PM >>>
>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
>>
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 an instruction not supported
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 an
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 th
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: wa
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 v
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
> > conge
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 Ostrovsky
Cc: Juergen Gross
Cc: xen-de...@lists.xenp
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 si
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?
Sorry
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
>
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
> > conge
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 the main Makefile certainly cuts
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 scnprintf(), presumably
> bec
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 vIOMM
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 gcc-7.
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 9750503a116be3c246b24
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
test-amd64-amd64-xl
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 (
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
Cc: Wei Liu
---
tools/tests/mce-test/tools/xen-mceinj.c | 50 +
Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/cpu/mcheck/mce.c | 24 +++-
xen/include/public/arch-x86/xen-mca.h | 1 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu/mc
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/arch/x86/cpu/mcheck/vmce.c | 34 +-
xen/arch/x8
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
Acked-by: W
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
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
[ RA
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
Reviewed-by: Jan Beulich
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
---
xen/arch/x86/cpu/mcheck/mcaction.c | 23 ---
x
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 07/
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 debian-hvm-in
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 +
[ 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 allm
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
Tes
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
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 gu
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
test-armhf-armhf-
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 blk_mq_{start
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
T
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 alignment:
> >
> >ARM32 native
>>> 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
___
Xen-devel mailing list
Xen-devel@lists.x
>>> 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,
>+ const struct xen_domctl_ext_vcp
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
---
xen/arch/x86
>>> 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 756e6300 63686563 6b5f666
>>> 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) )
>{
>-dprintk(XENLOG_ERR, LIVE
>>> 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);
>
>elf->sec[i].load_addr = buf +
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: b535e2b9b78a ("xen/pvcalls: impl
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
T
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
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 patches.
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 file changed, 5 insertions(
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 parse
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 61
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 e
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
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 Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
wrote:
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 Draf
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 9:39 AM, Tom Lendacky
wrote:
>
>
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 w
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 reporting on the
Secure Memory Encryption (SME) feat
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 mapped is in the ISA
range (is_ISA_range()), and if it
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 saveresto
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 o
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
> > directly
> > injecting a hw e
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 v
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 to
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 BEGIN
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
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
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
test-amd64-amd64-xl
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 at 9:39 AM, Tom Lendacky
>>>
>>> I originally had a check
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 3a3d62d2e66d7bec1b97f
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
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
Tes
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, try to populate memnodemap[]
>> * Returns :
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 v
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 check for SME here in a previous version of the
>> patch. Thomas Gleixn
> -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
> ; pbonz...@redhat.com
> Subject: [PATCH v3 4/4] xen: don't use xenstore to save
> -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
> ; pbonz...@redhat.com
> Subject: [PATCH v3 3/4] xen/mapcache: introduce
> xen_r
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
test-armhf-armhf-
82 matches
Mail list logo