On 16.12.20 15:08, Jason Andryuk wrote:
commit bfda93aee0ec ("xen: Kconfig: nest Xen guest options")
accidentally re-added X86_64 as a dependency to XEN_512GB. It was
originally removed in commit a13f2ef168cb ("x86/xen: remove 32-bit Xen
PV guest support"). Remove it again.
Fixes: bfda93aee0ec
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.11-rc1b-tag
xen: branch for v5.11-rc1
It contains some minor cleanup patches and a small series disentangling some Xen
related Kconfig options.
Thanks.
Juergen
arch/x86/include/
flight 157664 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157664/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs.
157135
Tests which
flight 157659 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157659/
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
test-amd64-i386-xl-
The description "physical CPUs" is especially wrong, as it implies the number
of sockets, which tops out at 8 on all but the very biggest servers.
NR_CPUS is the number of logical entities the scheduler can use.
Reported-by: hanet...@startmail.com
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
flight 157655 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157655/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 157617
test-amd64-amd64-xl-qemuu-ws16-amd64
On 12/18/20 11:25 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> 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, in the xs_reset_watches() call
> called fro
flight 157696 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157696/
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 157662 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
Phillip Susi writes:
> I tried with -s and it didn't help. So far I tried it originally on my
> Ubuntu 20.04 amazon vps, then on my debian testing ( linux 5.9.0 ) on my
> local xen server. I'll try building the latest upstream kernel and
> kexec tomorrow.
Built the latest kexec-tools and linu
While working on a reproducible build of xen in Debian I came up with
the following three patches which are needed to build xen reproducibly
in Debian. Reproducible builds are useful to verify the binary has
actually been built from the corresponding source.
The first patch is an extension of [1]
Use the solution described in [1] to replace the call to the 'date'
command with a version that uses SOURCE_DATE_EPOCH if available. This
is needed for reproducible builds.
[1] https://reproducible-builds.org/docs/source-date-epoch/
Signed-off-by: Maximilian Engelhardt
---
docs/Makefile | 8 +++
By default a timestamp gets added to the xen efi binary. Unfortunately
ld doesn't seem to provide a way to set a custom date, like from
SOURCE_DATE_EPOCH, so set a zero value for the timestamp (option
--no-insert-timestamp) if SOURCE_DATE_EPOCH is defined. This makes
reproducible builds possible.
When the seq number is equal, sort by the title to get predictable
output ordering. This is useful for reproducible builds.
Signed-off-by: Maximilian Engelhardt
---
docs/xen-headers | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/xen-headers b/docs/xen-headers
index 5415
On 12/17/20 12:49 PM, boris.ostrov...@oracle.com wrote:
> On 12/17/20 11:46 AM, Andrew Cooper wrote:
>> On 17/12/2020 16:25, boris.ostrov...@oracle.com wrote:
>>> On 12/17/20 2:40 AM, Jan Beulich wrote:
On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote:
I think this is acceptable as
On Fri, 18 Dec 2020, Julien Grall wrote:
> From: Julien Grall
>
> So far, our implementation of WARN_ON() cannot be used in the following
> situation:
>
> if ( WARN_ON() )
> ...
>
> This is because WARN_ON() doesn't return whether a warning has been
> triggered. Such construciton can be han
flight 157679 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 157656
Tests which
From: David Woodhouse
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, in the xs_reset_watches() call
called from xs_init().
This mostly doesn't matter much in practice
flight 157661 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157661/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
flight 157668 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 157656
Tests which
flight 157650 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 157564
build-armhf-pv
On 18/12/2020 08:27, Jan Beulich wrote:
> On 17.12.2020 22:46, Andrew Cooper wrote:
>> On 29/09/2020 07:18, Jan Beulich wrote:
>>> On 28.09.2020 17:47, Andrew Cooper wrote:
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -563,30 +563,37 @@ void hap_final_teardown(s
flight 157644 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
test-amd64-i386-
Hi Juergen,
On 15/12/2020 10:20, Jürgen Groß wrote:
On 15.12.20 08:27, Jürgen Groß wrote:
On 14.12.20 22:25, Julien Grall wrote:
Hi Juergen,
When testing Linux 5.10 dom0, I could reliably hit the following
warning with using event 2L ABI:
[ 589.591737] Interrupt for port 34, but apparentl
From: Julien Grall
So far, our implementation of WARN_ON() cannot be used in the following
situation:
if ( WARN_ON() )
...
This is because WARN_ON() doesn't return whether a warning has been
triggered. Such construciton can be handy if you want to print more
information and also dump the st
On 18.12.20 10:09, Jan Beulich wrote:
On 18.12.2020 09:57, Jürgen Groß wrote:
On 17.12.20 13:14, Jan Beulich wrote:
On 17.12.2020 12:32, Jürgen Groß wrote:
On 17.12.20 12:28, Jan Beulich wrote:
On 09.12.2020 17:09, Juergen Gross wrote:
+static const struct hypfs_entry *hypfs_dyndir_enter(
+
Having pondered note (1) in my previous email a bit more, I imagine the reason
for using a DMB instead of acq/rel semantics is to prevent accesses following
the STLXR from being reordered between it and the LDAXR.
I won't be winning any awards for this ASCII art but hopefully it helps convey
the p
Hi Stefano,
> On 17 Dec 2020, at 23:17, Stefano Stabellini wrote:
>
> On Thu, 17 Dec 2020, Bertrand Marquis wrote:
>> Modify identify_cpu function to use READ_SYSREG instead of READ_SYSREG32
>> or READ_SYSREG64.
>> The aarch32 versions of the registers are 64bit on an aarch64 processor
>> so it
Hi Stefano,
> On 17 Dec 2020, at 23:37, Stefano Stabellini wrote:
>
> On Thu, 17 Dec 2020, Bertrand Marquis wrote:
>> Add support for emulation of cp15 based ID registers (on arm32 or when
>> running a 32bit guest on arm64).
>> The handlers are returning the values stored in the guest_cpuinfo
>>
Hi Stefano,
> On 17 Dec 2020, at 23:47, Stefano Stabellini wrote:
>
> On Thu, 17 Dec 2020, Bertrand Marquis wrote:
>> The goal of this serie is to emulate coprocessor ID registers so that
>> Xen only publish to guest features that are supported by Xen and can
>> actually be used by guests.
>> On
flight 157638 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157431
Tests which are fail
Hi Jan,
On 18/12/2020 08:02, Jan Beulich wrote:
On 23.11.2020 16:21, Jan Beulich wrote:
In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
just to avoid bloating binaries when only some arch-es and/or
configurations need generic library routines, combine objects under lib/
i
On 18.12.2020 09:57, Jürgen Groß wrote:
> On 17.12.20 13:14, Jan Beulich wrote:
>> On 17.12.2020 12:32, Jürgen Groß wrote:
>>> On 17.12.20 12:28, Jan Beulich wrote:
On 09.12.2020 17:09, Juergen Gross wrote:
> +static const struct hypfs_entry *hypfs_dyndir_enter(
> +const struct hyp
On 17.12.2020 20:54, Andrew Cooper wrote:
> On 15/12/2020 16:26, Jan Beulich wrote:
>> Extend a respective #ifdef from inside set_typed_p2m_entry() to around
>> all three functions. Add ASSERT_UNREACHABLE() to the latter one's safety
>> check path.
>>
>> Signed-off-by: Jan Beulich
>
> As the code
On 17.12.20 13:14, Jan Beulich wrote:
On 17.12.2020 12:32, Jürgen Groß wrote:
On 17.12.20 12:28, Jan Beulich wrote:
On 09.12.2020 17:09, Juergen Gross wrote:
+static const struct hypfs_entry *hypfs_dyndir_enter(
+const struct hypfs_entry *entry)
+{
+const struct hypfs_dyndir_id *data;
On 17.12.2020 20:18, Andrew Cooper wrote:
> On 15/12/2020 16:26, Jan Beulich wrote:
>> This is together with its only caller, xenmem_add_to_physmap_one().
>
> I can't parse this sentence. Perhaps "... as is it's only caller," as a
> follow-on from the subject sentence.
Yeah, changed along these
On 17.12.2020 20:03, Andrew Cooper wrote:
> On 15/12/2020 16:25, Jan Beulich wrote:
>> Drop a bogus ASSERT() - we don't typically assert incoming domain
>> pointers to be non-NULL, and there's no particular reason to do so here.
>>
>> Replace the open-coded DOMID_SELF check by use of
>> rcu_lock_re
On 18.12.2020 09:19, Jürgen Groß wrote:
> On 18.12.20 08:54, Jan Beulich wrote:
>> On 18.12.2020 00:54, Stefano Stabellini wrote:
>>> On Tue, 15 Dec 2020, Jan Beulich wrote:
On 15.12.2020 14:19, Julien Grall wrote:
> On 15/12/2020 11:46, Jan Beulich wrote:
>> On 15.12.2020 12:26, Julie
On 17.12.2020 22:46, Andrew Cooper wrote:
> On 29/09/2020 07:18, Jan Beulich wrote:
>> On 28.09.2020 17:47, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -563,30 +563,37 @@ void hap_final_teardown(struct domain *d)
>>> paging_unlock(d);
>>>
On 18.12.20 08:54, Jan Beulich wrote:
On 18.12.2020 00:54, Stefano Stabellini wrote:
On Tue, 15 Dec 2020, Jan Beulich wrote:
On 15.12.2020 14:19, Julien Grall wrote:
On 15/12/2020 11:46, Jan Beulich wrote:
On 15.12.2020 12:26, Julien Grall wrote:
--- a/xen/include/xen/lib.h
+++ b/xen/include
On 23.11.2020 16:21, Jan Beulich wrote:
> In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
> just to avoid bloating binaries when only some arch-es and/or
> configurations need generic library routines, combine objects under lib/
> into an archive, which the linker then can pi
41 matches
Mail list logo
