On 18.01.2021 21:15, Claudemir Todo Bom wrote:
> Sorry for the simultaneous post on xen-users and xen-devel, but as I noted
> that the problem appears only for versions of xen that are >= 4.9, I think
> that developers may have a look at this.
Dropping xen-users.
> I recently bought a generic mai
On 19.01.2021 01:32, Andrew Cooper wrote:
> Similarly to c/s 98d4d6d8a6 "xen/domain: Introduce domain_teardown()",
> introduce a common mechanism for restartable per-vcpu teardown logic.
>
> Extend the PROGRESS() mechanism to support saving and restoring the vcpu loop
> variable across hypercalls.
Hi Igor,
On 13/01/2021 03:42, Igor Druzhinin wrote:
We faced a problem with passing through a PCI device with 64GB BAR to
UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at
64G address which pushes physical address space to 37 bits. That is above
36-bit width that OVMF expo
This code has been copied in 3 places, but it is broken and dangerous.
For all these cases, the domain destruction path will underflow the whichever
reference failed to be taken, leading to all kinds of more fun bugs.
Crashing instantly is strictly less-bad behaviour.
Signed-off-by: Andrew Coope
On 19/01/2021 09:14, Jan Beulich wrote:
> On 19.01.2021 01:32, Andrew Cooper wrote:
>> Similarly to c/s 98d4d6d8a6 "xen/domain: Introduce domain_teardown()",
>> introduce a common mechanism for restartable per-vcpu teardown logic.
>>
>> Extend the PROGRESS() mechanism to support saving and restorin
On Tue, Jan 19, 2021 at 08:43:01AM +0100, Jürgen Groß wrote:
> On 18.01.21 16:15, Roger Pau Monne wrote:
> > Don't require the discard-alignment xenstore node to be present in
> > order to correctly setup the feature. This can happen with versions of
> > QEMU that only write the discard-granularity
On 19.01.21 11:06, Roger Pau Monné wrote:
On Tue, Jan 19, 2021 at 08:43:01AM +0100, Jürgen Groß wrote:
On 18.01.21 16:15, Roger Pau Monne wrote:
Don't require the discard-alignment xenstore node to be present in
order to correctly setup the feature. This can happen with versions of
QEMU that on
On Tue, Jan 19, 2021 at 11:11:26AM +0100, Jürgen Groß wrote:
> On 19.01.21 11:06, Roger Pau Monné wrote:
> > On Tue, Jan 19, 2021 at 08:43:01AM +0100, Jürgen Groß wrote:
> > > On 18.01.21 16:15, Roger Pau Monne wrote:
> > > > Don't require the discard-alignment xenstore node to be present in
> > >
This is inline with the specification described in blkif.h:
* discard-granularity: should be set to the physical block size if
node is not present.
* discard-alignment, discard-secure: should be set to 0 if node not
present.
This was detected as QEMU would only create the discard-granular
On Mon, Jan 18, 2021 at 05:48:37PM +, Andrew Cooper wrote:
> On 18/01/2021 17:10, Roger Pau Monné wrote:
> > On Mon, Jan 18, 2021 at 05:04:19PM +0100, Jan Beulich wrote:
> >> On 18.01.2021 16:54, Roger Pau Monné wrote:
> >>> On Mon, Jan 18, 2021 at 12:05:12PM +0100, Jan Beulich wrote:
> On
On 19.01.21 11:57, Roger Pau Monne wrote:
This is inline with the specification described in blkif.h:
* discard-granularity: should be set to the physical block size if
node is not present.
* discard-alignment, discard-secure: should be set to 0 if node not
present.
This was detecte
On 19/01/2021 11:14, Roger Pau Monné wrote:
> On Mon, Jan 18, 2021 at 05:48:37PM +, Andrew Cooper wrote:
>> On 18/01/2021 17:10, Roger Pau Monné wrote:
>>> On Mon, Jan 18, 2021 at 05:04:19PM +0100, Jan Beulich wrote:
On 18.01.2021 16:54, Roger Pau Monné wrote:
> On Mon, Jan 18, 2021 at
... so debug builds can see what went wrong, rather than getting an
unqualified -EINVAL out domain creation.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
---
xen/common/grant_table.c | 4
On 06.01.21 11:03, Borislav Petkov wrote:
On Thu, Dec 17, 2020 at 10:31:24AM +0100, Juergen Gross wrote:
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this a
On 19/01/2021 09:41, Andrew Cooper wrote:
> This code has been copied in 3 places, but it is broken and dangerous.
>
> For all these cases, the domain destruction path will underflow the whichever
> reference failed to be taken, leading to all kinds of more fun bugs.
>
> Crashing instantly is stric
On 07.01.21 20:08, Borislav Petkov wrote:
On Thu, Dec 17, 2020 at 10:31:25AM +0100, Juergen Gross wrote:
Instead of only supporting to modify instructions when a specific
feature is set, support doing so for the case a feature is not set.
As today a feature is specified using a 16 bit quantity
On 17.12.20 18:31, Michael Kelley wrote:
From: Juergen Gross Sent: Thursday, December 17, 2020 1:31 AM
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this a
On Tue, Jan 19, 2021 at 11:16:06AM +, Andrew Cooper wrote:
> On 19/01/2021 11:14, Roger Pau Monné wrote:
> > On Mon, Jan 18, 2021 at 05:48:37PM +, Andrew Cooper wrote:
> >> On 18/01/2021 17:10, Roger Pau Monné wrote:
> >>> On Mon, Jan 18, 2021 at 05:04:19PM +0100, Jan Beulich wrote:
>
On Tue, Jan 19, 2021 at 12:35:42PM +0100, Jürgen Groß wrote:
> In fact this should rather be named "X86_FEATURE_TRUE", as this is its
> semantics.
>
> And I think I can define it to the value 0x instead of using a
> "real" bit for it.
A real bit is cheap - a special value to pay attention to i
On 19.01.21 13:06, Borislav Petkov wrote:
On Tue, Jan 19, 2021 at 12:35:42PM +0100, Jürgen Groß wrote:
In fact this should rather be named "X86_FEATURE_TRUE", as this is its
semantics.
And I think I can define it to the value 0x instead of using a
"real" bit for it.
A real bit is cheap -
This code has been copied in 3 places, but it is problematic.
All cases will hit a BUG() later in domain teardown, when a the missing
type/count reference is underflowed.
Don't complicated the logic by leaving a totally unqualified domain crash, and
a timebomb which will be triggered by the tools
Forgot to Cc stable for the Fixes tag. Doing it now.
On Tue, Jan 19, 2021 at 11:57:27AM +0100, Roger Pau Monne wrote:
> This is inline with the specification described in blkif.h:
>
> * discard-granularity: should be set to the physical block size if
>node is not present.
> * discard-alignm
On 19.01.2021 12:40, Roger Pau Monné wrote:
> On Tue, Jan 19, 2021 at 11:16:06AM +, Andrew Cooper wrote:
>> On 19/01/2021 11:14, Roger Pau Monné wrote:
>>> On Mon, Jan 18, 2021 at 05:48:37PM +, Andrew Cooper wrote:
On 18/01/2021 17:10, Roger Pau Monné wrote:
> On Mon, Jan 18, 2021
> -Original Message-
> From: Andrew Cooper
> Sent: 19 January 2021 12:28
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Roger Pau Monné
> ; Wei Liu ; Paul Durrant ;
> Tamas K Lengyel
>
> Subject: [PATCH v2] x86/mm: Short circuit damage from "fishy" ref/typecount
> failure
>
>
On 19/01/2021 12:45, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 19 January 2021 12:28
>> To: Xen-devel
>> Cc: Andrew Cooper ; Jan Beulich
>> ; Roger Pau Monné
>> ; Wei Liu ; Paul Durrant ;
>> Tamas K Lengyel
>>
>> Subject: [PATCH v2] x86/mm: Short circuit
This code has been copied in 3 places, but it is problematic.
All cases will hit a BUG() later in domain teardown, when a the missing
type/count reference is underflowed.
Don't complicated the logic by leaving a totally unqualified domain crash, and
a timebomb which will be triggered by the tools
> -Original Message-
> From: Andrew Cooper
> Sent: 19 January 2021 13:03
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Roger Pau Monné
> ; Wei Liu ; Paul Durrant ;
> Tamas K Lengyel
>
> Subject: [PATCH v3] x86/mm: Short circuit damage from "fishy" ref/typecount
> failure
>
>
This is a revert of f5cfa0985673 plus a rework of the comment that
accompanies the setting of the flag so we don't forget why it needs to
be unconditionally set: it's indicating whether the version of Xen has
the original issue fixed and IOMMU entries are created for
grant/foreign maps.
If the fla
On Mon, Jan 11, 2021 at 03:45:18AM +, Igor Druzhinin wrote:
> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c
> b/OvmfPkg/XenPlatformPei/MemDetect.c
> index 1f81eee..4175a2f 100644
> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
> +++ b/OvmfPkg/XenPlatformPei/MemDetect.c
> @@ -227,6 +227,7 @@ GetFi
On 19/01/2021 13:20, Anthony PERARD wrote:
> On Mon, Jan 11, 2021 at 03:45:18AM +, Igor Druzhinin wrote:
>> diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c
>> b/OvmfPkg/XenPlatformPei/MemDetect.c
>> index 1f81eee..4175a2f 100644
>> --- a/OvmfPkg/XenPlatformPei/MemDetect.c
>> +++ b/OvmfPkg/XenP
flight 158500 linux-5.4 real [real]
flight 158518 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158500/
http://logs.test-lab.xenproject.org/osstest/logs/158518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
flight 158509 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 19.01.2021 14:07, Roger Pau Monne wrote:
> This is a revert of f5cfa0985673 plus a rework of the comment that
> accompanies the setting of the flag so we don't forget why it needs to
> be unconditionally set: it's indicating whether the version of Xen has
> the original issue fixed and IOMMU ent
On Tue, Jan 19, 2021 at 03:26:22PM +0100, Jan Beulich wrote:
> On 19.01.2021 14:07, Roger Pau Monne wrote:
> > This is a revert of f5cfa0985673 plus a rework of the comment that
> > accompanies the setting of the flag so we don't forget why it needs to
> > be unconditionally set: it's indicating wh
On Fri, Jan 15, 2021 at 11:10:44PM +, Andrew Cooper wrote:
> So all the moving parts are in one function.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Marek Kasiewicz
> CC: Norbert Kamiński
> CC: Michal Zygo
On 18.01.21 18:57, Rahul Singh wrote:
Hello Oleksandr,
Hi Rahul
On 18 Jan 2021, at 4:20 pm, Oleksandr wrote:
On 18.01.21 17:33, Rahul Singh wrote:
Hello Oleksandr,
On 11 Jan 2021, at 4:39 pm, Oleksandr wrote:
Hi Rahul
Hi Rahul
-
static int arm_smmu_device_probe(struct p
On 01/19/21 10:37, Julien Grall wrote:
> Hi Igor,
>
> On 13/01/2021 03:42, Igor Druzhinin wrote:
>> We faced a problem with passing through a PCI device with 64GB BAR to
>> UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at
>> 64G address which pushes physical address space t
Hello Oleksandr,
> On 19 Jan 2021, at 2:43 pm, Oleksandr wrote:
>
>
> On 18.01.21 18:57, Rahul Singh wrote:
>> Hello Oleksandr,
>
> Hi Rahul
>
>
>>
>>> On 18 Jan 2021, at 4:20 pm, Oleksandr wrote:
>>>
>>>
>>> On 18.01.21 17:33, Rahul Singh wrote:
Hello Oleksandr,
> On 11 J
On 19/01/2021 14:38, Roger Pau Monné wrote:
> On Fri, Jan 15, 2021 at 11:10:44PM +, Andrew Cooper wrote:
>> So all the moving parts are in one function.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>> CC: Wei Liu
>> CC: Mare
On Fri, Jan 15, 2021 at 11:10:45PM +, Andrew Cooper wrote:
> A subsequent change is going to introduce SKINIT support, wherein the APs will
> be already be in the wait-for-SIPI state, and an INIT must not be sent.
>
> Introduce a send_INIT boolean, so we can control sending an INIT IPI
> separ
Jan Beulich writes ("Re: [PATCH] xen/decompress: make helper symbols static"):
> On 18.01.2021 17:09, Ian Jackson wrote:
> > AFAICT, this patch
> >
> > * was first posted after the last posting date for Xen 4.15.
> > * is not a bugfix.
> >
> > In which case it has missed 4.15.
> >
> > Please cor
On 19.01.2021 15:31, Roger Pau Monné wrote:
> On Tue, Jan 19, 2021 at 03:26:22PM +0100, Jan Beulich wrote:
>> On 19.01.2021 14:07, Roger Pau Monne wrote:
>>> This is a revert of f5cfa0985673 plus a rework of the comment that
>>> accompanies the setting of the flag so we don't forget why it needs to
On 19/01/2021 14:58, Roger Pau Monné wrote:
> On Fri, Jan 15, 2021 at 11:10:45PM +, Andrew Cooper wrote:
>> A subsequent change is going to introduce SKINIT support, wherein the APs
>> will
>> be already be in the wait-for-SIPI state, and an INIT must not be sent.
>>
>> Introduce a send_INIT b
Only the 1st patch is strictly intended for 4.15, paralleling
the recent Dom0 side work (and re-using some of the files
introduced there, for the stubdom build), but later ones may
still want considering.
1: libxenguest: support zstd compressed kernels
2: xen/decompress: make helper symbols static
This follows the logic used for other decompression methods utilizing an
external library, albeit here we can't ignore the 32-bit size field
appended to the compressed image - its presence causes decompression to
fail. Leverage the field instead to allocate the output buffer in one
go, i.e. without
The individual decompression CUs need to only surface their top level
functions to other code. Arrange for everything else to be static, to
make sure no undue uses of that code exist or will appear without
explicitly noticing. (In some cases this also results in code size
reduction, but since this
Add a DOMPRINTF() other methods have, indicating success. To facilitate
this, introduce an "outsize" local variable and update *size as well as
*blob only once done. The latter then also avoids leaving a pointer to
freed memory in dom->kernel_blob in case of a decompression error.
Signed-off-by: J
The ones in xg_dom_decompress_unsafe.h suffice.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/tools/libs/guest/xg_dom_bzimageloader.c
+++ b/tools/libs/guest/xg_dom_bzimageloader.c
@@ -673,13 +673,6 @@ static int xc_try_zstd_decode(
#endif
-#else /* __MINIOS__ */
-
-int xc_try_bzip2_decode(s
In all cases the kernel build makes available the uncompressed size in
the final 4 bytes of the bzImage payload. Utilize this to avoid
repeated realloc()ing of the output buffer.
As a side effect this also addresses the previous mistaken return of 0
(success) from xc_try_{bzip2,lzma,xz}_decode() i
Hi Julien
+
PROGRESS(xen):
ret = relinquish_memory(d, &d->xenpage_list);
if ( ret )
diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index ae7ef96..9814481 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -16,6 +16,7 @@
* GNU General Public Licen
On Tue, Jan 19, 2021 at 01:36:22PM +0100, Roger Pau Monné wrote:
> Forgot to Cc stable for the Fixes tag. Doing it now.
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
On 19.01.2021 15:58, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] xen/decompress: make helper symbols static"):
>> On 18.01.2021 17:09, Ian Jackson wrote:
>>> AFAICT, this patch
>>>
>>> * was first posted after the last posting date for Xen 4.15.
>>> * is not a bugfix.
>>>
>>> In which cas
On Fri, Jan 15, 2021 at 11:10:46PM +, Andrew Cooper wrote:
> From: Norbert Kamiński
>
> For now, this is simply enough logic to let Xen come up after the bootloader
> has executed an SKINIT instruction to begin a Secure Startup.
Since I know very little about this, I might as well ask. Readi
On Tue, Jan 19, 2021 at 03:49:34PM +0100, Laszlo Ersek wrote:
> On 01/19/21 10:37, Julien Grall wrote:
> > Hi Igor,
> >
> > On 13/01/2021 03:42, Igor Druzhinin wrote:
> >> We faced a problem with passing through a PCI device with 64GB BAR to
> >> UEFI guest. The BAR is expectedly programmed into 6
On 19.01.2021 12:18, Andrew Cooper wrote:
> ... so debug builds can see what went wrong, rather than getting an
> unqualified -EINVAL out domain creation.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-27675 / XSA-331
version 3
Race condition in Linux event handler may crash dom0
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-29040 / XSA-355
version 3
stack corruption from XSA-346 change
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-27674 / XSA-286
version 6
x86 PV guest INVLPG-like flushes may leave stale TLB entries
UPDATES IN VERSION 6
CVE assigned.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-27673 / XSA-332
version 4
Rogue guests can cause DoS of Dom0 via high frequency events
UPDATES IN VERSION 4
CVE assigned.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-27670 / XSA-347
version 3
unsafe AMD IOMMU page table updates
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-27672 / XSA-345
version 4
x86: Race condition in Xen mapping code
UPDATES IN VERSION 4
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-27671 / XSA-346
version 3
undue deferral of IOMMU TLB flushes
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
On 19.01.2021 14:02, Andrew Cooper wrote:
> This code has been copied in 3 places, but it is problematic.
>
> All cases will hit a BUG() later in domain teardown, when a the missing
> type/count reference is underflowed.
I'm afraid I could use some help with this: Why would there
be a missing ref
On 15.01.2021 15:44, Roger Pau Monné wrote:
> On Fri, Jan 15, 2021 at 03:30:50PM +0100, Hubert Jasudowicz wrote:
>> This patch is a result of a downstream bug report[1]. Xen fails to
>> create a HVM domain while running under VMware Fusion 12.1.0 on
>> a modern Intel Core i9 CPU:
>>
>> (XEN) VMX: C
On Tue, Jan 19, 2021 at 03:05:38PM +, Andrew Cooper wrote:
> On 19/01/2021 14:58, Roger Pau Monné wrote:
> > On Fri, Jan 15, 2021 at 11:10:45PM +, Andrew Cooper wrote:
> >> A subsequent change is going to introduce SKINIT support, wherein the APs
> >> will
> >> be already be in the wait-fo
On 01/19/21 16:52, Anthony PERARD via groups.io wrote:
> On Tue, Jan 19, 2021 at 03:49:34PM +0100, Laszlo Ersek wrote:
>> On 01/19/21 10:37, Julien Grall wrote:
>>> Hi Igor,
>>>
>>> On 13/01/2021 03:42, Igor Druzhinin wrote:
We faced a problem with passing through a PCI device with 64GB BAR to
On 19/01/2021 15:48, Roger Pau Monné wrote:
> On Fri, Jan 15, 2021 at 11:10:46PM +, Andrew Cooper wrote:
>> From: Norbert Kamiński
>>
>> For now, this is simply enough logic to let Xen come up after the bootloader
>> has executed an SKINIT instruction to begin a Secure Startup.
> Since I know
flight 158524 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158524/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 19/01/2021 16:48, Jan Beulich wrote:
> On 19.01.2021 14:02, Andrew Cooper wrote:
>> This code has been copied in 3 places, but it is problematic.
>>
>> All cases will hit a BUG() later in domain teardown, when a the missing
>> type/count reference is underflowed.
> I'm afraid I could use some he
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-dom0pvh-xl-intel
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
flight 158504 qemu-mainline real [real]
flight 158527 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158504/
http://logs.test-lab.xenproject.org/osstest/logs/158527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 158507 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken
test-amd64-i386-qemuu-rhel6hvm-intel 7 xe
flight 158528 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158528/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 158522 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158522/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 83facfd184021874f95a6a34b2e47e0ebb34a762
baseline version:
ovmf 4f214830ce02cf588baba
flight 158511 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158511/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158496
test-amd64-amd64-xl-qemuu-win7-amd64
I have been trying the "[PATCH v2 1/5] libxenguest: support zstd
compressed kernel" patch, and (assuming I haven't broken anything trying
to migrate it to 4.14) it fails with
onfigure: error: Package requirements (libzstd) were not met:
Package 'libzstd', required by 'virtual:world', not found
flight 158520 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 158387
Tests which are faili
On Sun, 17 Jan 2021, Oleksandr wrote:
> On 15.01.21 02:55, Stefano Stabellini wrote:
> > On Tue, 12 Jan 2021, Oleksandr Tyshchenko wrote:
> > > From: Julien Grall
> > >
> > > This patch adds basic IOREQ/DM support on Arm. The subsequent
> > > patches will improve functionality and add remaining b
On Tue, 19 Jan 2021, Oleksandr wrote:
> > > > > > > PROGRESS(xen):
> > > > > > > ret = relinquish_memory(d, &d->xenpage_list);
> > > > > > > if ( ret )
> > > > > > > diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
> > > > > > > index ae7ef96..9814481 100644
> > > > > >
From: David Woodhouse
[ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ]
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in x
From: David Woodhouse
[ Upstream commit 3d7746bea92530e8695258a3cf3ddec7a135edd6 ]
Only the IPI-related functions in the smp_ops should be conditional
on the vector callback being available. The rest should still happen:
• xen_hvm_smp_prepare_boot_cpu()
This function does two things, both
From: David Woodhouse
[ Upstream commit b36b0fe96af13460278bf9b173beced1bd15f85d ]
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors
From: David Woodhouse
[ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ]
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in x
From: David Woodhouse
[ Upstream commit b36b0fe96af13460278bf9b173beced1bd15f85d ]
It's useful to be able to test non-vector event channel delivery, to make
sure Linux will work properly on older Xen which doesn't have it.
It's also useful for those working on Xen and Xen-compatible hypervisors
From: David Woodhouse
[ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ]
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in x
From: David Woodhouse
[ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ]
For a while, event channel notification via the PCI platform device
has been broken, because we attempt to communicate with xenstore before
we even have notifications working, with the xs_reset_watches() call
in x
On 1/19/21 8:25 PM, Sasha Levin wrote:
> From: David Woodhouse
>
> [ Upstream commit 3d7746bea92530e8695258a3cf3ddec7a135edd6 ]
Sasha, you will also want
https://lore.kernel.org/lkml/20210115191123.27572-1-rdun...@infradead.org/, it
is sitting in Xen staging tree.
-boris
On 1/18/21 11:21 AM, Andrew Cooper wrote:
On 18/01/2021 15:31, Jan Beulich wrote:
On 18.01.2021 16:06, Andrew Cooper wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -147,6 +147,14 @@ static bool virq_is_global(unsigned int virq)
return true;
}
+static void
flight 158531 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158531/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6e5586863148773c15399ead249711143a74d2d0
baseline version:
ovmf 83facfd184021874f95a6
flight 158529 qemu-mainline real [real]
flight 158534 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158529/
http://logs.test-lab.xenproject.org/osstest/logs/158534/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 158530 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken in 158507
test-amd64-i386-qemuu-rhel6hvm-
91 matches
Mail list logo
