flight 125606 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125606/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 07eba7069d4c23e9b15caa1e729682a88ddf4ada
baseline version:
ovmf
flight 125573 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125573/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125178
flight 125567 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125520
Thank you Julien. I addressed almost all comments. I had a problem with
the implementation of buffering the chars, and I have an alternative
comment on the function sharing. See below.
On Tue, 24 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 07/07/18 00:12, Stefano Stabellini wrote:
> >
flight 125570 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 125487
build-arm64-libvirt
On Tue, Jul 24, 2018 at 3:02 PM, Jiri Kosina wrote:
> On Tue, 24 Jul 2018, Srivatsa S. Bhat wrote:
>
>> However, if you are proposing that you'd like to contribute the enhanced
>> PTI/Spectre (upstream) patches from the SLES 4.4 tree to 4.4 stable, and
>> have them merged instead of this patch
On Tue, 24 Jul 2018, Andrii Anisov wrote:
> On 07.07.18 02:13, Stefano Stabellini wrote:
> > Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
> > MPSOC and ALL. They enable the required options for their hardware
> > platform. ALL enables all available platforms and it's the
On 07/26/2018 09:34 AM, Jan Beulich wrote:
On 26.06.18 at 09:32, wrote:
>> Use EFLAGS.IF for all ordinary purposes; there's in particular no need
>> to unduly defer NMI/#MC. Clear/set GIF solely around VMRUN itself. This
>> has the additional advantage that svm_stgi_label now indeed marks
On Wed, 25 Jul 2018, Juergen Gross wrote:
> Its time to plan the Xen 4.12 release dates.
>
> There have been concerns with the schedule of 6 months between releases,
> as this scheme is leading to too many supported versions of Xen at a
> time. The needed resources to backport bug fixes and
Exclude named output files from the Xen tree setup.
The linkfarm.stamp content will differ between top level "make"
and "make install" invocations, due to the introduction of these
output files that are produced during the "make" build.
Filter these out to prevent an unnecessary rebuild of the
On Wed, Jul 25, 2018 at 1:10 AM, Jan Beulich wrote:
> >>> On 25.07.18 at 02:28, wrote:
> > --- a/tools/firmware/xen-dir/Makefile
> > +++ b/tools/firmware/xen-dir/Makefile
> > @@ -11,6 +11,10 @@ D=xen-root
> > LINK_DIRS=config xen
> > LINK_FILES=Config.mk
> >
> > +# Files to exclude from the
This run is configured for baseline tests only.
flight 75013 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75013/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75012
On Mon, Jul 23, 2018 at 11:11 AM George Dunlap wrote:
>
> The altp2m functionality was originally envisioned to be used in
> several different configurations, one of which was a single in-guest
> agent that had full operational control of altp2m. This required the
> single hypercall to be an
flight 125597 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125597/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4a723ed258367471eac8b4ae32558f09ef65672e
baseline version:
ovmf
flight 125561 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125561/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail in
125525 REGR. vs. 125138
On Wed, Jul 25, 2018 at 05:19:03PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Roger Pau Monné
> > Sent: 25 July 2018 15:12
> > To: berca...@amazon.com
> > Cc: xen-devel ; David Woodhouse
> > ; Jan
flight 125558 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125558/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 125169
On Wed, Jun 27, 2018 at 05:16:07PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v3 31/31] libxl: QEMU startup sync based on
> QMP"):
> > This is only activated when dm_restrict=1, as explained in the previous
> > patch "libxl_dm: Pre-open QMP socket for QEMU"
> ...
> > @@ -1603,11
32 bit gcc 8.1 non-debug build yields:
xenpmd.c:354:23: error: '%02x' directive output may be truncated writing
between 2 and 8 bytes into a region of size 3 [-Werror=format-truncation=]
snprintf(val, 3, "%02x",
^~~~
xenpmd.c:354:22: note: directive argument in the
Wei Liu (2):
tools: update ipxe changeset
xenpmd: make 32 bit gcc 8.1 non-debug build work
tools/firmware/etherboot/Makefile | 2 +-
tools/xenpmd/xenpmd.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
--
2.11.0
This placates gcc 8.1. The commit comes from ipxe master branch as of
July 25, 2018.
Signed-off-by: Wei Liu
---
tools/firmware/etherboot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/etherboot/Makefile
b/tools/firmware/etherboot/Makefile
index
>>> On 26.07.18 at 15:46, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 July 2018 14:41
>> To: Paul Durrant
>> Cc: Razvan Cojocaru ; Andrew Cooper
>> ; xen-devel > de...@lists.xenproject.org>; Tamas K Lengyel
>> Subject: RE: [PATCH v2] x86:
On Thu, Jul 26, 2018 at 1:19 PM, Juergen Gross wrote:
> On 26/07/18 13:27, George Dunlap wrote:
>> On Thu, Jul 26, 2018 at 12:22 PM, Juergen Gross wrote:
>>> I believe the right way would be to design a proper ballooning interface
>>> suitable for all kinds of guests from scratch. This should
On Thu, Jul 26, 2018 at 03:58:43PM +0200, Juergen Gross wrote:
> On 26/07/18 15:50, Roger Pau Monné wrote:
> > On Thu, Jul 26, 2018 at 01:22:33PM +0200, Juergen Gross wrote:
> >> On 26/07/18 13:11, Roger Pau Monné wrote:
> >>> On Thu, Jul 26, 2018 at 10:45:08AM +0100, George Dunlap wrote:
>
This run is configured for baseline tests only.
flight 75012 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75012/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75011
On 26/07/18 15:50, Roger Pau Monné wrote:
> On Thu, Jul 26, 2018 at 01:22:33PM +0200, Juergen Gross wrote:
>> On 26/07/18 13:11, Roger Pau Monné wrote:
>>> On Thu, Jul 26, 2018 at 10:45:08AM +0100, George Dunlap wrote:
On Thu, Jul 26, 2018 at 12:07 AM, Boris Ostrovsky
wrote:
> On
On Thu, Jul 26, 2018 at 01:22:33PM +0200, Juergen Gross wrote:
> On 26/07/18 13:11, Roger Pau Monné wrote:
> > On Thu, Jul 26, 2018 at 10:45:08AM +0100, George Dunlap wrote:
> >> On Thu, Jul 26, 2018 at 12:07 AM, Boris Ostrovsky
> >> wrote:
> >>> On 07/25/2018 02:56 PM, Andrew Cooper wrote:
>
On Thu, Jul 26, 2018 at 09:08:08AM -0400, Connor Davis wrote:
>
> On July 26, 2018 4:03 AM, Roger Pau Monné wrote:
>
> > On Wed, Jul 25, 2018 at 04:10:59PM -0400, Connor Davis wrote:
> >
> > > When booting into dom0=pvh, using the serial console prevents
> > > dom0 from booting. Serial works
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 July 2018 14:41
> To: Paul Durrant
> Cc: Razvan Cojocaru ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>; Tamas K Lengyel
> Subject: RE: [PATCH v2] x86: assorted array_index_nospec() insertions
>
>
On 07/26/2018 04:07 PM, Jan Beulich wrote:
> Don't chance having Spectre v1 (including BCBS) gadgets. In some of the
> cases the insertions are more of precautionary nature rather than there
> provably being a gadget, but I think we should err on the safe (secure)
> side here.
>
> Signed-off-by:
>>> On 26.07.18 at 15:25, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 July 2018 14:07
> Using something called 'array_index_nospec()' for an array size and having
> to adjust by 1 is kind of a bit ugly but it looks correct.
Indeed, and as you may have seen from the change
>>> On 26.07.18 at 15:08, wrote:
> I'm not pressing any keys. I tried again with iommu=debug and made sure not
> to press anything. Still getting an infinite loop. I attached the log for
> reference.
Well, Xen is definitely receiving keys. Is the same not the case when you
boot PV Dom0 on the
>>> On 26.06.18 at 09:32, wrote:
> Use EFLAGS.IF for all ordinary purposes; there's in particular no need
> to unduly defer NMI/#MC. Clear/set GIF solely around VMRUN itself. This
> has the additional advantage that svm_stgi_label now indeed marks the
> only place where GIF is being set.
>
> A
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 July 2018 14:07
> To: xen-devel
> Cc: Razvan Cojocaru ; Andrew Cooper
> ; Paul Durrant ;
> Tamas K Lengyel
> Subject: [PATCH v2] x86: assorted array_index_nospec() insertions
>
> Don't chance having Spectre
Don't chance having Spectre v1 (including BCBS) gadgets. In some of the
cases the insertions are more of precautionary nature rather than there
provably being a gadget, but I think we should err on the safe (secure)
side here.
Signed-off-by: Jan Beulich
---
v2: Re-base. Drop guest_cpuid()
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Wei Liu
> Sent: 26 July 2018 13:54
> To: Ian Jackson
> Cc: Xen-devel ; Wei Liu
> ; Marek Marczykowski
> ; Jan Beulich ; Tim
> (Xen.org)
> Subject: Re: [Xen-devel] [PATCH RFC] tools/kdd:
On Thu, Jul 26, 2018 at 01:37:45PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH RFC] tools/kdd: avoid adversarial optimisation
> hazard"):
> > There have been two attempts to fix kdd build with gcc 8.1
> > (437e00fe and 2de2b10b), but building with gcc 8.1 32 bit non-debug
> > build still
flight 125590 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125590/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cf4e79e466f951e72c2cbd40002c71fdaddad389
baseline version:
ovmf
Wei Liu writes ("[PATCH RFC] tools/kdd: avoid adversarial optimisation hazard"):
> There have been two attempts to fix kdd build with gcc 8.1
> (437e00fe and 2de2b10b), but building with gcc 8.1 32 bit non-debug
> build still yields the same error as in 437e00fe.
>
> Ian wrote about adversarial
On 26/07/18 13:27, George Dunlap wrote:
> On Thu, Jul 26, 2018 at 12:22 PM, Juergen Gross wrote:
>> I believe the right way would be to design a proper ballooning interface
>> suitable for all kinds of guests from scratch. This should include how
>> to deal with hotplug of memory or booting with
On Thu, Jul 26, 2018 at 12:22 PM, Juergen Gross wrote:
> I believe the right way would be to design a proper ballooning interface
> suitable for all kinds of guests from scratch. This should include how
> to deal with hotplug of memory or booting with mem < mem_max. Whether
> PoD should be
This run is configured for baseline tests only.
flight 75011 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75011/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75009
On Thu, Jul 26, 2018 at 12:11 PM, Roger Pau Monné wrote:
> On Thu, Jul 26, 2018 at 10:45:08AM +0100, George Dunlap wrote:
>> On Thu, Jul 26, 2018 at 12:07 AM, Boris Ostrovsky
>> wrote:
>> > On 07/25/2018 02:56 PM, Andrew Cooper wrote:
>> >> On 25/07/18 17:29, Juergen Gross wrote:
>> >>> On
On Thu, Jul 26, 2018 at 10:45:08AM +0100, George Dunlap wrote:
> On Thu, Jul 26, 2018 at 12:07 AM, Boris Ostrovsky
> wrote:
> > On 07/25/2018 02:56 PM, Andrew Cooper wrote:
> >> On 25/07/18 17:29, Juergen Gross wrote:
> >>> On 25/07/18 18:12, Roger Pau Monné wrote:
> On Wed, Jul 25, 2018 at
On Wed, Jul 25, 2018 at 06:29:25PM +0200, Juergen Gross wrote:
> On 25/07/18 18:12, Roger Pau Monné wrote:
> > On Wed, Jul 25, 2018 at 05:05:35PM +0300, berca...@amazon.com wrote:
> >> On 07/25/2018 05:02 PM, Wei Liu wrote:
> >>> On Wed, Jul 25, 2018 at 03:41:11PM +0200, Juergen Gross wrote:
>
On Thu, Jul 26, 2018 at 10:31:21AM +0200, Juergen Gross wrote:
> On 26/07/18 10:15, berca...@amazon.com wrote:
> > On 07/25/2018 07:12 PM, Roger Pau Monné wrote:
> >> On Wed, Jul 25, 2018 at 05:05:35PM +0300, berca...@amazon.com wrote:
> >>> On 07/25/2018 05:02 PM, Wei Liu wrote:
> On Wed,
There have been two attempts to fix kdd build with gcc 8.1
(437e00fe and 2de2b10b), but building with gcc 8.1 32 bit non-debug
build still yields the same error as in 437e00fe.
Ian wrote about adversarial optimisation in [0], one of the key points
is that computing an out-of-bounds pointer is UB.
On Wed, Jul 25, 2018 at 04:10:59PM -0400, Connor Davis wrote:
> When booting into dom0=pvh, using the serial console prevents
> dom0 from booting. Serial works until Xen tries to hand off to dom0.
> The specific crash varies with the arguments passed to iommu:
>
> iommu=1,debug console=com1
>>> On 25.07.18 at 21:15, wrote:
> Copying all of struct cpu_user_regs is generally unsafe, as the structure
> extends beyond the hardware exception frame.
>
> This generally copies 32 bytes beyond the top of the valid stack frame, and in
> the case of the top IST stack, hits the unmapped guard
On Thu, Jul 26, 2018 at 12:07 AM, Boris Ostrovsky
wrote:
> On 07/25/2018 02:56 PM, Andrew Cooper wrote:
>> On 25/07/18 17:29, Juergen Gross wrote:
>>> On 25/07/18 18:12, Roger Pau Monné wrote:
On Wed, Jul 25, 2018 at 05:05:35PM +0300, berca...@amazon.com wrote:
> On 07/25/2018 05:02 PM,
On 26/07/18 01:07, Boris Ostrovsky wrote:
> On 07/25/2018 02:56 PM, Andrew Cooper wrote:
>> On 25/07/18 17:29, Juergen Gross wrote:
>>> On 25/07/18 18:12, Roger Pau Monné wrote:
On Wed, Jul 25, 2018 at 05:05:35PM +0300, berca...@amazon.com wrote:
> On 07/25/2018 05:02 PM, Wei Liu wrote:
flight 125584 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125584/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 98d20e44dc72d9858523687fda11ab8fc570fcec
baseline version:
ovmf
On Thu, Jul 26, 2018 at 09:09:35AM +0100, Andrew Cooper wrote:
> On 26/07/2018 08:46, Wei Liu wrote:
> > On Wed, Jul 25, 2018 at 04:44:25PM -0700, Manjukumar Matha wrote:
> >> gcc-8.1 complains:
> >>
> >> libxl_arm_acpi.c:208:5: error: 'memcpy' forming offset [5, 6] is out of
> >> the bounds [0,
On Wed, Jul 25, 2018 at 06:15:20PM -0700, Christopher Clark wrote:
> On Wed, Jul 25, 2018 at 1:53 AM, Wei Liu wrote:
>
> > On Wed, Jul 25, 2018 at 09:49:39AM +0100, Wei Liu wrote:
> > > On Sat, Jul 21, 2018 at 02:14:12AM +0200, Marek Marczykowski-Górecki
> > wrote:
> > >
> > > > +
> > > > +
flight 75010 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75010/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 74988
jobs:
build-amd64 pass
build-armhf
On 26/07/18 10:15, berca...@amazon.com wrote:
> On 07/25/2018 07:12 PM, Roger Pau Monné wrote:
>> On Wed, Jul 25, 2018 at 05:05:35PM +0300, berca...@amazon.com wrote:
>>> On 07/25/2018 05:02 PM, Wei Liu wrote:
On Wed, Jul 25, 2018 at 03:41:11PM +0200, Juergen Gross wrote:
> On 25/07/18
On 07/25/2018 07:12 PM, Roger Pau Monné wrote:
On Wed, Jul 25, 2018 at 05:05:35PM +0300, berca...@amazon.com wrote:
On 07/25/2018 05:02 PM, Wei Liu wrote:
On Wed, Jul 25, 2018 at 03:41:11PM +0200, Juergen Gross wrote:
On 25/07/18 15:35, Roger Pau Monné wrote:
What could be causing the
On 26/07/2018 08:46, Wei Liu wrote:
> On Wed, Jul 25, 2018 at 04:44:25PM -0700, Manjukumar Matha wrote:
>> gcc-8.1 complains:
>>
>> libxl_arm_acpi.c:208:5: error: 'memcpy' forming offset [5, 6] is out of
>> the bounds [0, 4] [-Werror=array-bounds]
>> memcpy(h->oem_id, ACPI_OEM_ID,
flight 125552 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125552/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
On Wed, Jul 25, 2018 at 04:44:25PM -0700, Manjukumar Matha wrote:
> gcc-8.1 complains:
>
> libxl_arm_acpi.c:208:5: error: 'memcpy' forming offset [5, 6] is out of
> the bounds [0, 4] [-Werror=array-bounds]
> memcpy(h->oem_id, ACPI_OEM_ID, sizeof(h->oem_id));
>
flight 125551 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125551/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 123554
61 matches
Mail list logo
