flight 118638 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324
test-amd64-i386-lib
flight 118643 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118643/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118630
Tests which did n
On Wed, 7 Feb 2018 13:01:08 +
Igor Druzhinin wrote:
>So far the issue confirmed:
>Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>that it was tested on), Intel S2600XX, etc.
>
>Also see:
>https://bugs.xenserver.org/browse/XSO-774
>
>Well, no-watchdog is what we currently
flight 118647 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118647/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
flight 118636 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken
test-amd64-i386-freebsd10-amd64 4 host-
Applications like libvirt may not populate a device devid field,
delegating that to libxl. If needed, the application can later
retrieve the libxl-produced devid. Indeed most devices are handled
this way in libvirt, channel devices included.
This works well when only one channel device is defined,
On 02/07/2018 06:49 PM, Prarit Bhargava wrote:
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargav
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava
Tested-and-reported-by: Simon Gaiser
Cc: Thomas
flight 118665 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118665/
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 1
As the previous commit shows it's quite easy to confuse the transaction
reference counting by ending a transaction twice. So at least try to
detect and report it.
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_xs.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/x
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().
Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement th
If Andy wants to use his version of this, that's fine also. This is
just a newer version based on Jan's input.
v1 -> v2
Got rid of "== X"s
Added an assert and got rid of a check in an if
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lis
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/svm.c | 71 +
xen/arch/x86/hvm/svm/vmcb.c | 17 ---
2 files changed, 71 insertions(+), 17 d
Commit 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
removed the check for autotranslation from {set,clear}_foreign_p2m_mapping
but those are called by grant-table.c also on PVH/HVM guests.
Cc: # 4.14
Fixes: 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
Signe
flight 118660 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118660/
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 1
Hi all,
This is the latest status of the SP2 mitigations for Xen on Arm. Please
note that arm32 and arm64 require different mitigations.
I have just backported the arm32 mitigation to 4.10, 4.9, 4.8 and 4.7:
- 4.10
bbd093c xen/arm32: entry: Document the purpose of r11 in the traps handler
a69a8b
On 07/02/18 16:12, Jan Beulich wrote:
> I'm not sure why I didn't do this right away: By avoiding the use of
> global PTEs in the cloned directmap, there's no need to fiddle with
> CR4.PGE on any of the entry paths. Only the exit paths need to flush
> global mappings.
>
> The reduced flushing, howe
On 02/07/2018 02:26 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>>> This breaks booting as Xen PV domain for me. The problem seems to be
>>> that native_smp_cpus_done() is never called on a PV domain. So
>>> __max_logical_packages is uninitialized
Prarit Bhargava:
> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>> Prarit Bhargava:
>>> A system booted with a small number of cores enabled per package
>>> panics because the estimate of __max_logical_packages is too low.
>>> This occurs when the total number of active cores across all packages
>>>
On 02/07/2018 01:44 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> A system booted with a small number of cores enabled per package
>> panics because the estimate of __max_logical_packages is too low.
>> This occurs when the total number of active cores across all packages
>> is less than the maxi
flight 118633 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118633/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken
test-amd6
Prarit Bhargava:
> A system booted with a small number of cores enabled per package
> panics because the estimate of __max_logical_packages is too low.
> This occurs when the total number of active cores across all packages
> is less than the maximum core count for a single package.
>
> ie) On a 4
On 02/07/2018 07:01 PM, Jan Beulich wrote:
On 02.02.18 at 09:14, wrote:
>> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>> }
>> }
>>
>> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
>> +{
>> +noflush = !!(value & X86_
> On 7. Feb 2018, at 17:09, Wei Liu wrote:
>
> Signed-off-by: Wei Liu
> ---
> tools/ocaml/libs/xb/xb.mli | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli
> index b4d705201f..95d1c6f840 100644
> --- a/tools/ocam
> On 7. Feb 2018, at 17:09, Wei Liu wrote:
>
> To stay in line with other parts of the ocaml code base.
>
> This requires committing a bunch of mli files in tree.
>
> Signed-off-by: Wei Liu
> ---
> tools/ocaml/libs/xb/Makefile| 4
> tools/ocaml/libs/xb/op.mli | 29 +
flight 118650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118650/
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 1
On Wed, Feb 07, 2018 at 04:11:17PM +0100, Olaf Hering wrote:
> Remove the executable bits of vtpm files by using _DATA instead of _PROG.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:
On 07/02/18 15:06, Jan Beulich wrote:
On 07.02.18 at 14:24, wrote:
>> On 07/02/18 13:08, Jan Beulich wrote:
>> On 07.02.18 at 14:01, wrote:
So far the issue confirmed:
Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
that it was tested on), Intel S2600X
Wei Liu (2):
ocaml/xb: update xb.mli in accordance with df1e4c6e7f8
ocaml/libs/xb: don't generate *.mli automatically
tools/ocaml/libs/xb/Makefile| 4
tools/ocaml/libs/xb/op.mli | 29 +
tools/ocaml/libs/xb/packet.mli | 13 +
tools/ocaml/
To stay in line with other parts of the ocaml code base.
This requires committing a bunch of mli files in tree.
Signed-off-by: Wei Liu
---
tools/ocaml/libs/xb/Makefile| 4
tools/ocaml/libs/xb/op.mli | 29 +
tools/ocaml/libs/xb/packet.mli | 13
Signed-off-by: Wei Liu
---
tools/ocaml/libs/xb/xb.mli | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli
index b4d705201f..95d1c6f840 100644
--- a/tools/ocaml/libs/xb/xb.mli
+++ b/tools/ocaml/libs/xb/xb.mli
@@ -76,10 +76
>>> On 02.02.18 at 09:14, wrote:
> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
> }
> }
>
> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
> +{
> +noflush = !!(value & X86_CR3_NOFLUSH);
Pointless !!.
> --- a/xen/include/a
On 07/02/18 16:27, Zhongze Liu wrote:
Hi Wei and Julien,
Hi,
2018-02-07 2:06 GMT+08:00 Wei Liu :
On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:
if (libxl__device_pci_destroy_all(gc, domid) < 0)
LOGD(ERROR, domid, "Pci shutdown failed");
rc = xc_domain
>>> On 07.02.18 at 17:12, wrote:
> On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote:
>> I have no idea what *.1 is meant to cover. Instead also exclude
>> preprocessed and non-source assembly files.
>
> Oh, I guess that answers my question in 2/4 then. I don't seem to have
> neither .i
>>> On 07.02.18 at 17:05, wrote:
> On Wed, Feb 07, 2018 at 08:07:40AM -0700, Jan Beulich wrote:
>> I have no idea what *.d1 is supposed to refer to - we only have .*.d
>> and .*.d2 files (note also the leading dot).
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/tools/firmware/xen-dir/Makefile
>>
Hi Wei and Julien,
2018-02-07 2:06 GMT+08:00 Wei Liu :
> On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:
>> > if (libxl__device_pci_destroy_all(gc, domid) < 0)
>> > LOGD(ERROR, domid, "Pci shutdown failed");
>> > rc = xc_domain_pause(ctx->xch, domid);
>> > diff
On Wed, Feb 07, 2018 at 08:37:13AM -0700, Jan Beulich wrote:
> >>> On 07.02.18 at 11:53, wrote:
> > docs/misc/coverage.markdown | 2 +-
> > xen/Kconfig.debug| 6 +++---
> > xen/Rules.mk | 9 +++--
> > xen/arch/x86/efi/Makefile| 2 +-
> > xen/common/Makefile
On Wed, Feb 07, 2018 at 08:08:47AM -0700, Jan Beulich wrote:
> "mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly
> enough this doesn't cause the whole command (and hence the build to
> fail), despite the "set -e" now covering the entire set of commands -
> perhaps a quirk of th
On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote:
> I have no idea what *.1 is meant to cover. Instead also exclude
> preprocessed and non-source assembly files.
Oh, I guess that answers my question in 2/4 then. I don't seem to have
neither .i or .a files, but certainly .s should be exc
Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR
to guests yet.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -204,6 +204,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"avx512-4fmaps",0x0007, 0, CPU
At the same time also report the state of the two defined
ARCH_CAPABILITIES MSR bits. To avoid further complicating the
conditional around that printk(), drop it (it's a debug level one only
anyway).
Signed-off-by: Jan Beulich
---
v2: Re-base over split off earlier patch. Drop MSR_ from
MSR_A
When XPTI is active, the CR3 load in restore_all_guest is sufficient
when switching to user mode, improving in particular system call and
page fault exit paths for the guest.
Signed-off-by: Jan Beulich
---
v2: Add ASSERT(!in_irq()).
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@
Introduce a synthetic feature flag to use alternative instruction
patching to NOP out all code on entry/exit paths other than those
involved in NMI/#MC handling (the patching logic can't properly handle
those paths yet). Having NOPs here is generally better than using
conditional branches.
Also ch
CR3 is - during normal operation - only ever loaded from v->arch.cr3,
so there's no need to read the actual control register. For CR4 we can
generally use the cached value on all synchronous entry end exit paths.
Drop the write_cr3 macro, as the two use sites are probably easier to
follow without i
This allows shortening (and making more obvious what they do) some
altinstruction_entry uses.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -135,8 +135,7 @@ ENTRY(compat_restore_all_guest)
jne 1b
.Lcr4_alt_end:
I'm not sure why I didn't do this right away: By avoiding the use of
global PTEs in the cloned directmap, there's no need to fiddle with
CR4.PGE on any of the entry paths. Only the exit paths need to flush
global mappings.
The reduced flushing, however, implies that we now need to have
interrupts
On Wed, Feb 07, 2018 at 08:07:01AM -0700, Jan Beulich wrote:
> "set -e" on a separate Makefile line is meaningless. Glue together all
> the lines that this is supposed to cover.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Wed, Feb 07, 2018 at 08:07:40AM -0700, Jan Beulich wrote:
> I have no idea what *.d1 is supposed to refer to - we only have .*.d
> and .*.d2 files (note also the leading dot).
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@
1: slightly reduce Meltdown band-aid overhead
2: remove CR reads from exit-to-guest path
3: introduce altinstruction_nop assembler macro
4: NOP out most XPTI entry/exit code when it's not in use
5: avoid double CR3 reload when switching to guest user mode
6: disable XPTI when RDCL_NO
7: x86: log XP
On Mon, Jan 29, 2018 at 2:18 AM, Jan Beulich wrote:
On 26.01.18 at 18:35, wrote:
>> On Fri, Jan 26, 2018 at 5:46 AM, Jan Beulich wrote:
>> On 23.01.18 at 01:21, wrote:
@@ -375,12 +385,39 @@ static void __init PrintErrMesg(const CHAR16 *mesg,
EFI_STATUS ErrCode)
st
>>> On 07.02.18 at 11:53, wrote:
> docs/misc/coverage.markdown | 2 +-
> xen/Kconfig.debug| 6 +++---
> xen/Rules.mk | 9 +++--
> xen/arch/x86/efi/Makefile| 2 +-
> xen/common/Makefile | 2 +-
> xen/common/coverage/Makefile | 5 -
> xen/common/sys
>>> On 20.12.17 at 10:37, wrote:
> The parts of this series aren't really dependent upon one another,
> they belong together solely because of their origin.
>
> 1: x86/shadow: widen reference count
> 2: x86/mm: clean up SHARED_M2P{,_ENTRY} uses
> 3: x86: use paging_mark_pfn_dirty()
George,
any
On Wed, Feb 07, 2018 at 02:44:05PM +, Anthony PERARD wrote:
> On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote:
> > Am Wed, 7 Feb 2018 11:13:22 +0100
> > schrieb Olaf Hering :
> >
> > > Yes, it looks like qemu has now submodules which are required for build.
> >
> > How is the requ
>>> On 07.02.18 at 15:41, wrote:
> Explicit segment overides other than %fs and %gs are documented as ignored by
> both Intel and AMD.
>
> In practice, this means that:
>
> * Explicit uses of %ss don't actually yield #SS[0] for non-canonical
>memory references.
> * Explicit uses of %{e,c,d
Remove the executable bits of vtpm files by using _DATA instead of _PROG.
Signed-off-by: Olaf Hering
---
stubdom/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index f45eeabd8b..7cb62e6c36 100644
--- a/stubdom/Makefile
+++ b/s
"mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly
enough this doesn't cause the whole command (and hence the build to
fail), despite the "set -e" now covering the entire set of commands -
perhaps a quirk of the relatively old bash I've seen this with (a few
simple experiments s
I have no idea what *.1 is meant to cover. Instead also exclude
preprocessed and non-source assembly files.
Signed-off-by: Jan Beulich
--- unstable.orig/tools/firmware/xen-dir/Makefile 2018-02-07
15:30:24.038600788 +0100
+++ unstable/tools/firmware/xen-dir/Makefile2018-02-07 15:35:18.
I have no idea what *.d1 is supposed to refer to - we only have .*.d
and .*.d2 files (note also the leading dot).
Signed-off-by: Jan Beulich
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -26,7 +26,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)
$(foreach d,
>>> On 07.02.18 at 14:24, wrote:
> On 07/02/18 13:08, Jan Beulich wrote:
> On 07.02.18 at 14:01, wrote:
>>> So far the issue confirmed:
>>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>>> that it was tested on), Intel S2600XX, etc.
>>>
>>> Also see:
>>> https://bugs.x
"set -e" on a separate Makefile line is meaningless. Glue together all
the lines that this is supposed to cover.
Signed-off-by: Jan Beulich
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -16,18 +16,18 @@ DEP_FILES=$(foreach i, $(LINK_FILES), $(
linkfarm.stamp:
This is a split of the RFC with the mkdir fix added, but with the symlink
handling left off for now (I'll need some more time to properly deal with
that without using -xtype, ideally treating absolute and relative ones
differently).
1: correctly handle errors during Xen tree setup
2: better filter
On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote:
> Am Wed, 7 Feb 2018 11:13:22 +0100
> schrieb Olaf Hering :
>
> > Yes, it looks like qemu has now submodules which are required for build.
>
> How is the required state of the submodules tracked?
Hi,
QEMU have now a script to take car
Explicit segment overides other than %fs and %gs are documented as ignored by
both Intel and AMD.
In practice, this means that:
* Explicit uses of %ss don't actually yield #SS[0] for non-canonical
memory references.
* Explicit uses of %{e,c,d}s don't override %rbp/%rsp-based memory reference
On Wed, Feb 07, 2018 at 02:16:14PM +, Joao Martins wrote:
> On 02/07/2018 12:08 PM, Roger Pau Monné wrote:
> > On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
> >> +static void xen_blkbk_probe_features(struct xenbus_device *dev,
> >> + struct backend_
flight 118641 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 118626
build-armhf
On 02/07/2018 12:08 PM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
>> Toolstack may write values to the "require" subdirectory in the
>> backend main directory (e.g. backend/vbd/X/Y/). Read these values
>> and use them when announcing those to the fronten
On 07/02/18 13:08, Jan Beulich wrote:
On 07.02.18 at 14:01, wrote:
>> So far the issue confirmed:
>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>> that it was tested on), Intel S2600XX, etc.
>>
>> Also see:
>> https://bugs.xenserver.org/browse/XSO-774
>>
>> Well, no
flight 118631 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118631/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
Hi,
On 6 February 2018 at 20:12, Julien Grall wrote:
> On 02/06/2018 04:23 PM, Volodymyr Babchuk wrote:
>>
>> Hi,
>
>
> Hi,
>
>> On 5 February 2018 at 15:20, Julien Grall wrote:
>>>
>>> SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
>>> SMCCC_ARCH_WORKAROUND_1 provides BP harden
Hi Julien,
On 6 February 2018 at 20:33, Julien Grall wrote:
> Hi,
>
> On 02/06/2018 04:36 PM, Volodymyr Babchuk wrote:
>>
>> On 5 February 2018 at 15:20, Julien Grall wrote:
>>>
>>> The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
>>> hardening the branch predictor. So we wa
Hi Julien,
On 6 February 2018 at 20:04, Julien Grall wrote:
> Hi,
>
> On 02/06/2018 04:18 PM, Volodymyr Babchuk wrote:
>>
>> On 5 February 2018 at 15:20, Julien Grall wrote:
>>>
>>> The new SMC Calling Convention (v1.1) allows for a reduced overhead when
>>> calling into the firmware, and provid
On 07/02/18 13:08, Jan Beulich wrote:
On 07.02.18 at 14:01, wrote:
>> So far the issue confirmed:
>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>> that it was tested on), Intel S2600XX, etc.
>>
>> Also see:
>> https://bugs.xenserver.org/browse/XSO-774
>>
>> Well, no
>>> On 07.02.18 at 14:01, wrote:
> So far the issue confirmed:
> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
> that it was tested on), Intel S2600XX, etc.
>
> Also see:
> https://bugs.xenserver.org/browse/XSO-774
>
> Well, no-watchdog is what we currently recommend in t
flight 118632 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118632/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 118605
test-armhf-armhf-libvirt-xsm 14 saveresto
On 07/02/18 09:13, Jan Beulich wrote:
On 06.02.18 at 22:51, wrote:
>> The problem with a quirk/commandline parameter is that the issue is
>> reported for a wide variety of systems and, as it looks like, depends on
>> the default BIOS setup - means it's hard to identify particular
>> machines.
>>> On 07.02.18 at 13:40, wrote:
> Am Wed, 7 Feb 2018 11:13:22 +0100
> schrieb Olaf Hering :
>
>> Yes, it looks like qemu has now submodules which are required for build.
>
> How is the required state of the submodules tracked? When I did a local
> build I got 10739aa from qemu.org, and buildin
Am Wed, 7 Feb 2018 11:13:22 +0100
schrieb Olaf Hering :
> Yes, it looks like qemu has now submodules which are required for build.
How is the required state of the submodules tracked? When I did a local build I
got 10739aa from qemu.org, and building xen.git#staging succeeds. After that I
updat
Hi,
On 06/02/18 19:56, Julien Grall wrote:
Xen does not yet support Cavium SMMU because it requires some
workaround. For the time being, blacklist them.
Signed-off-by: Julien Grall
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/thunderx.c | 39 +
flight 118630 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118630/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118613
test-armhf-armhf-libvirt 14 sav
On 02/06/2018 02:52 PM, Wei Liu wrote:
On Tue, Feb 06, 2018 at 02:44:56PM +0200, Oleksandr Andrushchenko wrote:
From aa1f20af73a5a3c8f2c904b857a79334d18d41ff Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko
Date: Wed, 20 Dec 2017 17:51:18 +0200
Subject: [PATCH] [HACK] Reset iomem's gfn
On 02/06/2018 05:12 PM, Wei Liu wrote:
> (Three months after you sent this, sorry...)
>
> On Mon, Nov 06, 2017 at 12:33:06PM +, Joao Martins wrote:
>> On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
-Original Message-
From: Joao Martins [mailto:joao.m.mart...@or
On 02/07/2018 11:16 AM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
>> Hey folks,
>>
>> Presented herewith is an attempt to implement PV backends feature control
>> as discussed in the list
>> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg0076
On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
> Toolstack may write values to the "require" subdirectory in the
> backend main directory (e.g. backend/vbd/X/Y/). Read these values
> and use them when announcing those to the frontend. When backend
> scans frontend features the values
On 02/07/2018 11:30 AM, Roger Pau Monné wrote:
> On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
>> On 07/02/18 12:16, Roger Pau Monné wrote:
>>> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
* Toolstack constructs a key value store of features, and user specifie
On 02/07/2018 11:30 AM, Roger Pau Monné wrote:
> On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
>> On 07/02/18 12:16, Roger Pau Monné wrote:
>>> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
* Toolstack constructs a key value store of features, and user specifie
On Thu, Nov 02, 2017 at 06:06:09PM +, Joao Martins wrote:
> The proposed directory provides a mechanism for tools to control the
> maximum feature set of the device being provisioned by backends.
> Examples include max ring page order, persistent grants, number of
> queues etc.
>
> Signed-off-
On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
> On 07/02/18 12:16, Roger Pau Monné wrote:
> > On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
> >> * Toolstack constructs a key value store of features, and user specifies
> >> those
> >> through special entry names pre
flight 118629 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail REGR. vs. 118324
test-amd64-amd64-xl
On 07/02/18 12:16, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
>> Hey folks,
>>
>> Presented herewith is an attempt to implement PV backends feature control
>> as discussed in the list
>> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.htm
On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
> Hey folks,
>
> Presented herewith is an attempt to implement PV backends feature control
> as discussed in the list
> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html)
>
> Given that this a simple proposal hence
On Wed, Feb 07, 2018 at 10:53:56AM +, Roger Pau Monne wrote:
> So it can be used by both gcc and clang. Just add the Kconfig option
> and modify the makefiles so the llvm coverage specific code can be
> added in a follow up patch.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
__
So it can be used by both gcc and clang. Just add the Kconfig option
and modify the makefiles so the llvm coverage specific code can be
added in a follow up patch.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
>>> On 06.02.18 at 12:09, wrote:
> During patching, there is a very slim risk that an NMI or MCE interrupt in the
> middle of altering the code in the NMI/MCE paths, in which case bad things
> will happen.
>
> The NMI risk can be eliminated by running the patching loop in NMI context, at
> which
On Wed, Feb 07, 2018 at 09:45:53AM +0100, Olaf Hering wrote:
> The previous version simply states that a symlink has to be created
> without telling where the symlink should point to.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
___
Xen-devel mai
On Wed, Feb 07, 2018 at 09:30:57AM +0100, Olaf Hering wrote:
> HVC is shown underlined, the underscores are missing.
> Fix it by using underscores.
> Remove stale I.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-deve
On Tue, Feb 06, 2018 at 09:56:14PM +, Michael Young wrote:
> On Tue, 6 Feb 2018, Wei Liu wrote:
>
> > On Tue, Jan 30, 2018 at 10:55:47PM +, Michael Young wrote:
> > > Xen built with ocaml 4.06 gives errors such as
> > > Error: This expression has type bytes but an expression was
> > > ex
flight 118635 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118635/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58
baseline version:
xen 99d9
Am Wed, 07 Feb 2018 02:56:55 -0700
schrieb "Jan Beulich" :
> I think I had seen this too, and only then I realized that now I need
> to set up the respective submodule in the qemu tree.
Yes, it looks like qemu has now submodules which are required for build.
Neither configure nor 'git archive' d
>>> On 07.02.18 at 09:18, wrote:
> With current staging, qemu-xen fails to build. It looks like a ordering
> issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file.
> It is (as always) a fresh clean checkout in a clean chroot.
I think I had seen this too, and only then I realized th
On 02/06/2018 10:39 PM, Dario Faggioli wrote:
> On Tue, 2018-02-06 at 17:02 +, George Dunlap wrote:
>> On 02/06/2018 06:18 AM, Juergen Gross wrote:
>>> On 05/02/18 17:53, Dario Faggioli wrote:
Considering we're releasing in June, but freezing in March, do we
think
it is sti
1 - 100 of 104 matches
Mail list logo
