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
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
On 03/21/2018 03:26 PM, Julien Grall wrote:
Hi Manish,
On 03/21/2018 09:38 AM, Manish Jaggi wrote:
On 03/21/2018 02:15 PM, Julien Grall wrote:
On 03/21/2018 04:58 AM, Manish Jaggi wrote:
Hi Julien,
On 03/20/2018 01:16 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi
>>> 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
>>> 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
>>> 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
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
>>> 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 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:
>
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
>>> 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
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
(Sorry for the formatting)
On 23 Mar 2018 14:46, "Manish Jaggi" wrote:
On 03/21/2018 03:26 PM, Julien Grall wrote:
> Hi Manish,
>
> On 03/21/2018 09:38 AM, Manish Jaggi wrote:
>
>>
>>
>> On 03/21/2018 02:15 PM, Julien Grall wrote:
>>
>>>
>>>
>>> On 03/21/2018 04:58
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
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
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
>
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
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
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
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
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
>>> 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 )
> -
> -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
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
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
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
> -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 ;
>>> 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
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
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.
> >
> -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
>
>
>>> 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:
>>
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
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:
>>> 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:
>>
>>> 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
>
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
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
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
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
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 ++
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
>
> -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:
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
>>
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
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)
> > >
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
>
> -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
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
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
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.
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
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
>>> 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
>
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
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
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
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 +-
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
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
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
>>> 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.
>>> 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) )
> +
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
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:
>>
>>> 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
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
> -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
>>> 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
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
>>> 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
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 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
>>
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:
>
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
75 matches
Mail list logo