flight 121072 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
flight 121052 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. 120913
Regressions which are
flight 121051 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 120982
Tests which did not suc
flight 121053 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121053/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR. vs. 120977
Tests which did not
Prefer the direct use of octal for permissions.
Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
and some typing.
Miscellanea:
o Whitespace neatening around these conversions.
Signed-off-by: Joe Perches
---
drivers/net/bonding/bond_procfs.c | 2 +-
drivers/net/bonding/bond_s
Using octal and not symbolic permissions is preferred by many as
more readable.
https://lkml.org/lkml/2016/8/2/1945
Rather than getting these piecemeal, just do them all.
Done with checkpatch and some typing.
Joe Perches (4):
ethernet: Use octal not symbolic permissions
wireless: Use octal n
On Fri, 23 Mar 2018 13:57:11 +
Paul Durrant wrote:
[...]
>> Few related thoughts:
>>
>> 1. MMCONFIG address is chipset-specific. On Q35 it's a PCIEXBAR, on
>> other x86 systems it may be HECBASE or else. So we can assume it is
>> bound to the emulated machine
>
>Xen emulates the machine so it
flight 121090 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121090/
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
flight 121088 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121088/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-cubietruck-braque 2 hosts-allocate broken like 119971
examine-godello0 2 hosts-all
flight 121047 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121047/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780
test-xtf-amd64-amd64-4 50 xt
On Fri, Mar 23, 2018 at 05:06:30PM +, osstest service owner wrote:
> flight 121050 seabios real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/121050/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64
flight 121050 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121050/
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
On Fri, 23 Mar 2018, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné [mailto:roy...@gmail.com] On Behalf Of Roger Pau
> > Monné
> > Sent: 23 March 2018 09:44
> > To: Stefano Stabellini
> > Cc: Lars Kurth ; Juergen Gross ; Ji,
> > John ; xen-de...@lists.xensource.com; W
flight 121048 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
build-armhf-libvirt 5 host-build-p
>>> On 19.03.18 at 20:13, wrote:
> @@ -551,6 +555,37 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> if ( !ret )
> goto createdomain_fail_late;
>
> +ret = -EINVAL;
> +if ( vcpus > domain_max_vcpus(d) )
> +goto createdomain_f
>>> On 19.03.18 at 20:13, wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -539,14 +539,37 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> break;
> }
>
> +/* Stash the new domid for the toolstack. */
> +op->domain = d
>>> On 23.03.18 at 15:11, wrote:
> On 23/03/18 14:46, Jan Beulich wrote:
>> Valid point. Looking at all present uses of ->arch.cr3, it's probably
>> indeed better the way you have it. However, I'm now wondering
>> about something else: make_cr3() leaves PCID as zero for HVM
>> and idle domains, bu
My apologies, but I found a few more things that look strange and should
be cleaned up. Sorry for this iterative review approach, but I think we're
slowly getting there.
Thank you for reviewing!
Cheers, Daniel
---
+static int xen_drm_drv_dumb_create(struct drm_file *filp,
+
>>> On 23.03.18 at 12:28, wrote:
> From: FionaLi
>
> Signed-off-by: Fiona Li
First of all, please shorten the subject and put a fair part of what
you had there in the description.
Then you talk about a VT-d compatible IOMMU, but not about VMX
or some other CPU side hardware virtualization. Is
flight 121045 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121045/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd 12
>>> On 23.03.18 at 13:41, wrote:
> On Fri, Mar 23, 2018 at 07:28:56PM +0800, Fionali wrote:
>> +/* Test for Shanghai Extended CPUID information */
>> +if (cpuid_eax(0xC000) >= 0xC001) {
>
> Coding style. Should be
>
> if ( )
> {
FAOD with the tab replaced by
>>> On 23.03.18 at 14:41, wrote:
> Ah that's true. We will do the check based on the response state even if the
> next IO is going to be dealt with internally. So, yes, the real question is
> why the previous I/O was completed without apparently waiting for QEMU to
> finish.
> We should have se
On Fri, Mar 23, 2018 at 10:57:56AM +, Roger Pau Monne wrote:
> HVM guest should be created with (XEN_X86_EMU_ALL &
> ~XEN_X86_EMU_VPCI). This is not an issue for xl/libxl because it
> already sets the correct emulation flags and doesn't pass a NULL
> xc_domain_configuration_t to xc_domain_creat
On Fri, Mar 23, 2018 at 08:42:53AM +0100, Juergen Gross wrote:
> Commit 448c03b3cbe1487 ("tools/xenstore: try to get minimum thread
> stack size for watch thread") added a dependency to libdl to
> libxenstore. Unfortunately the way it was added requires now all
> users of libxenstore to specify "-l
On 3/23/18 2:42 AM, Juergen Gross wrote:
> Commit 448c03b3cbe1487 ("tools/xenstore: try to get minimum thread
> stack size for watch thread") added a dependency to libdl to
> libxenstore. Unfortunately the way it was added requires now all
> users of libxenstore to specify "-ldl" when linking. This
On 23/03/18 14:46, Jan Beulich wrote:
On 23.03.18 at 12:29, wrote:
>> On 23/03/18 11:51, Jan Beulich wrote:
>> On 21.03.18 at 13:51, wrote:
Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.
We are us
On Wed, 2018-03-21 at 13:51 +0100, Juergen Gross wrote:
> On my machine (Intel i7-4600M) using the PCID feature in the non-XPTI
> case showed a slightly worse performance than using global pages
> instead (using PCID and global pages is a bad idea as invalidating
> global pages in this case would n
> -Original Message-
> From: Alexey G [mailto:x19...@gmail.com]
> Sent: 22 March 2018 15:09
> To: Jan Beulich
> Cc: Andrew Cooper ; Anthony Perard
> ; Ian Jackson ; Paul
> Durrant ; Roger Pau Monne
> ; Wei Liu ; StefanoStabellini
> ; xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel
On Fri, Mar 23, 2018 at 10:22:27AM +, Daniel P. Berrangé wrote:
> On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> > Make sure all generated files go into qemu-build subdirectory.
> > We can then include them like this:
> > #include "qemu-build/trace.h"
> >
> > This serve
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 23 March 2018 11:39
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ;
> 'Alexey G' ; xen-devel@lists.xenproject.org; Anthony
> Perard ; Ian Jack
>>> On 23.03.18 at 12:29, wrote:
> On 23/03/18 11:51, Jan Beulich wrote:
> On 21.03.18 at 13:51, wrote:
>>> Avoid flushing the complete TLB when switching %cr3 for mitigation of
>>> Meltdown by using the PCID feature if available.
>>>
>>> We are using 4 PCID values for a 64 bit pv domain subj
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 23 March 2018 11:36
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] possible I/O emulation state machine issu
On Vi, 2018-03-23 at 09:35 -0400, Boris Ostrovsky wrote:
> On 03/23/2018 05:10 AM, Jan Beulich wrote:
> >
> > >
> > > >
> > > > >
> > > > > On 23.03.18 at 09:31, wrote:
> > > @@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct
> > > cpu_user_regs *regs)
> > > HVMTRACE_0D(SMI);
> > >
On 03/23/2018 05:10 AM, Jan Beulich wrote:
On 23.03.18 at 09:31, wrote:
>> @@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>> HVMTRACE_0D(SMI);
>> break;
>>
>> +case VMEXIT_ICEBP:
>> case VMEXIT_EXCEPTION_DB:
>> if ( !v->domain-
On Fri, Mar 23, 2018 at 07:28:56PM +0800, Fionali wrote:
> From: FionaLi
>
> Signed-off-by: Fiona Li
> ---
> xen/arch/x86/cpu/Makefile | 1 +
> xen/arch/x86/cpu/common.c | 1 +
> xen/arch/x86/cpu/shanghai.c | 61
> +++
> xen/include/as
On 22/03/18 15:50, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> When switching to a 64-bit pv context the TLB is flushed twice today:
>> the first time when switching to the new address space in
>> write_ptbase(), the second time when switching to guest mode in
>> restore_to_guest.
>>
>
flight 121084 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121084/
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 Fri, Mar 23, 2018 at 07:28:56PM +0800, Fionali wrote:
> From: FionaLi
>
> Signed-off-by: Fiona Li
> ---
> xen/arch/x86/cpu/Makefile | 1 +
> xen/arch/x86/cpu/common.c | 1 +
> xen/arch/x86/cpu/shanghai.c | 61
> +++
> xen/include/as
On Thu, Mar 22, 2018 at 06:24:37PM +, George Dunlap wrote:
> +### Disks
> +
> +The chroot (and seccomp?) happens late enough such that QEMU can
> +initialize itself and open its disks. If you want to add a disk at run
> +time via or insert a CD, you can't pass a path because QEMU is
> +chrooted
From: FionaLi
Signed-off-by: Fiona Li
---
xen/arch/x86/cpu/Makefile | 1 +
xen/arch/x86/cpu/common.c | 1 +
xen/arch/x86/cpu/shanghai.c | 61 +++
xen/include/asm-x86/iommu.h | 2 ++
xen/include/asm-x86/msr-index.h | 4 +++
xen
Also fix x86/HVM to spell out that only DomU HVM mode is supported and
remove the 'guest' from the ARM section, ARM supports both Dom0/DomU
using the same mode.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad
>>> On 23.03.18 at 11:29, wrote:
> No, that's not quite right. Only qemu-trad (and stubdom) are 'default' ioreq
> servers. Upstream QEMU has registered individual PCI devices with Xen for
> some time now, and hence gets proper PCI config IOREQs. Also we really really
> want default ioreq server
>>> On 23.03.18 at 11:43, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 23 March 2018 07:30
>>
>> >>> On 22.03.18 at 16:29, wrote:
>> > On 22/03/18 15:12, Jan Beulich wrote:
>> >> Paul,
>> >>
>> >> our PV driver person has found a
On 03/23/2018 10:53 AM, George Dunlap wrote:
On 03/23/2018 09:41 AM, Ross Lagerwall wrote:
On 03/22/2018 06:24 PM, George Dunlap wrote:
snip
-for ((i=1; i<65536; i++))
+# Introduction
+
+# Setup
+
+## Getting the right versions of software
+
+Linux 4.XX
(For dom0 kernel...)
Requires 4.11 for
On 23/03/18 11:51, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> Avoid flushing the complete TLB when switching %cr3 for mitigation of
>> Meltdown by using the PCID feature if available.
>>
>> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
>> 2 values for the non-X
Am 23.03.2018 um 11:22 hat Daniel P. Berrangé geschrieben:
> On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> > Make sure all generated files go into qemu-build subdirectory.
> > We can then include them like this:
> > #include "qemu-build/trace.h"
> >
> > This serves two pur
>>> On 23.03.18 at 11:43, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 23 March 2018 07:30
>>
>> >>> On 22.03.18 at 16:29, wrote:
>> > On 22/03/18 15:12, Jan Beulich wrote:
>> >> our PV driver person has found a reproducible crash
On 03/23/2018 11:14 AM, Roger Pau Monné wrote:
> On Fri, Mar 23, 2018 at 11:06:54AM +, George Dunlap wrote:
>> On 03/23/2018 10:27 AM, Roger Pau Monne wrote:
>>> Signed-off-by: Roger Pau Monné
>>> ---
>>> Cc: Andrew Cooper
>>> Cc: George Dunlap
>>> Cc: Ian Jackson
>>> Cc: Jan Beulich
>>> C
On Fri, Mar 23, 2018 at 11:06:54AM +, George Dunlap wrote:
> On 03/23/2018 10:27 AM, Roger Pau Monne wrote:
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Andrew Cooper
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Jan Beulich
> > Cc: Julien Grall
> > Cc: Konrad Rzeszutek Wilk
>
On 03/23/2018 10:27 AM, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
> ---
> SUPPORT.md | 24
HVM guest should be created with (XEN_X86_EMU_ALL &
~XEN_X86_EMU_VPCI). This is not an issue for xl/libxl because it
already sets the correct emulation flags and doesn't pass a NULL
xc_domain_configuration_t to xc_domain_create.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
On 03/23/2018 09:41 AM, Ross Lagerwall wrote:
> On 03/22/2018 06:24 PM, George Dunlap wrote:
> snip
>> -for ((i=1; i<65536; i++))
>> +# Introduction
>> +
>> +# Setup
>> +
>> +## Getting the right versions of software
>> +
>> +Linux 4.XX
>
> (For dom0 kernel...)
>
> Requires 4.11 for the ability t
>>> On 21.03.18 at 13:51, wrote:
> Avoid flushing the complete TLB when switching %cr3 for mitigation of
> Meltdown by using the PCID feature if available.
>
> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
> 2 values for the non-XPTI case:
>
> - guest active and in kernel
On 19/03/18 14:32, Jan Beulich wrote:
> 1: NOP out most XPTI entry/exit code when it's not in use
> 2: disable XPTI when RDCL_NO
> 3: x86: log XPTI enabled status
> 4: use %r12 to write zero into xen_cr3
> 5: reduce .text.entry
> 6: enable interrupts earlier with XPTI disabled
> 7: also NOP out xen
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 23 March 2018 07:30
> To: Andrew Cooper
> Cc: xen-devel ; Paul Durrant
>
> Subject: Re: [Xen-devel] possible I/O emulation state machine issue
>
> >>> On 22.03.18 at
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Alexey G
> Sent: 22 March 2018 15:31
> To: Roger Pau Monne
> Cc: Stefano Stabellini ; Wei Liu
> ; Andrew Cooper ; Ian
> Jackson ; Paul Durrant ;
> Jan Beulich ; Anthony Perard
> ; xen-deve
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
SUPPORT.md | 24
1 file changed, 24 insertions(+)
diff --git a
On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> Make sure all generated files go into qemu-build subdirectory.
> We can then include them like this:
> #include "qemu-build/trace.h"
>
> This serves two purposes:
> - make it easy to detect which files are in the source
> dir
On Fri, Mar 23, 2018 at 09:41:47AM +, Ross Lagerwall wrote:
> On 03/22/2018 06:24 PM, George Dunlap wrote:
> > +* PCI passthrough
>
> This one requires a fair amount of Xen & QEMU changes to have a chance of
> working.
I'm not sure this will ever be feasible with the current approach
where QE
> -Original Message-
> From: Roger Pau Monné [mailto:roy...@gmail.com] On Behalf Of Roger Pau
> Monné
> Sent: 23 March 2018 09:44
> To: Stefano Stabellini
> Cc: Lars Kurth ; Juergen Gross ; Ji,
> John ; xen-de...@lists.xensource.com; Wei Liu
> ; Tamas K Lengyel ; Andrew
> Cooper ; Daniel K
>>> On 21.03.18 at 13:51, wrote:
> Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to
> be switched on entry to Xen, or negative for keeping the value while
> indicating not to restore %cr3, or positive in case %cr3 is to be
> restored.
>
> Switch to use a flag byte instead of a
On Thu, Mar 22, 2018 at 03:51:11PM -0700, Stefano Stabellini wrote:
> On Thu, 22 Mar 2018, Lars Kurth wrote:
> > On 22/03/2018, 14:49, "Julien Grall" wrote:
> >
> > >> -
> > >>
> > >> I think we need to discuss PCI emulation and our future direction.
> > Our current hybrid with
On 03/22/2018 06:24 PM, George Dunlap wrote:
snip
-for ((i=1; i<65536; i++))
+# Introduction
+
+# Setup
+
+## Getting the right versions of software
+
+Linux 4.XX
(For dom0 kernel...)
Requires 4.11 for the ability to restrict dmop calls.
+
+Xen 4.XX
Requires 4.11 to get required dmop calls
flight 121044 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121044/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116
test-xtf-amd64-
>>> On 23.03.18 at 09:31, wrote:
> @@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
> HVMTRACE_0D(SMI);
> break;
>
> +case VMEXIT_ICEBP:
> case VMEXIT_EXCEPTION_DB:
> if ( !v->domain->debugger_attached )
> -hvm_inject_hw_e
>>> On 23.03.18 at 09:29, wrote:
> On 23/03/18 09:14, Jan Beulich wrote:
> On 23.03.18 at 08:58, wrote:
>>> On 23/03/18 08:46, Jan Beulich wrote:
>>> On 22.03.18 at 19:18, wrote:
> On 22/03/18 17:30, Jan Beulich wrote:
> On 21.03.18 at 13:51, wrote:
>>> --- a/xen/arch/x8
>>> On 23.03.18 at 08:58, wrote:
> On 23/03/18 08:46, Jan Beulich wrote:
> On 22.03.18 at 19:18, wrote:
>>> On 22/03/18 17:30, Jan Beulich wrote:
>>> On 21.03.18 at 13:51, wrote:
> Instead of flushing the TLB from global pages when switching address
> spaces with XPTI being activ
At this moment the Debug events for the AMD architecture are not
forwarded to the monitor layer.
This patch adds the Debug event to the common capabilities, adds
the VMEXIT_ICEBP then forwards the event to the monitor layer.
Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
exce
On 23/03/18 09:14, Jan Beulich wrote:
On 23.03.18 at 08:58, wrote:
>> On 23/03/18 08:46, Jan Beulich wrote:
>> On 22.03.18 at 19:18, wrote:
On 22/03/18 17:30, Jan Beulich wrote:
On 21.03.18 at 13:51, wrote:
>> Instead of flushing the TLB from global pages when switchin
>>> On 22.03.18 at 20:13, wrote:
> c/s 65e35549 "x86/PV: support data breakpoint extension registers"
> accidentally broke the handing of writes. The call to activate_debugregs()
> doesn't write %dr7 as v->arch.debugreg[7] hasn't been updated yet, and the
> break skips the intended write to %dr7.
>>> On 23.03.18 at 01:13, wrote:
> flight 121031 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/121031/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr
flight 121026 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121026/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
120952
test-armhf-armhf-
>>> On 22.03.18 at 19:18, wrote:
> On 22/03/18 17:30, Jan Beulich wrote:
> On 21.03.18 at 13:51, wrote:
>>> Instead of flushing the TLB from global pages when switching address
>>> spaces with XPTI being active just disable global pages via %cr4
>>> completely when a domain subject to XPTI is
On 23/03/18 08:46, Jan Beulich wrote:
On 22.03.18 at 19:18, wrote:
>> On 22/03/18 17:30, Jan Beulich wrote:
>> On 21.03.18 at 13:51, wrote:
Instead of flushing the TLB from global pages when switching address
spaces with XPTI being active just disable global pages via %cr4
>>> On 22.03.18 at 16:29, wrote:
> On 22/03/18 15:12, Jan Beulich wrote:
>> Paul,
>>
>> our PV driver person has found a reproducible crash with ws2k8,
>> triggered by one of the WHQL tests. The guest get crashed because
>> the re-issue check of an ioreq close to the top of hvmemul_do_io()
>> fail
Commit 448c03b3cbe1487 ("tools/xenstore: try to get minimum thread
stack size for watch thread") added a dependency to libdl to
libxenstore. Unfortunately the way it was added requires now all
users of libxenstore to specify "-ldl" when linking. This can be
avoided by linking libxenstore.so specify
76 matches
Mail list logo
