flight 122637 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122637/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 122625
version targeted for testi
flight 122664 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122664/
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 122662 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt18 guest-start/debian.repeat fail REGR. vs. 122642
Tests which
flight 122654 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122654/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 16 guest-start/debian.repeat fail REGR. vs. 122642
test-armhf-a
flight 122631 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122631/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 broken
build-arm64-libvirt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-8897 / XSA-260
version 2
x86: mishandling of debug exceptions
UPDATES IN VERSION 2
Public release.
Updated .meta file
ISSUE DESCRIPTIO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-262
version 2
qemu may drive Xen into unbounded loop
UPDATES IN VERSION 2
Public release.
Updated .meta file
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-261
version 2
x86 vHPET interrupt injection errors
UPDATES IN VERSION 2
Versions 3.1 ... 3.3 don't appear to be vulnerable.
Public r
Am Tue, 8 May 2018 13:31:43 +0200
schrieb Olaf Hering :
> On the sending side offset 0xc9 is unlocked on the other fd, which allows
> F_WRLCK to succeed:
>
> It seems on the receiving side some code forgets to unclock offset 0xc9,
> which causes F_WRLCK to fail:
It looks like the IDE unplug is
Hi,
On 08/05/18 17:20, Andrew Cooper wrote:
On 08/05/18 17:10, Roger Pau Monné wrote:
On Tue, May 08, 2018 at 02:03:04PM +0100, Andrew Cooper wrote:
c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
consumer of smap_policy. Looking at c/s 31ae587e6f which introduced
On 08/05/18 17:10, Roger Pau Monné wrote:
> On Tue, May 08, 2018 at 02:03:04PM +0100, Andrew Cooper wrote:
>> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
>> consumer of smap_policy. Looking at c/s 31ae587e6f which introduced the
>> smap_check logic, it exists only
On 08/05/18 17:05, George Dunlap wrote:
> On Tue, May 8, 2018 at 2:03 PM, Andrew Cooper
> wrote:
>> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
>> consumer of smap_policy. Looking at c/s 31ae587e6f which introduced the
>> smap_check logic, it exists only to work
On Tue, May 08, 2018 at 02:03:04PM +0100, Andrew Cooper wrote:
> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
> consumer of smap_policy. Looking at c/s 31ae587e6f which introduced the
> smap_check logic, it exists only to work around a bug in guest_walk_tables()
> w
On 08/05/18 18:05, George Dunlap wrote:
> On Tue, May 8, 2018 at 2:03 PM, Andrew Cooper
> wrote:
>> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
>> consumer of smap_policy. Looking at c/s 31ae587e6f which introduced the
>> smap_check logic, it exists only to work
On Tue, May 8, 2018 at 2:03 PM, Andrew Cooper wrote:
> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
> consumer of smap_policy. Looking at c/s 31ae587e6f which introduced the
> smap_check logic, it exists only to work around a bug in guest_walk_tables()
> was resolv
On Tue, 8 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/05/18 01:11, Stefano Stabellini wrote:
> > On Fri, 6 Apr 2018, Stefano Stabellini wrote:
> > > > > > > 3) Understand how to address dom0. FreeRTOS Dom0 sounds like a
> > > > > > > good
> > > > > > > solution.
> > > > > > > Next step:
On Tue, May 8, 2018 at 4:10 PM, Daniel P. Berrangé wrote:
>> With my Xen maintainer hat on: I wouldn't feel justified, personally,
>> in asking another project to continue supporting older versions. If
>> we didn't want to bump our own glib version, we would have to disable
>> "upstream" QEMU (as
On Tue, May 08, 2018 at 03:50:49PM +0100, George Dunlap wrote:
> On Fri, May 4, 2018 at 10:00 PM, Daniel P. Berrangé
> wrote:
> > CC'ing xen-devel in case Xen maintainers have a need for something that
> > will that conflict with this proposal wrt supported build platforms.
>
> Thanks for the he
On 08/05/2018 16:50, George Dunlap wrote:
> Tailing into that, with my CentOS package maintainer hat on: You said
> that the code in question compiled on RHEL 6 because RH had backported
> the function in question. Will QEMU continue to actually compile on
> RHEL 6 / CentOS 6? I.e., will configur
On Fri, May 4, 2018 at 10:00 PM, Daniel P. Berrangé wrote:
> CC'ing xen-devel in case Xen maintainers have a need for something that
> will that conflict with this proposal wrt supported build platforms.
Thanks for the heads-up. CC'ing some more people who usually have
opinions on this sort of t
Hi Julien,
On Tue, May 8, 2018 at 4:14 PM, Julien Grall wrote:
>
>
> On 07/05/18 15:55, Mirela Simonovic wrote:
>>
>> Hi Julien,
>
>
> Hi Mirela,
>
>> On Mon, Apr 30, 2018 at 4:47 PM, Julien Grall
>> wrote:
>>>
>>> On 27/04/18 18:12, Mirela Simonovic wrote:
printk("P2M: %d level
On 07/05/18 15:55, Mirela Simonovic wrote:
Hi Julien,
Hi Mirela,
On Mon, Apr 30, 2018 at 4:47 PM, Julien Grall wrote:
On 27/04/18 18:12, Mirela Simonovic wrote:
printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
- 4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
+
Mainly for the patch behind which relies on 'nr_phys_cpus' to estimate
the time needed for microcode update in the worst case.
Signed-off-by: Chao Gao
---
v3:
- new
---
xen/arch/x86/smpboot.c| 13 +
xen/include/asm-x86/smp.h | 3 +++
2 files changed, 16 insertions(+)
diff --g
This patch ports microcode improvement patches from linux kernel.
Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.
Gather all cores
Hi Stefano,
On 08/05/18 01:11, Stefano Stabellini wrote:
On Fri, 6 Apr 2018, Stefano Stabellini wrote:
3) Understand how to address dom0. FreeRTOS Dom0 sounds like a good
solution.
Next step: reach out to Dornerworks and/or others that worked with
FreeRTOS on Xen before. Figure out whether Free
On 05/08/2018 02:08 PM, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH v3 0/2] fix several issues in
> documentation"):
>> On 08/05/18 11:25, George Dunlap wrote:
>>> But maybe that's a discussion to have when we open the 4.12 development
>>> window.
>>
>> Another point is to a
On Fri, May 04, 2018 at 09:46:33AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53, wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -383,9 +383,13 @@ __efi64_mb2_start:
> > jmp x86_32_switch
> >
> > .Lefi_multiboot2_proto:
> > -/* Zero
On 05/08/2018 02:00 PM, Andrew Cooper wrote:
> On 08/05/18 13:58, George Dunlap wrote:
>> On 05/07/2018 11:16 AM, Juergen Gross wrote:
>>> "make -C docs all" fails due to incorrect markdown syntax in
>>> feature-levelling.pandoc. Correct it.
>>>
>>> Signed-off-by: Juergen Gross
>> I tripped across
Juergen Gross writes ("Re: [Xen-devel] [PATCH v3 0/2] fix several issues in
documentation"):
> On 08/05/18 11:25, George Dunlap wrote:
> > But maybe that's a discussion to have when we open the 4.12 development
> > window.
>
> Another point is to add a call of "make -C docs all" to the OSStest
>
On 08/05/18 14:56, George Dunlap wrote:
> On 05/08/2018 07:47 AM, Juergen Gross wrote:
>> "make -C docs all" fails due to incorrect markdown syntax in
>> intel_psr_cat_cdp.pandoc. Correct it.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> docs/features/intel_psr_cat_cdp.pandoc | 562
>> +++
c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
consumer of smap_policy. Looking at c/s 31ae587e6f which introduced the
smap_check logic, it exists only to work around a bug in guest_walk_tables()
was resolved by the aformentioned commit.
Remove the unused variables a
On Fri, May 04, 2018 at 09:40:51AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53, wrote:
> > In comparison to ELF the PE format is not supported by the Multiboot
> > protocol. So, if we wish to load xen.efi using this protocol we have
> > to put header_addr, load_addr, load_end_addr, bss_en
On 08/05/18 13:58, George Dunlap wrote:
> On 05/07/2018 11:16 AM, Juergen Gross wrote:
>> "make -C docs all" fails due to incorrect markdown syntax in
>> feature-levelling.pandoc. Correct it.
>>
>> Signed-off-by: Juergen Gross
> I tripped across this one too; and in any case the original code is
>
On 05/07/2018 11:16 AM, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> feature-levelling.pandoc. Correct it.
>
> Signed-off-by: Juergen Gross
I tripped across this one too; and in any case the original code is
pretty clearly not right:
Reviewed-by: George
On 05/08/2018 07:47 AM, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> intel_psr_cat_cdp.pandoc. Correct it.
>
> Signed-off-by: Juergen Gross
> ---
> docs/features/intel_psr_cat_cdp.pandoc | 562
> ++---
> 1 file changed, 300 in
On Fri, May 04, 2018 at 09:38:03AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53, wrote:
> > This is the first step to get:
> > - one binary which can be loaded by the EFI loader,
> > Multiboot and Multiboot2 protocols,
> > - if we wish, in the future we can drop xen/xen.gz
> >
On 08/05/18 12:38, Jason Andryuk wrote:
> On Mon, May 7, 2018 at 4:05 PM, Andrew Cooper
> wrote:
>> On 07/05/2018 20:57, Jason Andryuk wrote:
>>> commit 4c5d78a10dc89427140a50a1df5a0b8e9f073e82 (x86/pagewalk:
>>> Re-implement the pagetable walker) removed honoring the
>>> smap_check_policy of the
On Mon, Apr 30, 2018 at 09:56:38AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53, wrote:
> > We need the POSIX time to properly fill the TimeDateStamp field in the PE
> > header.
> >
> > Signed-off-by: Daniel Kiper
> > ---
> > xen/Makefile | 14 --
> > xen/in
On 05/08/2018 12:34 PM, Oleksandr Andrushchenko wrote:
On 05/08/2018 12:26 PM, Dan Carpenter wrote:
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
frontend")
Signed-off-by: Dan Carpenter
Thank you,
Reviewed-
On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:
On 05/08/2018 12:28 PM, Dan Carpenter wrote:
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
frontend")
Signed-o
On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:
On 05/08/2018 12:27 PM, Dan Carpenter wrote:
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
On Mon, May 7, 2018 at 4:05 PM, Andrew Cooper wrote:
> On 07/05/2018 20:57, Jason Andryuk wrote:
>> commit 4c5d78a10dc89427140a50a1df5a0b8e9f073e82 (x86/pagewalk:
>> Re-implement the pagetable walker) removed honoring the
>> smap_check_policy of the running VCPU. guest_walk_tables is used by
>> c
Am Mon, 7 May 2018 17:19:46 +0200
schrieb Olaf Hering :
> What I gathered during debugging so far is that somehow qemu on the receiving
> side locks a region twice:
After further debugging with many wild printfs:
On the receiving side blockdev_init sets BDRV_O_INACTIVE because
RUN_STATE_INMIGRA
On 08/05/2018, 11:48, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> On 04/05/2018, 18:43, "Ian Jackson" wrote:
> > +my $patch_prefix = "0
flight 74691 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74691/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-daily-netboot-pvgrub 10 debian-di-install fail REGR.
vs. 7465
Ian Jackson writes ("xenbits DSA ssh keys to be disabled"):
> DSA keys ("dss") are 1024-bit and not really considered good practice
> any more. By default in Debian's openssh-server, they are now
> disabled.
>
> We are going to disable these soon. Can you please make sure that the
> ssh keys you
On 05/08/2018 07:47 AM, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> livepatch.markdown. Correct it.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Konrad Rzeszutek Wilk
Git complains of trailing whitespace:
Importing patch "doc-correct-livepatch-markd
Lars Kurth writes ("Re: [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl
script to optimise the workflow when using git format-patch with
get_maintainer.pl"):
> On 04/05/2018, 18:43, "Ian Jackson" wrote:
> > +my $patch_prefix = "0"; # Use a 0, such that v* does not get picked up
> > +
On Mon, May 07, 2018 at 04:40:12PM +0300, Alexandru Isaila wrote:
> This patch is adding a way to enable/disable inguest pagefault
> events. It introduces the xc_monitor_inguest_pagefault function
> and adds the inguest_pagefault_disabled in the monitor structure.
> This is needed by the introspect
flight 122630 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122630/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
test-amd64-amd64-xl-qemuu-debianhvm-amd64-
On Mon, May 07, 2018 at 04:07:45PM -0500, Janakarajan Natarajan wrote:
> Rename vlapic_read_aligned() to vlapic_reg_read() to make it a pair of
> vlapic_reg_write().
>
> Signed-off-by: Janakarajan Natarajan
> ---
> xen/arch/x86/hvm/vlapic.c | 10 +-
> 1 file changed, 5 insertions(+), 5 d
On 08/05/18 10:33, Roger Pau Monne wrote:
> Class 0 devices are legacy pre PCI 2.0 devices that didn't have a
> class code. Treat them as endpoints, so that they can be handled by
> the IOMMU and properly passed-through to the hardware domain.
>
> Such device has been seen on a Super Micro server,
From: Juergen Gross
"make -C docs all" fails due to incorrect markdown syntax in
livepatch.markdown. Correct it.
Signed-off-by: Juergen Gross
Reviewed-by: Konrad Rzeszutek Wilk
Misc fixes:
* Insert real URLs
* Drop trailing whitespace
* Consistent alignment and indentation for code blocks
On Tue, May 08, 2018 at 11:30:18AM +0200, Juergen Gross wrote:
> On 08/05/18 11:23, Roger Pau Monne wrote:
> > Hello,
> >
> > There's a bug in current vpci code for MSI emulation when updating an
> > already bound interrupt. The code will disable and enable the interrupt
> > in order to update the
On 05/08/2018 12:28 PM, Dan Carpenter wrote:
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
Thank you,
Reviewed-by: Oleksandr A
On 05/08/2018 12:27 PM, Dan Carpenter wrote:
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xe
On 05/08/2018 12:26 PM, Dan Carpenter wrote:
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
Thank you,
Reviewed-by: Oleksandr Andrushchenko
diff --git a/drivers/gpu/dr
Class 0 devices are legacy pre PCI 2.0 devices that didn't have a
class code. Treat them as endpoints, so that they can be handled by
the IOMMU and properly passed-through to the hardware domain.
Such device has been seen on a Super Micro server, lspci -vv reports:
00:13.0 Non-VGA unclassified de
On 08/05/18 11:25, George Dunlap wrote:
> On 05/08/2018 07:47 AM, Juergen Gross wrote:
>> Some documents contain invalid pandoc syntax leading to failures when
>> creating PDFs from them, e.g. when calling "make all" in the docs
>> directory.
>>
>> Correct those by using proper lists, code blocks a
On 08/05/18 11:23, Roger Pau Monne wrote:
> Hello,
>
> There's a bug in current vpci code for MSI emulation when updating an
> already bound interrupt. The code will disable and enable the interrupt
> in order to update the binding, which calls unmap_domain_pirq that
> disables the global MSI enab
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_fr
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carp
On 05/08/2018 07:47 AM, Juergen Gross wrote:
> Some documents contain invalid pandoc syntax leading to failures when
> creating PDFs from them, e.g. when calling "make all" in the docs
> directory.
>
> Correct those by using proper lists, code blocks and special character
> escaping.
It's probabl
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..8615e8522c7a 1006
And put it in a separate update function. This is required in order to
improve binding of MSI PIRQs when using vPCI.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/vmsi.c | 73 +
1 file ch
Current update process of already bound MSI interrupts is wrong
because unmap_domain_pirq calls pci_disable_msi, which disables MSI
interrupts on the device. On the other hand map_domain_pirq doesn't
enable MSI, so the current update process of already enabled MSI
entries is wrong because MSI contr
Hello,
There's a bug in current vpci code for MSI emulation when updating an
already bound interrupt. The code will disable and enable the interrupt
in order to update the binding, which calls unmap_domain_pirq that
disables the global MSI enable flag in the control register.
In order to fix this
On Tue, May 08, 2018 at 10:20:20AM +0100, Wei Liu wrote:
> On Wed, Mar 07, 2018 at 02:45:50PM +, Ian Jackson wrote:
> > Wei Liu writes ("[OSSTEST PATCH v2 14/19] ts-guests-nbd-mirror: make it
> > work with stretch"):
> > > On the server side, only add oldstyle= and port= on Wheezy and Jessie.
On Wed, Mar 07, 2018 at 02:45:50PM +, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH v2 14/19] ts-guests-nbd-mirror: make it work
> with stretch"):
> > On the server side, only add oldstyle= and port= on Wheezy and Jessie.
> > Stretch doesn't support or need those anymore.
> ...
> > +
On Wed, Mar 07, 2018 at 03:11:47PM +, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH v2 13/19] TestSupport: add dpkg option when
> installing packages"):
> > Upgrading configuration file of nbd-client is controlled by dpkg in
> > stretch. Add dpkg option to keep old configuration file(s)
On Wed, Mar 07, 2018 at 03:04:41PM +, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH v2 08/19] ts-guests-nbd-mirror: use
> target_{get,put}file_root to transfter cfg"):
> > The original code used target_cmd_output_root which caused a trailing
> > new line to be deleted, which caused libv
On 2018/5/8 15:02, Juergen Gross wrote:
On 08/05/18 05:34, Jia-Ju Bai wrote:
The read operation to "req->type" is protected by
the lock on line 128, but the write operation to
this data on line 118 is not protected by the lock.
Thus, there may exist a data race for "req->type".
To fix this da
On 08/05/18 05:34, Jia-Ju Bai wrote:
> The read operation to "req->type" is protected by
> the lock on line 128, but the write operation to
> this data on line 118 is not protected by the lock.
> Thus, there may exist a data race for "req->type".
>
> To fix this data race, the write operation to "
73 matches
Mail list logo