flight 159832 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159832/
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
flight 159828 qemu-mainline real [real]
flight 159833 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159828/
http://logs.test-lab.xenproject.org/osstest/logs/159833/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 04/03/2021 14:47, Roger Pau Monne wrote:
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
> Xen result in the injection of a #GP to the
On 04/03/2021 23:09, Boris Ostrovsky wrote:
> On 3/4/21 9:47 AM, Roger Pau Monne wrote:
>> Introduce an option to allow selecting a less strict behaviour for
>> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
>> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled
On 3/4/21 9:47 AM, Roger Pau Monne wrote:
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
> Xen result in the injection of a #GP to the
flight 159826 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159826/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 159702
test-amd64-i386-xl-qemut-win7-amd64 19
On Wed, Mar 3, 2021 at 12:37 PM Alex Bennée wrote:
>
> Hypervisors, especially type-1 ones, need the firmware/bootcode to put
> their initial guest somewhere in memory and pass the information to it
> via platform data. The guest-loader is modelled after the generic
> loader for exactly this sort
On 04/03/2021 13:03, Andrew Cooper wrote:
> This is inappropriate for the header file of a standalone library with stable
> API and ABI.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Ian Jackson
> CC: Wei Liu
>
> Discovered when trying to actually remove the use of unstable libraries from a
>
flight 159825 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159825/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeat fail in 159820 pass in
159825
The pull request you sent on Thu, 4 Mar 2021 12:00:53 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.12b-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c5a58f877ca645a3303f7a57476f2de837fdb97a
Thank you!
--
Deet-doot-dot,
flight 159829 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159829/
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
Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
for HVM relaxed rdmsr behavior"):
> One option we could go for is making this behavior depend on Kconfig:
> enable strict MSR policy for debug builds and fallback to the
> 'relaxed' one for non-debug builds. That might
On Thu, Mar 04, 2021 at 05:13:15PM +, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
> for HVM relaxed rdmsr behavior"):
> > On Thu, Mar 04, 2021 at 03:20:34PM +, Ian Jackson wrote:
> > > The guest could be stopped with xl shutdown and
Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
for HVM relaxed rdmsr behavior"):
> On Thu, Mar 04, 2021 at 03:20:34PM +, Ian Jackson wrote:
> > The guest could be stopped with xl shutdown and then recrated with xl
> > create, from the config file. I don't think
On Thu, Mar 04, 2021 at 03:20:34PM +, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
> for HVM relaxed rdmsr behavior"):
> > On Thu, Mar 04, 2021 at 02:59:38PM +, Ian Jackson wrote:
> > > I think it's almost as bad to have guests which
flight 159823 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
Roger Pau Monné writes ("Re: [PATCH v2 for-4.15] x86/msr: introduce an option
for HVM relaxed rdmsr behavior"):
> On Thu, Mar 04, 2021 at 02:59:38PM +, Ian Jackson wrote:
> > I think it's almost as bad to have guests which can be migrated in,
> > but which then cannot reboot.
>
> Ups, yes,
On Thu, Mar 04, 2021 at 02:59:38PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 for-4.15] x86/msr: introduce an option for
> HVM relaxed rdmsr behavior"):
> > Introduce an option to allow selecting a less strict behaviour for
> > rdmsr accesses targeting a MSR not explicitly
Norbert Manthey writes ("Re: [PATCH XENSTORE v1 09/10] xs: handle daemon socket
error"):
> On 3/3/21 5:13 PM, Ian Jackson wrote:
> > Norbert Manthey writes ("[PATCH XENSTORE v1 09/10] xs: handle daemon socket
> > error"):
> >> When starting the daemon, we might see a NULL pointer instead of the
Roger Pau Monne writes ("[PATCH v2 for-4.15] x86/msr: introduce an option for
HVM relaxed rdmsr behavior"):
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not
On 3/3/21 5:13 PM, Ian Jackson wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> Norbert Manthey writes ("[PATCH XENSTORE v1 09/10] xs: handle daemon socket
Introduce an option to allow selecting a less strict behaviour for
rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
Xen result in the injection of a #GP to the guest. This is a behavior
change since previously a
On 04/03/2021 14:02, Andrew Cooper wrote:
> On 01/03/2021 19:33, Boris Ostrovsky wrote:
>> On 3/1/21 11:23 AM, Roger Pau Monne wrote:
>>> Introduce an option to allow selecting the legacy behavior for
>>> accesses to MSRs not explicitly handled. Since commit
>>> 84e848fd7a162f669 and
Andrew Cooper writes ("[PATCH for-4.15] tools/libxendevicemodel: Strip
__XEN_TOOLS__ header guard"):
> This is inappropriate for the header file of a standalone library with stable
> API and ABI.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Ian Jackson
On 01/03/2021 19:33, Boris Ostrovsky wrote:
> On 3/1/21 11:23 AM, Roger Pau Monne wrote:
>> Introduce an option to allow selecting the legacy behavior for
>> accesses to MSRs not explicitly handled. Since commit
>> 84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
>> handled by
flight 159822 qemu-mainline real [real]
flight 159827 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159822/
http://logs.test-lab.xenproject.org/osstest/logs/159827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
Andrew Cooper writes ("[PATCH for-4.15] tools/libxendevicemodel: Strip
__XEN_TOOLS__ header guard"):
> This is inappropriate for the header file of a standalone library with stable
> API and ABI.
wat
> Discovered when trying to actually remove the use of unstable libraries from a
> trivial
On 04/03/2021 13:01, Andrew Cooper wrote:
> The const_op boolean needs clobbering to cause data to be written back to the
> caller.
>
> Fixes: c4441ab1f1 ("dmop: Add XEN_DMOP_nr_vcpus")
> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
> Release-Acked-by: Ian Jackson
Apologies - I
This is inappropriate for the header file of a standalone library with stable
API and ABI.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
Discovered when trying to actually remove the use of unstable libraries from a
trivial userspace emulator. Current users of xendevicemodel.h
The const_op boolean needs clobbering to cause data to be written back to the
caller.
Fixes: c4441ab1f1 ("dmop: Add XEN_DMOP_nr_vcpus")
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Release-Acked-by: Ian Jackson
---
xen/arch/arm/dm.c | 1 +
xen/arch/x86/hvm/dm.c | 1 +
2 files
Jan Beulich writes ("[PATCH][4.15] crypto: adjust rijndaelEncrypt() prototype
for gcc11"):
> Clearly neither the 1st nor the 2nd argument have a "source size" of 0.
>
> --- a/xen/include/crypto/rijndael.h
> +++ b/xen/include/crypto/rijndael.h
> @@ -52,7 +52,7 @@
>
> int
On 04.03.2021 13:41, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt()
> prototype for gcc11"):
>> On 04/03/2021 11:21, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt()
>>> prototype for gcc11"):
> ...
>>>
On 04.03.2021 12:21, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt()
> prototype for gcc11"):
>> On 03.03.2021 20:09, Julien Grall wrote:
>>> On 01/03/2021 07:57, Jan Beulich wrote:
The upcoming release complains, not entirely unreasonably:
Julien Grall writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt()
prototype for gcc11"):
> On 04/03/2021 11:21, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt()
> > prototype for gcc11"):
...
> > It has been idiomatic in some codebases for a
Andrew Cooper writes ("[PATCH for-4.15] xen/dmop: Fix XEN_DMOP_nr_vcpus to
actually return data"):
> The const_op boolean needs clobbering to cause data to be written back to the
> caller.
>
> Fixes: c4441ab1f1 ("dmop: Add XEN_DMOP_nr_vcpus")
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan
On 04/03/2021 11:21, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt() prototype
for gcc11"):
On 03.03.2021 20:09, Julien Grall wrote:
On 01/03/2021 07:57, Jan Beulich wrote:
The upcoming release complains, not entirely unreasonably:
In file
On 04/03/2021 08:06, Jan Beulich wrote:
On 03.03.2021 20:09, Julien Grall wrote:
On 01/03/2021 07:57, Jan Beulich wrote:
The upcoming release complains, not entirely unreasonably:
In file included from rijndael.c:33:
.../xen/include/crypto/rijndael.h:55:53: note: previously declared as
Jan Beulich writes ("Re: [PATCH RFC for-4.15] x86/msr: introduce an option for
legacy MSR behavior selection"):
> On 04.03.2021 11:05, Roger Pau Monné wrote:
...
> > This one seems like a fine candidate to implement in
> > svm_msr_read_intercept, because Xen needs to return a specific value
> >
Jan Beulich writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt()
prototype for gcc11"):
> On 03.03.2021 20:09, Julien Grall wrote:
> > On 01/03/2021 07:57, Jan Beulich wrote:
> >> The upcoming release complains, not entirely unreasonably:
> >>
> >> In file included from rijndael.c:33:
> >>
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.12b-rc2-tag
xen: branch for v5.12-rc2
It contains fixes for 2 security issues (XSA-367 and XSA-369).
Thanks.
Juergen
arch/arm/xen/p2m.c| 35
On 04.03.2021 11:05, Roger Pau Monné wrote:
> On Thu, Mar 04, 2021 at 09:48:25AM +0100, Jan Beulich wrote:
>> On 03.03.2021 16:38, Roger Pau Monné wrote:
>>> It also raises the question whether we will allow any more exceptions
>>> to the MSR policy, like we did for Windows and OpenBSD in:
>>>
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-369
Linux: special config may crash when trying to map foreign pages
ISSUE DESCRIPTION
=
With CONFIG_XEN_BALLOON_MEMORY_HOTPLUG disabled and
CONFIG_XEN_UNPOPULATED_ALLOC enabled the
On Thu, Mar 04, 2021 at 10:48:05AM +, Andrew Cooper wrote:
> The const_op boolean needs clobbering to cause data to be written back to the
> caller.
>
> Fixes: c4441ab1f1 ("dmop: Add XEN_DMOP_nr_vcpus")
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Thanks, Roger.
The const_op boolean needs clobbering to cause data to be written back to the
caller.
Fixes: c4441ab1f1 ("dmop: Add XEN_DMOP_nr_vcpus")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Ian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-367
Linux: netback fails to honor grant mapping errors
ISSUE DESCRIPTION
=
XSA-362 tried to address issues here, but in the case of the netback
driver the changes were
Hi Jan,
On 04/03/2021 08:34, Jan Beulich wrote:
On 03.03.2021 20:36, Julien Grall wrote:
(BCCing xen-users, CCing xen-devel + a few folks)
How about the following (untested):
commit e1cd2d85234c8d0aa62ad32c824a5568a57be930 (HEAD -> dev)
Author: Julien Grall
Date: Wed Mar 3 19:27:56 2021
Hi Juergen,
On 04/03/2021 09:48, Jürgen Groß wrote:
On 04.03.21 10:39, Julien Grall wrote:
On 04/03/2021 09:00, Jürgen Groß wrote:
On 03.03.21 18:05, Julien Grall wrote:
From: Julien Grall
As XenStored is single-threaded, conn->ta_start_time will always be
smaller than now. As we
On Thu, Mar 04, 2021 at 09:48:25AM +0100, Jan Beulich wrote:
> On 03.03.2021 16:38, Roger Pau Monné wrote:
> > On Tue, Mar 02, 2021 at 04:18:59PM +0100, Jan Beulich wrote:
> >> On 02.03.2021 16:00, Roger Pau Monné wrote:
> >>> On Tue, Mar 02, 2021 at 12:16:12PM +0100, Jan Beulich wrote:
> On
On 04.03.21 10:39, Julien Grall wrote:
On 04/03/2021 09:00, Jürgen Groß wrote:
On 03.03.21 18:05, Julien Grall wrote:
From: Julien Grall
As XenStored is single-threaded, conn->ta_start_time will always be
smaller than now. As we substract the latter from the former, it means
a transaction
On 04/03/2021 09:00, Jürgen Groß wrote:
On 03.03.21 18:05, Julien Grall wrote:
From: Julien Grall
As XenStored is single-threaded, conn->ta_start_time will always be
smaller than now. As we substract the latter from the former, it means
a transaction will never be considered long running.
On 03.03.21 18:05, Julien Grall wrote:
From: Julien Grall
As XenStored is single-threaded, conn->ta_start_time will always be
smaller than now. As we substract the latter from the former, it means
a transaction will never be considered long running.
Invert the two operands of the substraction
On 03.03.2021 16:38, Roger Pau Monné wrote:
> On Tue, Mar 02, 2021 at 04:18:59PM +0100, Jan Beulich wrote:
>> On 02.03.2021 16:00, Roger Pau Monné wrote:
>>> On Tue, Mar 02, 2021 at 12:16:12PM +0100, Jan Beulich wrote:
On 01.03.2021 17:23, Roger Pau Monne wrote:
> RFC because there's
flight 159820 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159820/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 159814
Tests which did not
On 03.03.2021 20:36, Julien Grall wrote:
> (BCCing xen-users, CCing xen-devel + a few folks)
>
> Hi,
>
> Moving the discussion to xen-devel.
>
> On 22/02/2021 05:02, Charles Chiou wrote:
>> When trying to boot two zImage using dom0less boot on ARM, we encountered
>> this problem when xen runs
On 03.03.2021 20:09, Julien Grall wrote:
> On 01/03/2021 07:57, Jan Beulich wrote:
>> The upcoming release complains, not entirely unreasonably:
>>
>> In file included from rijndael.c:33:
>> .../xen/include/crypto/rijndael.h:55:53: note: previously declared as 'const
>> unsigned char[]'
>> 55
55 matches
Mail list logo
