Chuck Zmudzinski
2021-Sep-22 19:50 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Package: xen-hypervisor-4.14-amd64 Version: 4.14.3-1~deb11u1 Severity: important Tags: patch newcomer upstream Dear Maintainer, This bug is related to #991976, reported by Elliott Mitchell, who happens to be the person who requested the patches that are causing this bug. I understand he is a Debian Xen developer. Since I am not a developer, I only tagged this bug important, but if I were a developer, I would tag it serious and implement a fix that does what I will propose below. I hereby humbly request that you elevate this bug to serious, since it is entirely wrong to release software that causes a modern workstation/server to not power down properly and renders it unable to be managed remotely, which is what this bug does. A bug like this is normal on an unstable or testing distribution, but unacceptable/serious on the current stable release. I refer you here for my first description of the problem to the Debian Bug System: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#34 I also point out that another Debian user confirmed the bug on bullseye: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#54 Elliott is of the opinion that what I am seeing is a bug distinct from #991976. I am inclined to agree, as I have not been able to reproduce it the way he describes it, although the symptoms he sees are very similar. That is why I am submitting a new report. I can drill down the cause of this bug in the stable version of debian to the Debian Xen Team's decision to include a series of nine commits from upstream in order to improve Raspberry Pi 4 support in version 4.14.0+88-g1d1d1f5391-1. So the bug was introduced in the Debian Xen unstable/testing package on 15 Dec 2020 according to the changelog. I understand the original reporter of #991976 wants to keep these patches in the stable version of Xen to better support the Raspberry Pi 4, and that he is a Debian Xen developer. But I will strenuously and respectfully disagree with any decision by the Debian Xen Team to not apply a very reasonable compromise solution. Over on #991967, I argued passionately for removing the nine Raspberry Pi 4 patches from the stable Xen version because, and it is still my opinion that experiments with patches from unstable upstream branches is not appropriate for a package in a stable version. That is why I would expect the release team to tag this bug as serious even if the Debian Xen Team refuses to tag it as serious. Nevertheless, I propose the following compromise: Simply ship a package for the stable version that omits the nine Raspberry Pi 4 patches from unstable upstream while building for the amd64|i386 architectures. I was able to implement such a fix even though I am not an official developer in just a few hours. It is really a trivial fix, all I did was add a rule in debian/rules to use quilt to disable the nine patches on amd64|i386. I made it easy by moving the nine RP4 patches from debian/patches to debian/patches/rpi4 and so could I use sed s/rpi4/#rpi4/ debian/series to disable the patches for the amd64|i386 case. I am sure there are other ways to implement the fix, and it really is trivial, it would fix this bug and still allow for the Raspberry Pi 4 patches to be included where they are needed which I believe is in the arm64 architecture. I also tested the current unstable branch from Xen upstream, which is xen-c76cfad, which unstable calls Xen-4.16-unstable. I tested the current bullseye kernel as a dom0 on that upstream Xen-4.16 hypervisor and did not see the bug, so this most definetely is NOT an upstream bug. It is a Debian Xen packaging bug. I expect that perhaps some commits on the Xen-4.16 upstream branch that are missing on the Xen-4.14 branch might also fix this bug, but until such a solution is found, I suggest the aforementioned solution as a workaround. The reason I tagged this bug as upstream is that I think it would be adviseable to make upstream aware that our current xen-4.14 package is not really a true Xen-4.14 but one with some patches from Xen-unstable that are causing this bug, and perhaps they can help eventually find the best solution for their Xen-4.14 stable branch. Finally, I tag the bug newcomer simply because there is a known solution but the Debian Xen package maintainer seems to want the Debian Kernel Team to find a way to fix the bug in the Linux kernel, as evidenced by the recent discussion over at #991976, instead of implementing the fix in the Xen hypervisor as proposed here. Regards, Chuck Zmudzinski *** Reporter, please consider answering these questions, where appropriate *** ?? * What led up to the situation? ?? * What exactly did you do (or not do) that was effective (or ???? ineffective)? ?? * What was the outcome of this action? ?? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.0 ? APT prefers stable-updates ? APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8.1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled xen-hypervisor-4.14-amd64 depends on no packages. Versions of packages xen-hypervisor-4.14-amd64 recommends: pn? xen-hypervisor-common? <none> pn? xen-utils-4.14???????? <none> xen-hypervisor-4.14-amd64 suggests no packages.
Diederik de Haas
2021-Sep-23 16:49 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Control: tag -1 -newcomer Control: tag -1 -upstream On woensdag 22 september 2021 21:50:16 CEST Chuck Zmudzinski wrote:> Finally, I tag the bug newcomer simply because there is a known solution butThat's what the 'patch' tag is for. 'newcomer' is similar to 'good first issue', which this is not. Hence removing the 'newcomer' tag.> the Debian Xen package maintainer seems to want the Debian Kernel Team to > find a way to fix the bug in the Linux kernel, as evidenced by the recent > discussion over at #991976, instead of implementing the fix in the Xen > hypervisor as proposed here.You're claiming, possibly correctly, that the issue is with the Debian Xen package, not with the upstream code, so removing the 'upstream' tag as well. It's good that you filed this bug against the Debian Xen package because it's (quite) possible that there is both an issue with the Linux kernel which #991976 is about and with the Xen package, what this issue will be about. They way you went about it ... not so good. By filing a bug you want others to spend their free time to (help) fix an issue you are having (and in this case, me too). To make the best use of their time and your chances of it being fixed, you should state the problem as short and succinct as possible. And in the case of a 'patch' as may be the case here, the actual patch. You did neither. You did go on a rant where you made (incorrect) claims and accusations. I don't think that helps your goal, which is getting this issue fixed. Do you? F.e. you make claims on the Debian Xen package maintainers' position, while this is the first time they've been made (explicitly) aware of this issue. So they did not have a chance to (formulate and) state their position. I had written a point-by-point description of what *I* think was wrong with your bug report, but that would only keep the negative cycle in place. FTR: I'm just a contributor to Debian (by participating in this bug), just like you are (by submitting a bug). And so is Elliot. For uploading packages to the Debian archive you *do* need special permissions. For almost all other things, everyone can contribute.> Package: xen-hypervisor-4.14-amd64 > Version: 4.14.3-1~deb11u1 > Severity: important > Since I am not a developer, I only tagged this bug important, but if I were > a developer, I would tag it serious and implement a fix that does what I will > propose below.https://www.debian.org/Bugs/Developer#severities explains what the severity levels entail. There is no correlation between severity and some (claimed) role within the project. IMO this bug is *at most* important. Let's leave it to the Debian Xen package maintainers to change the severity if they think that's appropriate.> I refer you here for my first description of the problem > to the Debian Bug System: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#34IMO, this is just wrong. You've filed a new bug so make the exact problem the primary part of this bug. Don't ask of others to read a '50 page document' and expect them to distill YOUR problem themselves. Doing a copy+paste of the *relevant* part is absolutely fine. So please reply to this with the following (minimal) info: - Your hardware - Whether you use BIOS or UEFI - Your init system - What you did and what the result of that was. Item 2 & 3 may seem 'odd' at first, but should become clear later on.> another Debian user confirmed the bug on bullseye:Yep. If I do 'poweroff' on my Xen server, it looks like it does the whole shutdown procedure correctly, but it doesn't actually poweroff the machine.> I can drill down the cause of this bug in the stable version of debian to > a series of nine commits from upstream in order to improve Raspberry Pi 4 > support in version 4.14.0+88-g1d1d1f5391-1.Do those 9 commits correspond to 9 patches from the <debian-xen-repo>/debian/patches/ directory? If so, which 9? If you add the 'patch' tag, do indeed include the patch in the bug report. I built Xen packages based on 4.14.3-1~deb11u1 but remove patches 0029-0034, but after installing those packages and rebooting into my patched version, my Xen server still did NOT power off. Other patches didn't seem relevant *to me*, but I can be wrong. If you share your changes, I can try whether that will fix the problem with me (too). My Xen server uses BIOS (not UEFI, which I think you do) and has sysv-init as init system. That may be relevant as well.> So the bug was introduced in the Debian Xen unstable/testing package on > 15 Dec 2020 according to the changelog.You *think* that was the case? Or did your Bullseye system actually poweroff correctly when installing version 4.14.0+80-gd101b417b7-1 or earlier? That was the version before the RPi4 related patches were added. Version N-1=good, version N=bad is very useful and relevant info.> I also tested the current unstable branch from Xen upstream, which is > xen-c76cfad, which unstable calls Xen-4.16-unstable. I tested the current > bullseye kernel as a dom0 on that upstream Xen-4.16 hypervisor and did not > see the bug, so this most definetely is NOT an upstream bug.Can you do a test with the upstream Xen-4.14 code? It *can* actually be an upstream bug present in the 4.14 code which has been fixed in the Xen-4.16-unstable 'branch'. If you compare the following 2 branches, there are quite some differences: https://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/acpi;hb=refs/heads/stable-4.14 https://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/acpi;hb=HEAD And that's only for the 'xen/arch/x86/acpi/' folder.> I think it would be adviseable to make upstream aware that our > current xen-4.14 package is not really a true Xen-4.14The whole existence of the [debian/]patches directory makes it not identical to upstream's code. I'm quite sure upstream Xen is already aware of that, but it's also none of their concern/business. As said earlier, the 'upstream' tag is entirely incorrect. While I *personally* do agree that grabbing 'random' upstream patches should not be done or with extreme caution (in the case of Xen), that decision is actually up to the maintainers of the Debian package(s). In this case Elliot made a *suggestion* and until now, no one had reported a problem with it, so there was no reason to *assume* it was harmful. Evidence and proof are much better arguments then (vague) speculation. I'm quite certain you're very capable of the former, so let's see more of that.> xen-hypervisor-4.14-amd64 depends on no packages. > > Versions of packages xen-hypervisor-4.14-amd64 recommends: > pn xen-hypervisor-common <none> > pn xen-utils-4.14 <none>You seem to NOT have installed Recommended packages, which is generally a bad thing. In case of xen-hypervisor-common possibly harmful and relevant. Cheers, Diederik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20210923/ac8fee27/attachment.sig>
Debian Bug Tracking System
2021-Sep-23 16:51 UTC
[Pkg-xen-devel] Processed: Re: Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Processing control commands:> tag -1 -newcomerBug #994899 [xen-hypervisor-4.14-amd64] xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye Removed tag(s) newcomer.> tag -1 -upstreamBug #994899 [xen-hypervisor-4.14-amd64] xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye Removed tag(s) upstream. -- 994899: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 Debian Bug Tracking System Contact owner at bugs.debian.org with problems
Chuck Zmudzinski
2021-Sep-23 19:54 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
On 9/23/2021 12:49 PM, Diederik de Haas wrote:> Control: tag -1 -newcomer > Control: tag -1 -upstream > > On woensdag 22 september 2021 21:50:16 CEST Chuck Zmudzinski wrote: >> Finally, I tag the bug newcomer simply because there is a known solution but > That's what the 'patch' tag is for. 'newcomer' is similar to 'good first issue', > which this is not. Hence removing the 'newcomer' tag. > >> the Debian Xen package maintainer seems to want the Debian Kernel Team to >> find a way to fix the bug in the Linux kernel, as evidenced by the recent >> discussion over at #991976, instead of implementing the fix in the Xen >> hypervisor as proposed here. > You're claiming, possibly correctly, that the issue is with the Debian Xen > package, not with the upstream code, so removing the 'upstream' tag as well. > > > It's good that you filed this bug against the Debian Xen package because it's > (quite) possible that there is both an issue with the Linux kernel which > #991976 is about and with the Xen package, what this issue will be about. > > They way you went about it ... not so good. > > By filing a bug you want others to spend their free time to (help) fix an issue > you are having (and in this case, me too). To make the best use of their time > and your chances of it being fixed, you should state the problem as short and > succinct as possible. > And in the case of a 'patch' as may be the case here, the actual patch. > > You did neither. > > You did go on a rant where you made (incorrect) claims and accusations. > I don't think that helps your goal, which is getting this issue fixed. Do you? > > F.e. you make claims on the Debian Xen package maintainers' position, while > this is the first time they've been made (explicitly) aware of this issue. > So they did not have a chance to (formulate and) state their position. > > I had written a point-by-point description of what *I* think was wrong with > your bug report, but that would only keep the negative cycle in place. > FTR: I'm just a contributor to Debian (by participating in this bug), just > like you are (by submitting a bug). And so is Elliot. > > For uploading packages to the Debian archive you *do* need special > permissions. For almost all other things, everyone can contribute. > >> Package: xen-hypervisor-4.14-amd64 >> Version: 4.14.3-1~deb11u1 >> Severity: important >> Since I am not a developer, I only tagged this bug important, but if I were >> a developer, I would tag it serious and implement a fix that does what I will >> propose below. > https://www.debian.org/Bugs/Developer#severities explains what the severity > levels entail. There is no correlation between severity and some (claimed) role > within the project. IMO this bug is *at most* important. > Let's leave it to the Debian Xen package maintainers to change the severity > if they think that's appropriate. > >> I refer you here for my first description of the problem >> to the Debian Bug System: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#34 > IMO, this is just wrong. > You've filed a new bug so make the exact problem the primary part of this bug. > Don't ask of others to read a '50 page document' and expect them to distill > YOUR problem themselves. > Doing a copy+paste of the *relevant* part is absolutely fine. > > So please reply to this with the following (minimal) info: > - Your hardware > - Whether you use BIOS or UEFI > - Your init system > - What you did and what the result of that was. > > Item 2 & 3 may seem 'odd' at first, but should become clear later on. > >> another Debian user confirmed the bug on bullseye: > Yep. If I do 'poweroff' on my Xen server, it looks like it does the whole > shutdown procedure correctly, but it doesn't actually poweroff the machine. > >> I can drill down the cause of this bug in the stable version of debian to >> a series of nine commits from upstream in order to improve Raspberry Pi 4 >> support in version 4.14.0+88-g1d1d1f5391-1. > Do those 9 commits correspond to 9 patches from the > <debian-xen-repo>/debian/patches/ directory? If so, which 9? > If you add the 'patch' tag, do indeed include the patch in the bug report. > > I built Xen packages based on 4.14.3-1~deb11u1 but remove patches 0029-0034, > but after installing those packages and rebooting into my patched version, my > Xen server still did NOT power off. Other patches didn't seem relevant *to me*, > but I can be wrong. If you share your changes, I can try whether that will fix > the problem with me (too). > My Xen server uses BIOS (not UEFI, which I think you do) and has sysv-init > as init system. That may be relevant as well. > >> So the bug was introduced in the Debian Xen unstable/testing package on >> 15 Dec 2020 according to the changelog. > You *think* that was the case? Or did your Bullseye system actually poweroff > correctly when installing version 4.14.0+80-gd101b417b7-1 or earlier? > That was the version before the RPi4 related patches were added. > Version N-1=good, version N=bad is very useful and relevant info. > >> I also tested the current unstable branch from Xen upstream, which is >> xen-c76cfad, which unstable calls Xen-4.16-unstable. I tested the current >> bullseye kernel as a dom0 on that upstream Xen-4.16 hypervisor and did not >> see the bug, so this most definetely is NOT an upstream bug. > Can you do a test with the upstream Xen-4.14 code? > It *can* actually be an upstream bug present in the 4.14 code which has been > fixed in the Xen-4.16-unstable 'branch'. > > If you compare the following 2 branches, there are quite some differences: > https://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/acpi;hb=refs/heads/stable-4.14 > https://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/acpi;hb=HEAD > And that's only for the 'xen/arch/x86/acpi/' folder. > >> I think it would be adviseable to make upstream aware that our >> current xen-4.14 package is not really a true Xen-4.14 > The whole existence of the [debian/]patches directory makes it not identical > to upstream's code. I'm quite sure upstream Xen is already aware of that, > but it's also none of their concern/business. > As said earlier, the 'upstream' tag is entirely incorrect. > > While I *personally* do agree that grabbing 'random' upstream patches should > not be done or with extreme caution (in the case of Xen), that decision is > actually up to the maintainers of the Debian package(s). > > In this case Elliot made a *suggestion* and until now, no one had reported > a problem with it, so there was no reason to *assume* it was harmful. > > Evidence and proof are much better arguments then (vague) speculation. > I'm quite certain you're very capable of the former, so let's see more of that. > >> xen-hypervisor-4.14-amd64 depends on no packages. >> >> Versions of packages xen-hypervisor-4.14-amd64 recommends: >> pn xen-hypervisor-common <none> >> pn xen-utils-4.14 <none> > You seem to NOT have installed Recommended packages, which is generally > a bad thing. In case of xen-hypervisor-common possibly harmful and relevant. > > Cheers, > DiederikWow! I am not going to bother defending myself except by stating the author of this message made several false assumptions about me in his attack on my character and good reputation. While I did respond point by point privately to the author, in the interest of avoiding further negativity I am not going to respond further to this message in this public forum. Regards, Chuck Zmudzinski
Diederik de Haas
2021-Sep-23 21:50 UTC
[Pkg-xen-devel] Bug#994899: Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
On donderdag 23 september 2021 21:54:49 CEST Chuck Zmudzinski wrote:> While I did respond point by point privately to the authorDon't do that. Any discussion relevant to the bug should be sent to the bug itself so that everyone has all the relevant information. I actually learned myself how to build Xen packages so I could assist you as good as possible. You won't see any more effort or participation on my part. Bye. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20210923/7c20322a/attachment.sig>
Chuck Zmudzinski
2021-Sep-24 01:18 UTC
[Pkg-xen-devel] Bug#994899: Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
On 9/23/2021 5:50 PM, Diederik de Haas wrote:> On donderdag 23 september 2021 21:54:49 CEST Chuck Zmudzinski wrote: >> While I did respond point by point privately to the author > Don't do that. Any discussion relevant to the bug should be sent to the bug > itself so that everyone has all the relevant information. > > I actually learned myself how to build Xen packages so I could assist you as > good as possible. You won't see any more effort or participation on my part. > > Bye.Sorry to hear that. Cheers, Chuck Zmudzinski
Chuck Zmudzinski
2021-Sep-24 03:05 UTC
[Pkg-xen-devel] Bug#994899: Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Based on the technical information so far provided by the Debian community in this report and in the related bug #991967, I consider this bug closed. For me it is fixed. I found the solution for it on my hardware and shared it with the Debian community. I do not care if the official Debian developers implement my suggestion or not. I will not run Debian's version which is really a mix of Xen-4.14 stable and Xen-4.16 unstable. Instead I will run the version with the patch I suggested in this bug report, and AFAICT I will have a more stable and bug-free version of Xen than anyone who runs the current so-called stable version of Xen for Debian. Since the information about this bug is scattered in various places in the this bug report and in #991967, I will say this bug concerned the following hardware/software configuration: Motherboard/CPU: ASRock B85M Pro4, BIOS P2.50 12/11/2015, with a Haswell CPU (core i5-4590S) Boot system: EFI, not using secure boot, booting xen hypervisor and dom0 bullseye with grub-efi package for bullseye, and it boots the xen-4.14-amd64.gz file, not the xen-4.14-amd64.efi file. Init system: systemd Xen domain type: Domain 0 Linux Kernel Versions: all Linux kernel versions of both buster and bullseye running as a dom0 I tested exhibit the bug, but no Debian stable Linux kernel version since 4.19.0-16 running as a dom0 exhibited the bug with the Xen hypervisor for buster. If you are experiencing the symptoms described in this bug report, the solution I proposed for Debian in both this bug report and in #991976 might fix the bug if your hardware and software configuration is similar to what I have described above. However, to fix it you will have to test it yourself, and that would involve building the Xen package for bullseye from source, unless and until Debian decides to implement the fix I proposed in my original bug report. if you use BIOS boot and/or sysv-init instead of EFI boot and/or systemd, it is likely the fix I have described here will not fix the bug, and also if you have a newer intel cpu or an amd cpu the fix might not work on your hardware, but it might work if you use EFI and systemd in those latter cases. If you try the solution I proposed here and it does not solve your issue, I would suggest that you look at #991976 before reporting a new bug. I will not take action to close this bug; that is up to the Debian developers to decide. Instead, I will select this message to be a summary of the bug. Happy computing on Debian, Chuck Zmudzinski
Chuck Zmudzinski
2021-Sep-24 11:17 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Lowered severity to minor because the information so far indicates the bug may only affect a limited set of hardware/software combinations. It does affect my system, but I have found a solution for it in accord with the Debian principles of free software. I understand the free software development world cannot stop everything it is doing to work on this little bug. Nevertheless, if Debian wishes to try to implement a true and full solution that fixes both this bug and #991976, I am willing to cooperate with anyone who will not accuse me of wrongdoing in this public forum without first discussing the matter with me in a private email. Cheers, Chuck Zmudzinski
Chuck Zmudzinski
2021-Sep-26 13:48 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Added tag upstream. Explanation is in discussion at related bug #991967 here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#169 and here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#174 Briefly, since we are currently? shipping a fork of Xen-4.14 on our unstable, testing, and stable versions of the hypervisor to better support arm devices but there is an annoying bug also in x86 (amd64) in these versions, IMO we should 1) Notify upstream of the fork we are doing and 2) Notify our users, especially on the stable branch, that our version of Xen is actually? a fork of Xen-4.14. I know this can be discovered by reading the changelog, but to find it one must go back to the unstable version that was released back in December of 2020 to find where the fork started. Not many people (including me) would look there to try to find such a significant change to the package, especially on stable where ordinarily only vanilla security patches from upstream are in the changelog. So, as a courtesy to our users, I think the visibility of this change needs to be elevated to the status of at least a README.Debian file, if not an actual notification to the user by dpkg when installing. Of course the changelog should also note explicitly that this is a fork of Xen 4.14 in all the released versions that have patches from Xen upstream 4.16. Perhaps there is a way to also indicate this in the version name and number of the packages, but I do not know if there are conventions or policies to handle a version change that is really the start of a fork. If so, we should follow them.
Patch is attached.
Patch generated by: debdiff xen_4.14.3-1~deb11u1.dsc
xen_4.14.3-1~deb11u1.1.dsc > bug#994899.diff
What it does: Rebuilds the xen packages without the RPI4 patches on
amd64 and i386
Tested on: Native amd64 build
Fixes this bug on my amd64 system
Build Instructions:
Since the .pc directory is changed in the new package, we need quilt to
rebuild it correctly.
So the following commands should work to build the packages. Start in an
empty directory.
if [ ! -e /usr/bin/quilt ]; then sudo apt install quilt; fi
dget -x
https://snapshot.debian.org/archive/debian-security/20210920T191155Z/pool/updates/main/x/xen/xen_4.14.3-1~deb11u1.dsc
cd xen-4.14.3
dpkg-checkbuilddeps
quilt pop -a
cd ..
patch -p0 < bug#994899.diff
cd xen-4.14.3
debuild -i -us -uc -b
To build the source package:
debuild -i -us -uc -S
-------------- next part --------------
diff -Nru xen-4.14.3/debian/changelog xen-4.14.3/debian/changelog
--- xen-4.14.3/debian/changelog 2021-09-13 10:28:21.000000000 -0400
+++ xen-4.14.3/debian/changelog 2021-09-26 22:22:56.000000000 -0400
@@ -1,3 +1,12 @@
+xen (4.14.3-1~deb11u1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches - move RPI4 patches into a separate directory
+ * debian/rules - disable RPI4 patches on amd64|i386 to fix #994899
+ * debian/control - add Build Dependency quilt
+
+ -- Chuck Zmudzinski <brchuckz at netscape.net> Sun, 26 Sep 2021
22:23:21 -0400
+
xen (4.14.3-1~deb11u1) bullseye-security; urgency=medium
* Rebuild for bullseye-security
diff -Nru xen-4.14.3/debian/control xen-4.14.3/debian/control
--- xen-4.14.3/debian/control 2021-07-10 08:01:39.000000000 -0400
+++ xen-4.14.3/debian/control 2021-09-26 22:21:51.000000000 -0400
@@ -34,6 +34,7 @@
markdown,
ocaml-native-compilers | ocaml-nox,
ocaml-findlib,
+ quilt,
Homepage: https://xenproject.org/
Vcs-Browser: https://salsa.debian.org/xen-team/debian-xen
Vcs-Git: https://salsa.debian.org/xen-team/debian-xen.git
diff -Nru
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
--- xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,105 +0,0 @@
-From: Stefano Stabellini <sstabellini at kernel.org>
-Date: Fri, 2 Oct 2020 13:47:17 -0700
-Subject: xen/rpi4: implement watchdog-based reset
-
-The preferred method to reboot RPi4 is PSCI. If it is not available,
-touching the watchdog is required to be able to reboot the board.
-
-The implementation is based on
-drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
-
-Signed-off-by: Stefano Stabellini <stefano.stabellini at xilinx.com>
-Acked-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Bertrand Marquis <bertrand.marquis at arm.com>
-Tested-by: Roman Shaposhnik <roman at zededa.com>
-CC: roman at zededa.com
-(cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9)
----
- xen/arch/arm/platforms/brcm-raspberry-pi.c | 61 ++++++++++++++++++++++++++++++
- 1 file changed, 61 insertions(+)
-
-diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-index f5ae58a..811b40b 100644
---- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
-+++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-@@ -17,6 +17,10 @@
- * GNU General Public License for more details.
- */
-
-+#include <xen/delay.h>
-+#include <xen/mm.h>
-+#include <xen/vmap.h>
-+#include <asm/io.h>
- #include <asm/platform.h>
-
- static const char *const rpi4_dt_compat[] __initconst -@@ -37,12 +41,69 @@
static const struct dt_device_match rpi4_blacklist_dev[] __initconst - *
The aux peripheral also shares a page with the aux UART.
- */
- DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
-+ /* Special device used for rebooting */
-+ DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
- { /* sentinel */ },
- };
-
-+
-+#define PM_PASSWORD 0x5a000000
-+#define PM_RSTC 0x1c
-+#define PM_WDOG 0x24
-+#define PM_RSTC_WRCFG_FULL_RESET 0x00000020
-+#define PM_RSTC_WRCFG_CLR 0xffffffcf
-+
-+static void __iomem *rpi4_map_watchdog(void)
-+{
-+ void __iomem *base;
-+ struct dt_device_node *node;
-+ paddr_t start, len;
-+ int ret;
-+
-+ node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
-+ if ( !node )
-+ return NULL;
-+
-+ ret = dt_device_get_address(node, 0, &start, &len);
-+ if ( ret )
-+ {
-+ printk("Cannot read watchdog register address\n");
-+ return NULL;
-+ }
-+
-+ base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
-+ if ( !base )
-+ {
-+ printk("Unable to map watchdog register!\n");
-+ return NULL;
-+ }
-+
-+ return base;
-+}
-+
-+static void rpi4_reset(void)
-+{
-+ uint32_t val;
-+ void __iomem *base = rpi4_map_watchdog();
-+
-+ if ( !base )
-+ return;
-+
-+ /* use a timeout of 10 ticks (~150us) */
-+ writel(10 | PM_PASSWORD, base + PM_WDOG);
-+ val = readl(base + PM_RSTC);
-+ val &= PM_RSTC_WRCFG_CLR;
-+ val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
-+ writel(val, base + PM_RSTC);
-+
-+ /* No sleeping, possibly atomic. */
-+ mdelay(1);
-+}
-+
- PLATFORM_START(rpi4, "Raspberry Pi 4")
- .compatible = rpi4_dt_compat,
- .blacklist_dev = rpi4_blacklist_dev,
-+ .reset = rpi4_reset,
- .dma_bitsize = 30,
- PLATFORM_END
-
diff -Nru
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
---
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,91 +0,0 @@
-From: Elliott Mitchell <ehem+xen at m5p.com>
-Date: Sun, 11 Oct 2020 18:11:39 -0700
-Subject: tools/python: Pass linker to Python build process
-MIME-Version: 1.0
-Content-Type: text/plain; charset="utf-8"
-Content-Transfer-Encoding: 8bit
-
-Unexpectedly the environment variable which needs to be passed is
-$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
-of the host `ld`.
-
-Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
-it can load at runtime, not executables.
-
-This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
-to $LDFLAGS which breaks many linkers.
-
-Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
-Acked-by: Marek Marczykowski-G?recki <marmarek at invisiblethingslab.com>
-(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
-
-[ Hans van Kranenburg ]
-Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
-between in the same lines. The line wrap mess makes it a bit hard to
-follow.
----
- tools/pygrub/Makefile | 11 ++++++-----
- tools/python/Makefile | 9 +++++----
- 2 files changed, 11 insertions(+), 9 deletions(-)
-
-diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
-index 4cd1a95..2950f37 100644
---- a/tools/pygrub/Makefile
-+++ b/tools/pygrub/Makefile
-@@ -3,21 +3,22 @@ XEN_ROOT = $(CURDIR)/../..
- include $(XEN_ROOT)/tools/Rules.mk
-
- PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
--PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
-+PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
- INSTALL_LOG = build/installed_files.txt
-
- .PHONY: all
- all: build
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py
build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" \
-+ LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
-
- .PHONY: install
- install: all
- $(INSTALL_DIR) $(DESTDIR)/$(bindir)
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" \
-- LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) \
-- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
-+ LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON)
setup.py install \
-+ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
- --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force
- set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \
- "`readlink -f $(DESTDIR)/$(bindir)`" != \
-diff --git a/tools/python/Makefile b/tools/python/Makefile
-index 8d22c03..b675f5b 100644
---- a/tools/python/Makefile
-+++ b/tools/python/Makefile
-@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
- all: build
-
- PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
--PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
-+PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
- INSTALL_LOG = build/installed_files.txt
-
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py
build
-
- .PHONY: install
- install:
- $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
-- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
-+ LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py install \
-+ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
- --root="$(DESTDIR)" --force
-
- $(INSTALL_PYTHON_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
diff -Nru
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
---
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,47 +0,0 @@
-From: Elliott Mitchell <ehem+xen at m5p.com>
-Date: Wed, 21 Oct 2020 15:12:53 -0700
-Subject: xen/arm: acpi: Don't fail if SPCR table is absent
-
-Absence of a SPCR table likely means the console is a framebuffer. In
-such case acpi_iomem_deny_access() should NOT fail.
-
-Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
-Acked-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 861f0c110976fa8879b7bf63d9478b6be83d4ab6)
----
- xen/arch/arm/acpi/domain_build.c | 19 ++++++++++---------
- 1 file changed, 10 insertions(+), 9 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/domain_build.c
b/xen/arch/arm/acpi/domain_build.c
-index 1b1cfab..bbdc90f 100644
---- a/xen/arch/arm/acpi/domain_build.c
-+++ b/xen/arch/arm/acpi/domain_build.c
-@@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain *d)
- status = acpi_get_table(ACPI_SIG_SPCR, 0,
- (struct acpi_table_header **)&spcr);
-
-- if ( ACPI_FAILURE(status) )
-+ if ( ACPI_SUCCESS(status) )
- {
-- printk("Failed to get SPCR table\n");
-- return -EINVAL;
-+ mfn = spcr->serial_port.address >> PAGE_SHIFT;
-+ /* Deny MMIO access for UART */
-+ rc = iomem_deny_access(d, mfn, mfn + 1);
-+ if ( rc )
-+ return rc;
-+ }
-+ else
-+ {
-+ printk("Failed to get SPCR table, Xen console may be
unavailable\n");
- }
--
-- mfn = spcr->serial_port.address >> PAGE_SHIFT;
-- /* Deny MMIO access for UART */
-- rc = iomem_deny_access(d, mfn, mfn + 1);
-- if ( rc )
-- return rc;
-
- /* Deny MMIO access for GIC regions */
- return gic_iomem_deny_access(d);
diff -Nru
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
---
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,163 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 17:44:29 +0100
-Subject: xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
-
-The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
-while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
-
-Currently, the former are still containing x86 specific code.
-
-To avoid this rather strange split, the generic helpers are reworked so
-they are arch-agnostic. This requires the introduction of a new helper
-__acpi_os_unmap_memory() that will undo any mapping done by
-__acpi_os_map_memory().
-
-Currently, the arch-helper for unmap is basically a no-op so it only
-returns whether the mapping was arch specific. But this will change
-in the future.
-
-Note that the x86 version of acpi_os_map_memory() was already able to
-able the 1MB region. Hence why there is no addition of new code.
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Rahul Singh <rahul.singh at arm.com>
-Reviewed-by: Jan Beulich <jbeulich at suse.com>
-Acked-by: Stefano Stabellini <sstabellini at kernel.org>
-Tested-by: Rahul Singh <rahul.singh at arm.com>
-Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
-(cherry picked from commit 1c4aa69ca1e1fad20b2158051eb152276d1eb973)
----
- xen/arch/arm/acpi/lib.c | 12 ++++++++++++
- xen/arch/x86/acpi/lib.c | 18 ++++++++++++++++++
- xen/drivers/acpi/osl.c | 34 ++++++++++++++++++----------------
- xen/include/xen/acpi.h | 1 +
- 4 files changed, 49 insertions(+), 16 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
-index 4fc6e17..fcc186b 100644
---- a/xen/arch/arm/acpi/lib.c
-+++ b/xen/arch/arm/acpi/lib.c
-@@ -30,6 +30,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- unsigned long base, offset, mapped_size;
- int idx;
-
-+ /* No arch specific implementation after early boot */
-+ if ( system_state >= SYS_STATE_boot )
-+ return NULL;
-+
- offset = phys & (PAGE_SIZE - 1);
- mapped_size = PAGE_SIZE - offset;
- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-@@ -49,6 +53,14 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- return ((char *) base + offset);
- }
-
-+bool __acpi_unmap_table(const void *ptr, unsigned long size)
-+{
-+ vaddr_t vaddr = (vaddr_t)ptr;
-+
-+ return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
-+ (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
-+}
-+
- /* True to indicate PSCI 0.2+ is implemented */
- bool __init acpi_psci_present(void)
- {
-diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
-index 265b9ad..a22414a 100644
---- a/xen/arch/x86/acpi/lib.c
-+++ b/xen/arch/x86/acpi/lib.c
-@@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- if ((phys + size) <= (1 * 1024 * 1024))
- return __va(phys);
-
-+ /* No further arch specific implementation after early boot */
-+ if (system_state >= SYS_STATE_boot)
-+ return NULL;
-+
- offset = phys & (PAGE_SIZE - 1);
- mapped_size = PAGE_SIZE - offset;
- set_fixmap(FIX_ACPI_END, phys);
-@@ -66,6 +70,20 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- return ((char *) base + offset);
- }
-
-+bool __acpi_unmap_table(const void *ptr, unsigned long size)
-+{
-+ unsigned long vaddr = (unsigned long)ptr;
-+
-+ if ((vaddr >= DIRECTMAP_VIRT_START) &&
-+ (vaddr < DIRECTMAP_VIRT_END)) {
-+ ASSERT(!((__pa(ptr) + size - 1) >> 20));
-+ return true;
-+ }
-+
-+ return ((vaddr >= __fix_to_virt(FIX_ACPI_END)) &&
-+ (vaddr < (__fix_to_virt(FIX_ACPI_BEGIN) + PAGE_SIZE)));
-+}
-+
- unsigned int acpi_get_processor_id(unsigned int cpu)
- {
- unsigned int acpiid, apicid;
-diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
-index 4c8bb78..389505f 100644
---- a/xen/drivers/acpi/osl.c
-+++ b/xen/drivers/acpi/osl.c
-@@ -92,27 +92,29 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
- void __iomem *
- acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
- {
-- if (system_state >= SYS_STATE_boot) {
-- mfn_t mfn = _mfn(PFN_DOWN(phys));
-- unsigned int offs = phys & (PAGE_SIZE - 1);
--
-- /* The low first Mb is always mapped on x86. */
-- if (IS_ENABLED(CONFIG_X86) && !((phys + size - 1) >> 20))
-- return __va(phys);
-- return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-- ACPI_MAP_MEM_ATTR, VMAP_DEFAULT) + offs;
-- }
-- return __acpi_map_table(phys, size);
-+ void *ptr;
-+ mfn_t mfn = _mfn(PFN_DOWN(phys));
-+ unsigned int offs = PAGE_OFFSET(phys);
-+
-+ /* Try the arch specific implementation first */
-+ ptr = __acpi_map_table(phys, size);
-+ if (ptr)
-+ return ptr;
-+
-+ /* No common implementation for early boot map */
-+ if (unlikely(system_state < SYS_STATE_boot))
-+ return NULL;
-+
-+ ptr = __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-+ ACPI_MAP_MEM_ATTR, VMAP_DEFAULT);
-+
-+ return !ptr ? NULL : (ptr + offs);
- }
-
- void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
- {
-- if (IS_ENABLED(CONFIG_X86) &&
-- (unsigned long)virt >= DIRECTMAP_VIRT_START &&
-- (unsigned long)virt < DIRECTMAP_VIRT_END) {
-- ASSERT(!((__pa(virt) + size - 1) >> 20));
-+ if (__acpi_unmap_table(virt, size))
- return;
-- }
-
- if (system_state >= SYS_STATE_boot)
- vunmap((void *)((unsigned long)virt & PAGE_MASK));
-diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
-index c945ab0..21d5e9f 100644
---- a/xen/include/xen/acpi.h
-+++ b/xen/include/xen/acpi.h
-@@ -68,6 +68,7 @@ typedef int (*acpi_table_entry_handler) (struct
acpi_subtable_header *header, co
-
- unsigned int acpi_get_processor_id (unsigned int cpu);
- char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
-+bool __acpi_unmap_table(const void *ptr, unsigned long size);
- int acpi_boot_init (void);
- int acpi_boot_table_init (void);
- int acpi_numa_init (void);
diff -Nru
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
---
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,131 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 19:53:27 +0100
-Subject: xen/arm: acpi: The fixmap area should always be cleared during
- failure/unmap
-
-Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
-{set, clear}_fixmap()" enforced that each set_fixmap() should be
-paired with a clear_fixmap(). Any failure to follow the model would
-result to a platform crash.
-
-Unfortunately, the use of fixmap in the ACPI code was overlooked as it
-is calling set_fixmap() but not clear_fixmap().
-
-The function __acpi_os_map_table() is reworked so:
- - We know before the mapping whether the fixmap region is big
- enough for the mapping.
- - It will fail if the fixmap is already in use. This is not a
- change of behavior but clarifying the current expectation to avoid
- hitting a BUG().
-
-The function __acpi_os_unmap_table() will now call clear_fixmap().
-
-Reported-by: Wei Xu <xuwei5 at hisilicon.com>
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 4d625ff3c3a939dc270b03654337568c30c5ab6e)
----
- xen/arch/arm/acpi/lib.c | 73 +++++++++++++++++++++++++++++++++++++------------
- 1 file changed, 56 insertions(+), 17 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
-index fcc186b..a59cc40 100644
---- a/xen/arch/arm/acpi/lib.c
-+++ b/xen/arch/arm/acpi/lib.c
-@@ -25,40 +25,79 @@
- #include <xen/init.h>
- #include <xen/mm.h>
-
-+static bool fixmap_inuse;
-+
- char *__acpi_map_table(paddr_t phys, unsigned long size)
- {
-- unsigned long base, offset, mapped_size;
-- int idx;
-+ unsigned long base, offset;
-+ mfn_t mfn;
-+ unsigned int idx;
-
- /* No arch specific implementation after early boot */
- if ( system_state >= SYS_STATE_boot )
- return NULL;
-
- offset = phys & (PAGE_SIZE - 1);
-- mapped_size = PAGE_SIZE - offset;
-- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-- base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
-+ base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) + offset;
-+
-+ /* Check the fixmap is big enough to map the region */
-+ if ( (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - base) < size )
-+ return NULL;
-+
-+ /* With the fixmap, we can only map one region at the time */
-+ if ( fixmap_inuse )
-+ return NULL;
-
-- /* Most cases can be covered by the below. */
-+ fixmap_inuse = true;
-+
-+ size += offset;
-+ mfn = maddr_to_mfn(phys);
- idx = FIXMAP_ACPI_BEGIN;
-- while ( mapped_size < size )
-- {
-- if ( ++idx > FIXMAP_ACPI_END )
-- return NULL; /* cannot handle this */
-- phys += PAGE_SIZE;
-- set_fixmap(idx, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-- mapped_size += PAGE_SIZE;
-- }
-
-- return ((char *) base + offset);
-+ do {
-+ set_fixmap(idx, mfn, PAGE_HYPERVISOR);
-+ size -= min(size, (unsigned long)PAGE_SIZE);
-+ mfn = mfn_add(mfn, 1);
-+ idx++;
-+ } while ( size > 0 );
-+
-+ return (char *)base;
- }
-
- bool __acpi_unmap_table(const void *ptr, unsigned long size)
- {
- vaddr_t vaddr = (vaddr_t)ptr;
-+ unsigned int idx;
-+
-+ /* We are only handling fixmap address in the arch code */
-+ if ( (vaddr < FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) ||
-+ (vaddr >= (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)) )
-+ return false;
-+
-+ /*
-+ * __acpi_map_table() will always return a pointer in the first page
-+ * for the ACPI fixmap region. The caller is expected to free with
-+ * the same address.
-+ */
-+ ASSERT((vaddr & PAGE_MASK) == FIXMAP_ADDR(FIXMAP_ACPI_BEGIN));
-+
-+ /* The region allocated fit in the ACPI fixmap region. */
-+ ASSERT(size < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - vaddr));
-+ ASSERT(fixmap_inuse);
-+
-+ fixmap_inuse = false;
-+
-+ size += vaddr - FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
-+ idx = FIXMAP_ACPI_BEGIN;
-+
-+ do
-+ {
-+ clear_fixmap(idx);
-+ size -= min(size, (unsigned long)PAGE_SIZE);
-+ idx++;
-+ } while ( size > 0 );
-
-- return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
-- (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
-+ return true;
- }
-
- /* True to indicate PSCI 0.2+ is implemented */
diff -Nru
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
---
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,39 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 21:16:55 +0100
-Subject: xen/arm: Check if the platform is not using ACPI before initializing
- Dom0less
-
-Dom0less requires a device-tree. However, since commit 6e3e77120378
-"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
-device-tree will not get unflatten when using ACPI.
-
-This will lead to a crash during boot.
-
-Given the complexity to setup dom0less with ACPI (for instance how to
-assign device?), we should skip any code related to Dom0less when using
-ACPI.
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Tested-by: Rahul Singh <rahul.singh at arm.com>
-Reviewed-by: Rahul Singh <rahul.singh at arm.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
-(cherry picked from commit dac867bf9adc1562a4cf9db5f89726597af13ef8)
----
- xen/arch/arm/setup.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
-index 34b1c1a..fb2f45e 100644
---- a/xen/arch/arm/setup.c
-+++ b/xen/arch/arm/setup.c
-@@ -961,7 +961,8 @@ void __init start_xen(unsigned long boot_phys_offset,
- if ( construct_dom0(dom0) != 0)
- panic("Could not set up DOM0 guest OS\n");
-
-- create_domUs();
-+ if ( acpi_disabled )
-+ create_domUs();
-
- /*
- * This needs to be called **before** heap_init_late() so modules
diff -Nru
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
---
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,124 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 21:30:14 +0100
-Subject: xen/arm: Introduce fw_unreserved_regions() and use it
-
-Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
-later on in the boot", the device-tree will not be kept mapped when
-using ACPI.
-
-However, a few places are calling dt_unreserved_regions() which expects
-a valid DT. This will lead to a crash.
-
-As the DT should not be used for ACPI (other than for detecting the
-modules), a new function fw_unreserved_regions() is introduced.
-
-It will behave the same way on DT system. On ACPI system, it will
-unreserve the whole region.
-
-Take the opportunity to clarify that bootinfo.reserved_mem is only used
-when booting using Device-Tree.
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0)
----
- xen/arch/arm/kernel.c | 2 +-
- xen/arch/arm/setup.c | 22 +++++++++++++++++-----
- xen/include/asm-arm/setup.h | 3 ++-
- 3 files changed, 20 insertions(+), 7 deletions(-)
-
-diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
-index 8eff074..27dace0 100644
---- a/xen/arch/arm/kernel.c
-+++ b/xen/arch/arm/kernel.c
-@@ -307,7 +307,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
- * Free the original kernel, update the pointers to the
- * decompressed kernel
- */
-- dt_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-+ fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-
- return 0;
- }
-diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
-index fb2f45e..c94827e 100644
---- a/xen/arch/arm/setup.c
-+++ b/xen/arch/arm/setup.c
-@@ -183,8 +183,9 @@ static void __init processor_id(void)
- processor_setup();
- }
-
--void __init dt_unreserved_regions(paddr_t s, paddr_t e,
-- void (*cb)(paddr_t, paddr_t), int first)
-+static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
-+ void (*cb)(paddr_t, paddr_t),
-+ int first)
- {
- int i, nr = fdt_num_mem_rsv(device_tree_flattened);
-
-@@ -231,6 +232,17 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
- cb(s, e);
- }
-
-+void __init fw_unreserved_regions(paddr_t s, paddr_t e,
-+ void (*cb)(paddr_t, paddr_t), int first)
-+{
-+ if ( acpi_disabled )
-+ dt_unreserved_regions(s, e, cb, first);
-+ else
-+ cb(s, e);
-+}
-+
-+
-+
- struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size,
- bool domU)
-@@ -392,7 +404,7 @@ void __init discard_initial_modules(void)
- !mfn_valid(maddr_to_mfn(e)) )
- continue;
-
-- dt_unreserved_regions(s, e, init_domheap_pages, 0);
-+ fw_unreserved_regions(s, e, init_domheap_pages, 0);
- }
-
- mi->nr_mods = 0;
-@@ -699,7 +711,7 @@ static void __init setup_mm(void)
- n = mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages));
- }
-
-- dt_unreserved_regions(s, e, init_boot_pages, 0);
-+ fw_unreserved_regions(s, e, init_boot_pages, 0);
-
- s = n;
- }
-@@ -752,7 +764,7 @@ static void __init setup_mm(void)
- if ( e > bank_end )
- e = bank_end;
-
-- dt_unreserved_regions(s, e, init_boot_pages, 0);
-+ fw_unreserved_regions(s, e, init_boot_pages, 0);
- s = n;
- }
- }
-diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
-index 2f8f24e..28bf622 100644
---- a/xen/include/asm-arm/setup.h
-+++ b/xen/include/asm-arm/setup.h
-@@ -67,6 +67,7 @@ struct bootcmdlines {
-
- struct bootinfo {
- struct meminfo mem;
-+ /* The reserved regions are only used when booting using Device-Tree */
- struct meminfo reserved_mem;
- struct bootmodules modules;
- struct bootcmdlines cmdlines;
-@@ -96,7 +97,7 @@ int construct_dom0(struct domain *d);
- void create_domUs(void);
-
- void discard_initial_modules(void);
--void dt_unreserved_regions(paddr_t s, paddr_t e,
-+void fw_unreserved_regions(paddr_t s, paddr_t e,
- void (*cb)(paddr_t, paddr_t), int first);
-
- size_t boot_fdt_info(const void *fdt, paddr_t paddr);
diff -Nru
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
---
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,60 +0,0 @@
-From: Julien Grall <julien.grall at arm.com>
-Date: Wed, 30 Sep 2020 12:25:04 +0100
-Subject: xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro
-
-Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
-
- The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
- of the MADT. In the ACPI 5.1 version of the spec, the struct for the
- GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
- ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
- in ACPICA for this struct -- and that is the 6.0 version. Hence, when
- BAD_MADT_ENTRY() compares the struct size to the length in the GICC
- subtable, it fails if 5.1 structs are in use, and there are systems in
- the wild that have them.
-
- This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
- only, accounting for the difference in specification versions that are
- possible. The BAD_MADT_ENTRY() will continue to work as is for all other
- MADT subtables.
-
- This code is being added to an arm64 header file since that is currently
- the only architecture using the GICC subtable of the MADT. As a GIC is
- specific to ARM, it is also unlikely the subtable will be used elsewhere.
-
- Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT
table.")
- Signed-off-by: Al Stone <al.stone at linaro.org>
- Acked-by: Will Deacon <will.deacon at arm.com>
- Acked-by: "Rafael J. Wysocki" <rjw at rjwysocki.net>
- [catalin.marinas at arm.com: extra brackets around macro arguments]
- Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
-
-Signed-off-by: Julien Grall <julien.grall at arm.com>
-Signed-off-by: Andre Przywara <andre.przywara at arm.com>
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Acked-by: Stefano Stabellini <sstabellini at kernel.org>
-Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
-(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
----
- xen/include/asm-arm/acpi.h | 8 ++++++++
- 1 file changed, 8 insertions(+)
-
-diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
-index 5034028..b52ae2d 100644
---- a/xen/include/asm-arm/acpi.h
-+++ b/xen/include/asm-arm/acpi.h
-@@ -54,6 +54,14 @@ void acpi_smp_init_cpus(void);
- */
- paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
-
-+/* Macros for consistency checks of the GICC subtable of MADT */
-+#define ACPI_MADT_GICC_LENGTH \
-+ (acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
-+
-+#define BAD_MADT_GICC_ENTRY(entry, end) \
-+ (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \
-+ (entry)->header.length != ACPI_MADT_GICC_LENGTH)
-+
- #ifdef CONFIG_ACPI
- extern bool acpi_disabled;
- /* Basic configuration for ACPI */
diff -Nru
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
---
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,29 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Thu, 5 Nov 2020 22:31:06 +0000
-Subject: xen/arm: traps: Don't panic when receiving an unknown debug trap
-
-Even if debug trap are only meant for debugging purpose, it is quite
-harsh to crash Xen if one of the trap sent by the guest is not handled.
-
-So switch from a panic() to a printk().
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 957708c2d1ae25d7375abd5e5e70c3043d64f1f1)
----
- xen/arch/arm/traps.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
-index 2197df2..22bd1bd 100644
---- a/xen/arch/arm/traps.c
-+++ b/xen/arch/arm/traps.c
-@@ -1411,7 +1411,7 @@ static void do_debug_trap(struct cpu_user_regs *regs,
unsigned int code)
- show_execution_state(regs);
- break;
- default:
-- panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
-+ printk("DOM%d: Unhandled debug trap %#x\n", domid, code);
- break;
- }
- }
diff -Nru
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
---
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,105 @@
+From: Stefano Stabellini <sstabellini at kernel.org>
+Date: Fri, 2 Oct 2020 13:47:17 -0700
+Subject: xen/rpi4: implement watchdog-based reset
+
+The preferred method to reboot RPi4 is PSCI. If it is not available,
+touching the watchdog is required to be able to reboot the board.
+
+The implementation is based on
+drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
+
+Signed-off-by: Stefano Stabellini <stefano.stabellini at xilinx.com>
+Acked-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Bertrand Marquis <bertrand.marquis at arm.com>
+Tested-by: Roman Shaposhnik <roman at zededa.com>
+CC: roman at zededa.com
+(cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9)
+---
+ xen/arch/arm/platforms/brcm-raspberry-pi.c | 61 ++++++++++++++++++++++++++++++
+ 1 file changed, 61 insertions(+)
+
+diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
+index f5ae58a..811b40b 100644
+--- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
++++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
+@@ -17,6 +17,10 @@
+ * GNU General Public License for more details.
+ */
+
++#include <xen/delay.h>
++#include <xen/mm.h>
++#include <xen/vmap.h>
++#include <asm/io.h>
+ #include <asm/platform.h>
+
+ static const char *const rpi4_dt_compat[] __initconst +@@ -37,12 +41,69 @@
static const struct dt_device_match rpi4_blacklist_dev[] __initconst + *
The aux peripheral also shares a page with the aux UART.
+ */
+ DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
++ /* Special device used for rebooting */
++ DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
+ { /* sentinel */ },
+ };
+
++
++#define PM_PASSWORD 0x5a000000
++#define PM_RSTC 0x1c
++#define PM_WDOG 0x24
++#define PM_RSTC_WRCFG_FULL_RESET 0x00000020
++#define PM_RSTC_WRCFG_CLR 0xffffffcf
++
++static void __iomem *rpi4_map_watchdog(void)
++{
++ void __iomem *base;
++ struct dt_device_node *node;
++ paddr_t start, len;
++ int ret;
++
++ node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
++ if ( !node )
++ return NULL;
++
++ ret = dt_device_get_address(node, 0, &start, &len);
++ if ( ret )
++ {
++ printk("Cannot read watchdog register address\n");
++ return NULL;
++ }
++
++ base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
++ if ( !base )
++ {
++ printk("Unable to map watchdog register!\n");
++ return NULL;
++ }
++
++ return base;
++}
++
++static void rpi4_reset(void)
++{
++ uint32_t val;
++ void __iomem *base = rpi4_map_watchdog();
++
++ if ( !base )
++ return;
++
++ /* use a timeout of 10 ticks (~150us) */
++ writel(10 | PM_PASSWORD, base + PM_WDOG);
++ val = readl(base + PM_RSTC);
++ val &= PM_RSTC_WRCFG_CLR;
++ val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
++ writel(val, base + PM_RSTC);
++
++ /* No sleeping, possibly atomic. */
++ mdelay(1);
++}
++
+ PLATFORM_START(rpi4, "Raspberry Pi 4")
+ .compatible = rpi4_dt_compat,
+ .blacklist_dev = rpi4_blacklist_dev,
++ .reset = rpi4_reset,
+ .dma_bitsize = 30,
+ PLATFORM_END
+
diff -Nru
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
---
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,91 @@
+From: Elliott Mitchell <ehem+xen at m5p.com>
+Date: Sun, 11 Oct 2020 18:11:39 -0700
+Subject: tools/python: Pass linker to Python build process
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Unexpectedly the environment variable which needs to be passed is
+$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
+of the host `ld`.
+
+Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
+it can load at runtime, not executables.
+
+This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
+to $LDFLAGS which breaks many linkers.
+
+Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
+Acked-by: Marek Marczykowski-G?recki <marmarek at invisiblethingslab.com>
+(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
+
+[ Hans van Kranenburg ]
+Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
+between in the same lines. The line wrap mess makes it a bit hard to
+follow.
+---
+ tools/pygrub/Makefile | 11 ++++++-----
+ tools/python/Makefile | 9 +++++----
+ 2 files changed, 11 insertions(+), 9 deletions(-)
+
+diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
+index 4cd1a95..2950f37 100644
+--- a/tools/pygrub/Makefile
++++ b/tools/pygrub/Makefile
+@@ -3,21 +3,22 @@ XEN_ROOT = $(CURDIR)/../..
+ include $(XEN_ROOT)/tools/Rules.mk
+
+ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
+-PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
++PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
+ INSTALL_LOG = build/installed_files.txt
+
+ .PHONY: all
+ all: build
+ .PHONY: build
+ build:
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py
build
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" \
++ LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
+
+ .PHONY: install
+ install: all
+ $(INSTALL_DIR) $(DESTDIR)/$(bindir)
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" \
+- LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) \
+- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
++ LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON)
setup.py install \
++ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
+ --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force
+ set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \
+ "`readlink -f $(DESTDIR)/$(bindir)`" != \
+diff --git a/tools/python/Makefile b/tools/python/Makefile
+index 8d22c03..b675f5b 100644
+--- a/tools/python/Makefile
++++ b/tools/python/Makefile
+@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
+ all: build
+
+ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
+-PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
++PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
+ INSTALL_LOG = build/installed_files.txt
+
+ .PHONY: build
+ build:
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py
build
+
+ .PHONY: install
+ install:
+ $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
+- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
++ LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py install \
++ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
+ --root="$(DESTDIR)" --force
+
+ $(INSTALL_PYTHON_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
diff -Nru
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
---
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,47 @@
+From: Elliott Mitchell <ehem+xen at m5p.com>
+Date: Wed, 21 Oct 2020 15:12:53 -0700
+Subject: xen/arm: acpi: Don't fail if SPCR table is absent
+
+Absence of a SPCR table likely means the console is a framebuffer. In
+such case acpi_iomem_deny_access() should NOT fail.
+
+Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
+Acked-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 861f0c110976fa8879b7bf63d9478b6be83d4ab6)
+---
+ xen/arch/arm/acpi/domain_build.c | 19 ++++++++++---------
+ 1 file changed, 10 insertions(+), 9 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/domain_build.c
b/xen/arch/arm/acpi/domain_build.c
+index 1b1cfab..bbdc90f 100644
+--- a/xen/arch/arm/acpi/domain_build.c
++++ b/xen/arch/arm/acpi/domain_build.c
+@@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain *d)
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr);
+
+- if ( ACPI_FAILURE(status) )
++ if ( ACPI_SUCCESS(status) )
+ {
+- printk("Failed to get SPCR table\n");
+- return -EINVAL;
++ mfn = spcr->serial_port.address >> PAGE_SHIFT;
++ /* Deny MMIO access for UART */
++ rc = iomem_deny_access(d, mfn, mfn + 1);
++ if ( rc )
++ return rc;
++ }
++ else
++ {
++ printk("Failed to get SPCR table, Xen console may be
unavailable\n");
+ }
+-
+- mfn = spcr->serial_port.address >> PAGE_SHIFT;
+- /* Deny MMIO access for UART */
+- rc = iomem_deny_access(d, mfn, mfn + 1);
+- if ( rc )
+- return rc;
+
+ /* Deny MMIO access for GIC regions */
+ return gic_iomem_deny_access(d);
diff -Nru
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
---
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,163 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 17:44:29 +0100
+Subject: xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
+
+The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
+while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
+
+Currently, the former are still containing x86 specific code.
+
+To avoid this rather strange split, the generic helpers are reworked so
+they are arch-agnostic. This requires the introduction of a new helper
+__acpi_os_unmap_memory() that will undo any mapping done by
+__acpi_os_map_memory().
+
+Currently, the arch-helper for unmap is basically a no-op so it only
+returns whether the mapping was arch specific. But this will change
+in the future.
+
+Note that the x86 version of acpi_os_map_memory() was already able to
+able the 1MB region. Hence why there is no addition of new code.
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Rahul Singh <rahul.singh at arm.com>
+Reviewed-by: Jan Beulich <jbeulich at suse.com>
+Acked-by: Stefano Stabellini <sstabellini at kernel.org>
+Tested-by: Rahul Singh <rahul.singh at arm.com>
+Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
+(cherry picked from commit 1c4aa69ca1e1fad20b2158051eb152276d1eb973)
+---
+ xen/arch/arm/acpi/lib.c | 12 ++++++++++++
+ xen/arch/x86/acpi/lib.c | 18 ++++++++++++++++++
+ xen/drivers/acpi/osl.c | 34 ++++++++++++++++++----------------
+ xen/include/xen/acpi.h | 1 +
+ 4 files changed, 49 insertions(+), 16 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
+index 4fc6e17..fcc186b 100644
+--- a/xen/arch/arm/acpi/lib.c
++++ b/xen/arch/arm/acpi/lib.c
+@@ -30,6 +30,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ unsigned long base, offset, mapped_size;
+ int idx;
+
++ /* No arch specific implementation after early boot */
++ if ( system_state >= SYS_STATE_boot )
++ return NULL;
++
+ offset = phys & (PAGE_SIZE - 1);
+ mapped_size = PAGE_SIZE - offset;
+ set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+@@ -49,6 +53,14 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ return ((char *) base + offset);
+ }
+
++bool __acpi_unmap_table(const void *ptr, unsigned long size)
++{
++ vaddr_t vaddr = (vaddr_t)ptr;
++
++ return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
++ (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
++}
++
+ /* True to indicate PSCI 0.2+ is implemented */
+ bool __init acpi_psci_present(void)
+ {
+diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
+index 265b9ad..a22414a 100644
+--- a/xen/arch/x86/acpi/lib.c
++++ b/xen/arch/x86/acpi/lib.c
+@@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ if ((phys + size) <= (1 * 1024 * 1024))
+ return __va(phys);
+
++ /* No further arch specific implementation after early boot */
++ if (system_state >= SYS_STATE_boot)
++ return NULL;
++
+ offset = phys & (PAGE_SIZE - 1);
+ mapped_size = PAGE_SIZE - offset;
+ set_fixmap(FIX_ACPI_END, phys);
+@@ -66,6 +70,20 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ return ((char *) base + offset);
+ }
+
++bool __acpi_unmap_table(const void *ptr, unsigned long size)
++{
++ unsigned long vaddr = (unsigned long)ptr;
++
++ if ((vaddr >= DIRECTMAP_VIRT_START) &&
++ (vaddr < DIRECTMAP_VIRT_END)) {
++ ASSERT(!((__pa(ptr) + size - 1) >> 20));
++ return true;
++ }
++
++ return ((vaddr >= __fix_to_virt(FIX_ACPI_END)) &&
++ (vaddr < (__fix_to_virt(FIX_ACPI_BEGIN) + PAGE_SIZE)));
++}
++
+ unsigned int acpi_get_processor_id(unsigned int cpu)
+ {
+ unsigned int acpiid, apicid;
+diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
+index 4c8bb78..389505f 100644
+--- a/xen/drivers/acpi/osl.c
++++ b/xen/drivers/acpi/osl.c
+@@ -92,27 +92,29 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
+ void __iomem *
+ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+ {
+- if (system_state >= SYS_STATE_boot) {
+- mfn_t mfn = _mfn(PFN_DOWN(phys));
+- unsigned int offs = phys & (PAGE_SIZE - 1);
+-
+- /* The low first Mb is always mapped on x86. */
+- if (IS_ENABLED(CONFIG_X86) && !((phys + size - 1) >> 20))
+- return __va(phys);
+- return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
+- ACPI_MAP_MEM_ATTR, VMAP_DEFAULT) + offs;
+- }
+- return __acpi_map_table(phys, size);
++ void *ptr;
++ mfn_t mfn = _mfn(PFN_DOWN(phys));
++ unsigned int offs = PAGE_OFFSET(phys);
++
++ /* Try the arch specific implementation first */
++ ptr = __acpi_map_table(phys, size);
++ if (ptr)
++ return ptr;
++
++ /* No common implementation for early boot map */
++ if (unlikely(system_state < SYS_STATE_boot))
++ return NULL;
++
++ ptr = __vmap(&mfn, PFN_UP(offs + size), 1, 1,
++ ACPI_MAP_MEM_ATTR, VMAP_DEFAULT);
++
++ return !ptr ? NULL : (ptr + offs);
+ }
+
+ void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
+ {
+- if (IS_ENABLED(CONFIG_X86) &&
+- (unsigned long)virt >= DIRECTMAP_VIRT_START &&
+- (unsigned long)virt < DIRECTMAP_VIRT_END) {
+- ASSERT(!((__pa(virt) + size - 1) >> 20));
++ if (__acpi_unmap_table(virt, size))
+ return;
+- }
+
+ if (system_state >= SYS_STATE_boot)
+ vunmap((void *)((unsigned long)virt & PAGE_MASK));
+diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
+index c945ab0..21d5e9f 100644
+--- a/xen/include/xen/acpi.h
++++ b/xen/include/xen/acpi.h
+@@ -68,6 +68,7 @@ typedef int (*acpi_table_entry_handler) (struct
acpi_subtable_header *header, co
+
+ unsigned int acpi_get_processor_id (unsigned int cpu);
+ char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
++bool __acpi_unmap_table(const void *ptr, unsigned long size);
+ int acpi_boot_init (void);
+ int acpi_boot_table_init (void);
+ int acpi_numa_init (void);
diff -Nru
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
---
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,131 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 19:53:27 +0100
+Subject: xen/arm: acpi: The fixmap area should always be cleared during
+ failure/unmap
+
+Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
+{set, clear}_fixmap()" enforced that each set_fixmap() should be
+paired with a clear_fixmap(). Any failure to follow the model would
+result to a platform crash.
+
+Unfortunately, the use of fixmap in the ACPI code was overlooked as it
+is calling set_fixmap() but not clear_fixmap().
+
+The function __acpi_os_map_table() is reworked so:
+ - We know before the mapping whether the fixmap region is big
+ enough for the mapping.
+ - It will fail if the fixmap is already in use. This is not a
+ change of behavior but clarifying the current expectation to avoid
+ hitting a BUG().
+
+The function __acpi_os_unmap_table() will now call clear_fixmap().
+
+Reported-by: Wei Xu <xuwei5 at hisilicon.com>
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 4d625ff3c3a939dc270b03654337568c30c5ab6e)
+---
+ xen/arch/arm/acpi/lib.c | 73 +++++++++++++++++++++++++++++++++++++------------
+ 1 file changed, 56 insertions(+), 17 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
+index fcc186b..a59cc40 100644
+--- a/xen/arch/arm/acpi/lib.c
++++ b/xen/arch/arm/acpi/lib.c
+@@ -25,40 +25,79 @@
+ #include <xen/init.h>
+ #include <xen/mm.h>
+
++static bool fixmap_inuse;
++
+ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ {
+- unsigned long base, offset, mapped_size;
+- int idx;
++ unsigned long base, offset;
++ mfn_t mfn;
++ unsigned int idx;
+
+ /* No arch specific implementation after early boot */
+ if ( system_state >= SYS_STATE_boot )
+ return NULL;
+
+ offset = phys & (PAGE_SIZE - 1);
+- mapped_size = PAGE_SIZE - offset;
+- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+- base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
++ base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) + offset;
++
++ /* Check the fixmap is big enough to map the region */
++ if ( (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - base) < size )
++ return NULL;
++
++ /* With the fixmap, we can only map one region at the time */
++ if ( fixmap_inuse )
++ return NULL;
+
+- /* Most cases can be covered by the below. */
++ fixmap_inuse = true;
++
++ size += offset;
++ mfn = maddr_to_mfn(phys);
+ idx = FIXMAP_ACPI_BEGIN;
+- while ( mapped_size < size )
+- {
+- if ( ++idx > FIXMAP_ACPI_END )
+- return NULL; /* cannot handle this */
+- phys += PAGE_SIZE;
+- set_fixmap(idx, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+- mapped_size += PAGE_SIZE;
+- }
+
+- return ((char *) base + offset);
++ do {
++ set_fixmap(idx, mfn, PAGE_HYPERVISOR);
++ size -= min(size, (unsigned long)PAGE_SIZE);
++ mfn = mfn_add(mfn, 1);
++ idx++;
++ } while ( size > 0 );
++
++ return (char *)base;
+ }
+
+ bool __acpi_unmap_table(const void *ptr, unsigned long size)
+ {
+ vaddr_t vaddr = (vaddr_t)ptr;
++ unsigned int idx;
++
++ /* We are only handling fixmap address in the arch code */
++ if ( (vaddr < FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) ||
++ (vaddr >= (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)) )
++ return false;
++
++ /*
++ * __acpi_map_table() will always return a pointer in the first page
++ * for the ACPI fixmap region. The caller is expected to free with
++ * the same address.
++ */
++ ASSERT((vaddr & PAGE_MASK) == FIXMAP_ADDR(FIXMAP_ACPI_BEGIN));
++
++ /* The region allocated fit in the ACPI fixmap region. */
++ ASSERT(size < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - vaddr));
++ ASSERT(fixmap_inuse);
++
++ fixmap_inuse = false;
++
++ size += vaddr - FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
++ idx = FIXMAP_ACPI_BEGIN;
++
++ do
++ {
++ clear_fixmap(idx);
++ size -= min(size, (unsigned long)PAGE_SIZE);
++ idx++;
++ } while ( size > 0 );
+
+- return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
+- (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
++ return true;
+ }
+
+ /* True to indicate PSCI 0.2+ is implemented */
diff -Nru
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
---
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,39 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 21:16:55 +0100
+Subject: xen/arm: Check if the platform is not using ACPI before initializing
+ Dom0less
+
+Dom0less requires a device-tree. However, since commit 6e3e77120378
+"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
+device-tree will not get unflatten when using ACPI.
+
+This will lead to a crash during boot.
+
+Given the complexity to setup dom0less with ACPI (for instance how to
+assign device?), we should skip any code related to Dom0less when using
+ACPI.
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Tested-by: Rahul Singh <rahul.singh at arm.com>
+Reviewed-by: Rahul Singh <rahul.singh at arm.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
+(cherry picked from commit dac867bf9adc1562a4cf9db5f89726597af13ef8)
+---
+ xen/arch/arm/setup.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
+index 34b1c1a..fb2f45e 100644
+--- a/xen/arch/arm/setup.c
++++ b/xen/arch/arm/setup.c
+@@ -961,7 +961,8 @@ void __init start_xen(unsigned long boot_phys_offset,
+ if ( construct_dom0(dom0) != 0)
+ panic("Could not set up DOM0 guest OS\n");
+
+- create_domUs();
++ if ( acpi_disabled )
++ create_domUs();
+
+ /*
+ * This needs to be called **before** heap_init_late() so modules
diff -Nru
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
---
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,124 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 21:30:14 +0100
+Subject: xen/arm: Introduce fw_unreserved_regions() and use it
+
+Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
+later on in the boot", the device-tree will not be kept mapped when
+using ACPI.
+
+However, a few places are calling dt_unreserved_regions() which expects
+a valid DT. This will lead to a crash.
+
+As the DT should not be used for ACPI (other than for detecting the
+modules), a new function fw_unreserved_regions() is introduced.
+
+It will behave the same way on DT system. On ACPI system, it will
+unreserve the whole region.
+
+Take the opportunity to clarify that bootinfo.reserved_mem is only used
+when booting using Device-Tree.
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0)
+---
+ xen/arch/arm/kernel.c | 2 +-
+ xen/arch/arm/setup.c | 22 +++++++++++++++++-----
+ xen/include/asm-arm/setup.h | 3 ++-
+ 3 files changed, 20 insertions(+), 7 deletions(-)
+
+diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
+index 8eff074..27dace0 100644
+--- a/xen/arch/arm/kernel.c
++++ b/xen/arch/arm/kernel.c
+@@ -307,7 +307,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
+ * Free the original kernel, update the pointers to the
+ * decompressed kernel
+ */
+- dt_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
++ fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+
+ return 0;
+ }
+diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
+index fb2f45e..c94827e 100644
+--- a/xen/arch/arm/setup.c
++++ b/xen/arch/arm/setup.c
+@@ -183,8 +183,9 @@ static void __init processor_id(void)
+ processor_setup();
+ }
+
+-void __init dt_unreserved_regions(paddr_t s, paddr_t e,
+- void (*cb)(paddr_t, paddr_t), int first)
++static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
++ void (*cb)(paddr_t, paddr_t),
++ int first)
+ {
+ int i, nr = fdt_num_mem_rsv(device_tree_flattened);
+
+@@ -231,6 +232,17 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
+ cb(s, e);
+ }
+
++void __init fw_unreserved_regions(paddr_t s, paddr_t e,
++ void (*cb)(paddr_t, paddr_t), int first)
++{
++ if ( acpi_disabled )
++ dt_unreserved_regions(s, e, cb, first);
++ else
++ cb(s, e);
++}
++
++
++
+ struct bootmodule __init *add_boot_module(bootmodule_kind kind,
+ paddr_t start, paddr_t size,
+ bool domU)
+@@ -392,7 +404,7 @@ void __init discard_initial_modules(void)
+ !mfn_valid(maddr_to_mfn(e)) )
+ continue;
+
+- dt_unreserved_regions(s, e, init_domheap_pages, 0);
++ fw_unreserved_regions(s, e, init_domheap_pages, 0);
+ }
+
+ mi->nr_mods = 0;
+@@ -699,7 +711,7 @@ static void __init setup_mm(void)
+ n = mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages));
+ }
+
+- dt_unreserved_regions(s, e, init_boot_pages, 0);
++ fw_unreserved_regions(s, e, init_boot_pages, 0);
+
+ s = n;
+ }
+@@ -752,7 +764,7 @@ static void __init setup_mm(void)
+ if ( e > bank_end )
+ e = bank_end;
+
+- dt_unreserved_regions(s, e, init_boot_pages, 0);
++ fw_unreserved_regions(s, e, init_boot_pages, 0);
+ s = n;
+ }
+ }
+diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
+index 2f8f24e..28bf622 100644
+--- a/xen/include/asm-arm/setup.h
++++ b/xen/include/asm-arm/setup.h
+@@ -67,6 +67,7 @@ struct bootcmdlines {
+
+ struct bootinfo {
+ struct meminfo mem;
++ /* The reserved regions are only used when booting using Device-Tree */
+ struct meminfo reserved_mem;
+ struct bootmodules modules;
+ struct bootcmdlines cmdlines;
+@@ -96,7 +97,7 @@ int construct_dom0(struct domain *d);
+ void create_domUs(void);
+
+ void discard_initial_modules(void);
+-void dt_unreserved_regions(paddr_t s, paddr_t e,
++void fw_unreserved_regions(paddr_t s, paddr_t e,
+ void (*cb)(paddr_t, paddr_t), int first);
+
+ size_t boot_fdt_info(const void *fdt, paddr_t paddr);
diff -Nru
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
---
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,60 @@
+From: Julien Grall <julien.grall at arm.com>
+Date: Wed, 30 Sep 2020 12:25:04 +0100
+Subject: xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro
+
+Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
+
+ The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
+ of the MADT. In the ACPI 5.1 version of the spec, the struct for the
+ GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
+ ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
+ in ACPICA for this struct -- and that is the 6.0 version. Hence, when
+ BAD_MADT_ENTRY() compares the struct size to the length in the GICC
+ subtable, it fails if 5.1 structs are in use, and there are systems in
+ the wild that have them.
+
+ This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
+ only, accounting for the difference in specification versions that are
+ possible. The BAD_MADT_ENTRY() will continue to work as is for all other
+ MADT subtables.
+
+ This code is being added to an arm64 header file since that is currently
+ the only architecture using the GICC subtable of the MADT. As a GIC is
+ specific to ARM, it is also unlikely the subtable will be used elsewhere.
+
+ Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT
table.")
+ Signed-off-by: Al Stone <al.stone at linaro.org>
+ Acked-by: Will Deacon <will.deacon at arm.com>
+ Acked-by: "Rafael J. Wysocki" <rjw at rjwysocki.net>
+ [catalin.marinas at arm.com: extra brackets around macro arguments]
+ Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
+
+Signed-off-by: Julien Grall <julien.grall at arm.com>
+Signed-off-by: Andre Przywara <andre.przywara at arm.com>
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Acked-by: Stefano Stabellini <sstabellini at kernel.org>
+Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
+(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
+---
+ xen/include/asm-arm/acpi.h | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
+index 5034028..b52ae2d 100644
+--- a/xen/include/asm-arm/acpi.h
++++ b/xen/include/asm-arm/acpi.h
+@@ -54,6 +54,14 @@ void acpi_smp_init_cpus(void);
+ */
+ paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
+
++/* Macros for consistency checks of the GICC subtable of MADT */
++#define ACPI_MADT_GICC_LENGTH \
++ (acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
++
++#define BAD_MADT_GICC_ENTRY(entry, end) \
++ (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \
++ (entry)->header.length != ACPI_MADT_GICC_LENGTH)
++
+ #ifdef CONFIG_ACPI
+ extern bool acpi_disabled;
+ /* Basic configuration for ACPI */
diff -Nru
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
---
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,29 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Thu, 5 Nov 2020 22:31:06 +0000
+Subject: xen/arm: traps: Don't panic when receiving an unknown debug trap
+
+Even if debug trap are only meant for debugging purpose, it is quite
+harsh to crash Xen if one of the trap sent by the guest is not handled.
+
+So switch from a panic() to a printk().
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 957708c2d1ae25d7375abd5e5e70c3043d64f1f1)
+---
+ xen/arch/arm/traps.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
+index 2197df2..22bd1bd 100644
+--- a/xen/arch/arm/traps.c
++++ b/xen/arch/arm/traps.c
+@@ -1411,7 +1411,7 @@ static void do_debug_trap(struct cpu_user_regs *regs,
unsigned int code)
+ show_execution_state(regs);
+ break;
+ default:
+- panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
++ printk("DOM%d: Unhandled debug trap %#x\n", domid, code);
+ break;
+ }
+ }
diff -Nru xen-4.14.3/debian/patches/series xen-4.14.3/debian/patches/series
--- xen-4.14.3/debian/patches/series 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/series 2021-09-26 22:23:21.000000000 -0400
@@ -24,15 +24,15 @@
0024-tools-don-t-build-ship-xenmon.patch
0025-tools-Partially-revert-Cross-compilation-fixes.patch
0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch
-0027-xen-rpi4-implement-watchdog-based-reset.patch
-0028-tools-python-Pass-linker-to-Python-build-process.patch
-0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
-0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
-0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
-0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
-0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
-0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
-0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
+rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
+rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
+rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
+rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
+rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
+rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
+rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
+rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
+rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
0036-fix-spelling-errors.patch
0037-xen-don-t-have-timestamp-inserted-in-config.gz.patch
0038-x86-EFI-don-t-insert-timestamp-when-SOURCE_DATE_EPOC.patch
diff -Nru xen-4.14.3/debian/rules xen-4.14.3/debian/rules
--- xen-4.14.3/debian/rules 2021-07-10 08:01:39.000000000 -0400
+++ xen-4.14.3/debian/rules 2021-09-26 17:11:21.000000000 -0400
@@ -176,9 +176,12 @@
# /bin/sh: 1: Syntax error: Unterminated quoted string
# probably because the CFLAGS value contains multiple options and
# therefore spaces. See also the note by `undefine CFLAGS', above.
+# Also, restore the RPI4 patches if they were disabled in the last build
override_dh_auto_clean:
rm -f debian/xen-tools-built.stamp
$(MAKE) -j1 distclean
+ quilt pop 14 && sed s/#rpi4/rpi4/ debian/patches/series >
series.tmp \
+ && mv series.tmp debian/patches/series && quilt push -a
# To avoid that the build dirties the tree, our delta queue deletes
# config.sub and config.guess. dh_update_autotools_config can get
@@ -213,6 +216,7 @@
--enable-ovmf --with-system-ovmf=/usr/share/ovmf/OVMF.fd \
--with-system-seabios=/usr/share/seabios/bios-256k.bin
+# To fix #994899, we disable the patches that support the RPI4 on amd64|i386
# tools/firmware/xen-dir is the `shim' used for booting PV guests
# in an HVM container, for security (particularly, for meltdown/spectre
# mitigation). It's actually a hypervisor. On i386 it is not built
@@ -221,6 +225,11 @@
# build it with $(make_args_xen) not $(make_args_tools). So do it
# separately.
override_dh_auto_build:
+ case $(flavour) in \
+ amd64|i386) \
+ quilt pop 14 && sed s/rpi4/#rpi4/ debian/patches/series >
series.tmp && \
+ mv series.tmp debian/patches/series && quilt push 5 ;; \
+ esac
$(MAKE) $(make_args_xen) xen
$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n
case $(flavour) in \
Chuck Zmudzinski
2021-Sep-27 12:20 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
A patch has been uploaded (message #55). For more information, see message #34.
Patch is attached. (An improved patch from the one in message #55)
changes from the patch in message #55: debian/rules: quilt pop 0026-...
instead of quilt pop 14
This ensures builds succeed when the number of patches in debian/patches
increases
Patch generated by: debdiff xen_4.14.3-1~deb11u1.dsc
xen_4.14.3-1~deb11u1.1.dsc > bug#994899.diff
What it does: Rebuilds the xen packages without the RPI4 patches on
amd64 and i386
Tested on: Native amd64 build
Fixes this bug on my amd64 system
Build Instructions:
Since the .pc directory is changed in the new package, we need quilt to
rebuild it correctly.
So the following commands should work to build the packages. Start in an
empty directory.
if [ ! -e /usr/bin/quilt ]; then sudo apt install quilt; fi
dget -x
https://snapshot.debian.org/archive/debian-security/20210920T191155Z/pool/updates/main/x/xen/xen_4.14.3-1~deb11u1.dsc
cd xen-4.14.3
dpkg-checkbuilddeps
quilt pop -a
cd ..
patch -p0 < bug#994899.diff
cd xen-4.14.3
quilt push -a
debuild -i -us -uc -b
To build the source package:
debuild -i -us -uc -S
-------------- next part --------------
diff -Nru xen-4.14.3/debian/changelog xen-4.14.3/debian/changelog
--- xen-4.14.3/debian/changelog 2021-09-13 10:28:21.000000000 -0400
+++ xen-4.14.3/debian/changelog 2021-09-27 11:51:02.000000000 -0400
@@ -1,3 +1,12 @@
+xen (4.14.3-1~deb11u1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches - move RPI4 patches into a separate directory
+ * debian/rules - disable RPI4 patches on amd64|i386 to fix #994899
+ * debian/control - add Build Dependency quilt
+
+ -- Chuck Zmudzinski <brchuckz at netscape.net> Mon, 27 Sep 2021
11:51:04 -0400
+
xen (4.14.3-1~deb11u1) bullseye-security; urgency=medium
* Rebuild for bullseye-security
diff -Nru xen-4.14.3/debian/control xen-4.14.3/debian/control
--- xen-4.14.3/debian/control 2021-07-10 08:01:39.000000000 -0400
+++ xen-4.14.3/debian/control 2021-09-26 22:21:51.000000000 -0400
@@ -34,6 +34,7 @@
markdown,
ocaml-native-compilers | ocaml-nox,
ocaml-findlib,
+ quilt,
Homepage: https://xenproject.org/
Vcs-Browser: https://salsa.debian.org/xen-team/debian-xen
Vcs-Git: https://salsa.debian.org/xen-team/debian-xen.git
diff -Nru
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
--- xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/0027-xen-rpi4-implement-watchdog-based-reset.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,105 +0,0 @@
-From: Stefano Stabellini <sstabellini at kernel.org>
-Date: Fri, 2 Oct 2020 13:47:17 -0700
-Subject: xen/rpi4: implement watchdog-based reset
-
-The preferred method to reboot RPi4 is PSCI. If it is not available,
-touching the watchdog is required to be able to reboot the board.
-
-The implementation is based on
-drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
-
-Signed-off-by: Stefano Stabellini <stefano.stabellini at xilinx.com>
-Acked-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Bertrand Marquis <bertrand.marquis at arm.com>
-Tested-by: Roman Shaposhnik <roman at zededa.com>
-CC: roman at zededa.com
-(cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9)
----
- xen/arch/arm/platforms/brcm-raspberry-pi.c | 61 ++++++++++++++++++++++++++++++
- 1 file changed, 61 insertions(+)
-
-diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-index f5ae58a..811b40b 100644
---- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
-+++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
-@@ -17,6 +17,10 @@
- * GNU General Public License for more details.
- */
-
-+#include <xen/delay.h>
-+#include <xen/mm.h>
-+#include <xen/vmap.h>
-+#include <asm/io.h>
- #include <asm/platform.h>
-
- static const char *const rpi4_dt_compat[] __initconst -@@ -37,12 +41,69 @@
static const struct dt_device_match rpi4_blacklist_dev[] __initconst - *
The aux peripheral also shares a page with the aux UART.
- */
- DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
-+ /* Special device used for rebooting */
-+ DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
- { /* sentinel */ },
- };
-
-+
-+#define PM_PASSWORD 0x5a000000
-+#define PM_RSTC 0x1c
-+#define PM_WDOG 0x24
-+#define PM_RSTC_WRCFG_FULL_RESET 0x00000020
-+#define PM_RSTC_WRCFG_CLR 0xffffffcf
-+
-+static void __iomem *rpi4_map_watchdog(void)
-+{
-+ void __iomem *base;
-+ struct dt_device_node *node;
-+ paddr_t start, len;
-+ int ret;
-+
-+ node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
-+ if ( !node )
-+ return NULL;
-+
-+ ret = dt_device_get_address(node, 0, &start, &len);
-+ if ( ret )
-+ {
-+ printk("Cannot read watchdog register address\n");
-+ return NULL;
-+ }
-+
-+ base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
-+ if ( !base )
-+ {
-+ printk("Unable to map watchdog register!\n");
-+ return NULL;
-+ }
-+
-+ return base;
-+}
-+
-+static void rpi4_reset(void)
-+{
-+ uint32_t val;
-+ void __iomem *base = rpi4_map_watchdog();
-+
-+ if ( !base )
-+ return;
-+
-+ /* use a timeout of 10 ticks (~150us) */
-+ writel(10 | PM_PASSWORD, base + PM_WDOG);
-+ val = readl(base + PM_RSTC);
-+ val &= PM_RSTC_WRCFG_CLR;
-+ val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
-+ writel(val, base + PM_RSTC);
-+
-+ /* No sleeping, possibly atomic. */
-+ mdelay(1);
-+}
-+
- PLATFORM_START(rpi4, "Raspberry Pi 4")
- .compatible = rpi4_dt_compat,
- .blacklist_dev = rpi4_blacklist_dev,
-+ .reset = rpi4_reset,
- .dma_bitsize = 30,
- PLATFORM_END
-
diff -Nru
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
---
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0028-tools-python-Pass-linker-to-Python-build-process.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,91 +0,0 @@
-From: Elliott Mitchell <ehem+xen at m5p.com>
-Date: Sun, 11 Oct 2020 18:11:39 -0700
-Subject: tools/python: Pass linker to Python build process
-MIME-Version: 1.0
-Content-Type: text/plain; charset="utf-8"
-Content-Transfer-Encoding: 8bit
-
-Unexpectedly the environment variable which needs to be passed is
-$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
-of the host `ld`.
-
-Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
-it can load at runtime, not executables.
-
-This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
-to $LDFLAGS which breaks many linkers.
-
-Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
-Acked-by: Marek Marczykowski-G?recki <marmarek at invisiblethingslab.com>
-(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
-
-[ Hans van Kranenburg ]
-Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
-between in the same lines. The line wrap mess makes it a bit hard to
-follow.
----
- tools/pygrub/Makefile | 11 ++++++-----
- tools/python/Makefile | 9 +++++----
- 2 files changed, 11 insertions(+), 9 deletions(-)
-
-diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
-index 4cd1a95..2950f37 100644
---- a/tools/pygrub/Makefile
-+++ b/tools/pygrub/Makefile
-@@ -3,21 +3,22 @@ XEN_ROOT = $(CURDIR)/../..
- include $(XEN_ROOT)/tools/Rules.mk
-
- PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
--PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
-+PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
- INSTALL_LOG = build/installed_files.txt
-
- .PHONY: all
- all: build
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py
build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" \
-+ LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
-
- .PHONY: install
- install: all
- $(INSTALL_DIR) $(DESTDIR)/$(bindir)
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" \
-- LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) \
-- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
-+ LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON)
setup.py install \
-+ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
- --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force
- set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \
- "`readlink -f $(DESTDIR)/$(bindir)`" != \
-diff --git a/tools/python/Makefile b/tools/python/Makefile
-index 8d22c03..b675f5b 100644
---- a/tools/python/Makefile
-+++ b/tools/python/Makefile
-@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
- all: build
-
- PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
--PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
-+PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
- INSTALL_LOG = build/installed_files.txt
-
- .PHONY: build
- build:
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py
build
-
- .PHONY: install
- install:
- $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-
-- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
-- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
-+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
-+ LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py install \
-+ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
- --root="$(DESTDIR)" --force
-
- $(INSTALL_PYTHON_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
diff -Nru
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
---
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,47 +0,0 @@
-From: Elliott Mitchell <ehem+xen at m5p.com>
-Date: Wed, 21 Oct 2020 15:12:53 -0700
-Subject: xen/arm: acpi: Don't fail if SPCR table is absent
-
-Absence of a SPCR table likely means the console is a framebuffer. In
-such case acpi_iomem_deny_access() should NOT fail.
-
-Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
-Acked-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 861f0c110976fa8879b7bf63d9478b6be83d4ab6)
----
- xen/arch/arm/acpi/domain_build.c | 19 ++++++++++---------
- 1 file changed, 10 insertions(+), 9 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/domain_build.c
b/xen/arch/arm/acpi/domain_build.c
-index 1b1cfab..bbdc90f 100644
---- a/xen/arch/arm/acpi/domain_build.c
-+++ b/xen/arch/arm/acpi/domain_build.c
-@@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain *d)
- status = acpi_get_table(ACPI_SIG_SPCR, 0,
- (struct acpi_table_header **)&spcr);
-
-- if ( ACPI_FAILURE(status) )
-+ if ( ACPI_SUCCESS(status) )
- {
-- printk("Failed to get SPCR table\n");
-- return -EINVAL;
-+ mfn = spcr->serial_port.address >> PAGE_SHIFT;
-+ /* Deny MMIO access for UART */
-+ rc = iomem_deny_access(d, mfn, mfn + 1);
-+ if ( rc )
-+ return rc;
-+ }
-+ else
-+ {
-+ printk("Failed to get SPCR table, Xen console may be
unavailable\n");
- }
--
-- mfn = spcr->serial_port.address >> PAGE_SHIFT;
-- /* Deny MMIO access for UART */
-- rc = iomem_deny_access(d, mfn, mfn + 1);
-- if ( rc )
-- return rc;
-
- /* Deny MMIO access for GIC regions */
- return gic_iomem_deny_access(d);
diff -Nru
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
---
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,163 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 17:44:29 +0100
-Subject: xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
-
-The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
-while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
-
-Currently, the former are still containing x86 specific code.
-
-To avoid this rather strange split, the generic helpers are reworked so
-they are arch-agnostic. This requires the introduction of a new helper
-__acpi_os_unmap_memory() that will undo any mapping done by
-__acpi_os_map_memory().
-
-Currently, the arch-helper for unmap is basically a no-op so it only
-returns whether the mapping was arch specific. But this will change
-in the future.
-
-Note that the x86 version of acpi_os_map_memory() was already able to
-able the 1MB region. Hence why there is no addition of new code.
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Rahul Singh <rahul.singh at arm.com>
-Reviewed-by: Jan Beulich <jbeulich at suse.com>
-Acked-by: Stefano Stabellini <sstabellini at kernel.org>
-Tested-by: Rahul Singh <rahul.singh at arm.com>
-Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
-(cherry picked from commit 1c4aa69ca1e1fad20b2158051eb152276d1eb973)
----
- xen/arch/arm/acpi/lib.c | 12 ++++++++++++
- xen/arch/x86/acpi/lib.c | 18 ++++++++++++++++++
- xen/drivers/acpi/osl.c | 34 ++++++++++++++++++----------------
- xen/include/xen/acpi.h | 1 +
- 4 files changed, 49 insertions(+), 16 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
-index 4fc6e17..fcc186b 100644
---- a/xen/arch/arm/acpi/lib.c
-+++ b/xen/arch/arm/acpi/lib.c
-@@ -30,6 +30,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- unsigned long base, offset, mapped_size;
- int idx;
-
-+ /* No arch specific implementation after early boot */
-+ if ( system_state >= SYS_STATE_boot )
-+ return NULL;
-+
- offset = phys & (PAGE_SIZE - 1);
- mapped_size = PAGE_SIZE - offset;
- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-@@ -49,6 +53,14 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- return ((char *) base + offset);
- }
-
-+bool __acpi_unmap_table(const void *ptr, unsigned long size)
-+{
-+ vaddr_t vaddr = (vaddr_t)ptr;
-+
-+ return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
-+ (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
-+}
-+
- /* True to indicate PSCI 0.2+ is implemented */
- bool __init acpi_psci_present(void)
- {
-diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
-index 265b9ad..a22414a 100644
---- a/xen/arch/x86/acpi/lib.c
-+++ b/xen/arch/x86/acpi/lib.c
-@@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- if ((phys + size) <= (1 * 1024 * 1024))
- return __va(phys);
-
-+ /* No further arch specific implementation after early boot */
-+ if (system_state >= SYS_STATE_boot)
-+ return NULL;
-+
- offset = phys & (PAGE_SIZE - 1);
- mapped_size = PAGE_SIZE - offset;
- set_fixmap(FIX_ACPI_END, phys);
-@@ -66,6 +70,20 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
- return ((char *) base + offset);
- }
-
-+bool __acpi_unmap_table(const void *ptr, unsigned long size)
-+{
-+ unsigned long vaddr = (unsigned long)ptr;
-+
-+ if ((vaddr >= DIRECTMAP_VIRT_START) &&
-+ (vaddr < DIRECTMAP_VIRT_END)) {
-+ ASSERT(!((__pa(ptr) + size - 1) >> 20));
-+ return true;
-+ }
-+
-+ return ((vaddr >= __fix_to_virt(FIX_ACPI_END)) &&
-+ (vaddr < (__fix_to_virt(FIX_ACPI_BEGIN) + PAGE_SIZE)));
-+}
-+
- unsigned int acpi_get_processor_id(unsigned int cpu)
- {
- unsigned int acpiid, apicid;
-diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
-index 4c8bb78..389505f 100644
---- a/xen/drivers/acpi/osl.c
-+++ b/xen/drivers/acpi/osl.c
-@@ -92,27 +92,29 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
- void __iomem *
- acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
- {
-- if (system_state >= SYS_STATE_boot) {
-- mfn_t mfn = _mfn(PFN_DOWN(phys));
-- unsigned int offs = phys & (PAGE_SIZE - 1);
--
-- /* The low first Mb is always mapped on x86. */
-- if (IS_ENABLED(CONFIG_X86) && !((phys + size - 1) >> 20))
-- return __va(phys);
-- return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-- ACPI_MAP_MEM_ATTR, VMAP_DEFAULT) + offs;
-- }
-- return __acpi_map_table(phys, size);
-+ void *ptr;
-+ mfn_t mfn = _mfn(PFN_DOWN(phys));
-+ unsigned int offs = PAGE_OFFSET(phys);
-+
-+ /* Try the arch specific implementation first */
-+ ptr = __acpi_map_table(phys, size);
-+ if (ptr)
-+ return ptr;
-+
-+ /* No common implementation for early boot map */
-+ if (unlikely(system_state < SYS_STATE_boot))
-+ return NULL;
-+
-+ ptr = __vmap(&mfn, PFN_UP(offs + size), 1, 1,
-+ ACPI_MAP_MEM_ATTR, VMAP_DEFAULT);
-+
-+ return !ptr ? NULL : (ptr + offs);
- }
-
- void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
- {
-- if (IS_ENABLED(CONFIG_X86) &&
-- (unsigned long)virt >= DIRECTMAP_VIRT_START &&
-- (unsigned long)virt < DIRECTMAP_VIRT_END) {
-- ASSERT(!((__pa(virt) + size - 1) >> 20));
-+ if (__acpi_unmap_table(virt, size))
- return;
-- }
-
- if (system_state >= SYS_STATE_boot)
- vunmap((void *)((unsigned long)virt & PAGE_MASK));
-diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
-index c945ab0..21d5e9f 100644
---- a/xen/include/xen/acpi.h
-+++ b/xen/include/xen/acpi.h
-@@ -68,6 +68,7 @@ typedef int (*acpi_table_entry_handler) (struct
acpi_subtable_header *header, co
-
- unsigned int acpi_get_processor_id (unsigned int cpu);
- char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
-+bool __acpi_unmap_table(const void *ptr, unsigned long size);
- int acpi_boot_init (void);
- int acpi_boot_table_init (void);
- int acpi_numa_init (void);
diff -Nru
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
---
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,131 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 19:53:27 +0100
-Subject: xen/arm: acpi: The fixmap area should always be cleared during
- failure/unmap
-
-Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
-{set, clear}_fixmap()" enforced that each set_fixmap() should be
-paired with a clear_fixmap(). Any failure to follow the model would
-result to a platform crash.
-
-Unfortunately, the use of fixmap in the ACPI code was overlooked as it
-is calling set_fixmap() but not clear_fixmap().
-
-The function __acpi_os_map_table() is reworked so:
- - We know before the mapping whether the fixmap region is big
- enough for the mapping.
- - It will fail if the fixmap is already in use. This is not a
- change of behavior but clarifying the current expectation to avoid
- hitting a BUG().
-
-The function __acpi_os_unmap_table() will now call clear_fixmap().
-
-Reported-by: Wei Xu <xuwei5 at hisilicon.com>
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 4d625ff3c3a939dc270b03654337568c30c5ab6e)
----
- xen/arch/arm/acpi/lib.c | 73 +++++++++++++++++++++++++++++++++++++------------
- 1 file changed, 56 insertions(+), 17 deletions(-)
-
-diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
-index fcc186b..a59cc40 100644
---- a/xen/arch/arm/acpi/lib.c
-+++ b/xen/arch/arm/acpi/lib.c
-@@ -25,40 +25,79 @@
- #include <xen/init.h>
- #include <xen/mm.h>
-
-+static bool fixmap_inuse;
-+
- char *__acpi_map_table(paddr_t phys, unsigned long size)
- {
-- unsigned long base, offset, mapped_size;
-- int idx;
-+ unsigned long base, offset;
-+ mfn_t mfn;
-+ unsigned int idx;
-
- /* No arch specific implementation after early boot */
- if ( system_state >= SYS_STATE_boot )
- return NULL;
-
- offset = phys & (PAGE_SIZE - 1);
-- mapped_size = PAGE_SIZE - offset;
-- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-- base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
-+ base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) + offset;
-+
-+ /* Check the fixmap is big enough to map the region */
-+ if ( (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - base) < size )
-+ return NULL;
-+
-+ /* With the fixmap, we can only map one region at the time */
-+ if ( fixmap_inuse )
-+ return NULL;
-
-- /* Most cases can be covered by the below. */
-+ fixmap_inuse = true;
-+
-+ size += offset;
-+ mfn = maddr_to_mfn(phys);
- idx = FIXMAP_ACPI_BEGIN;
-- while ( mapped_size < size )
-- {
-- if ( ++idx > FIXMAP_ACPI_END )
-- return NULL; /* cannot handle this */
-- phys += PAGE_SIZE;
-- set_fixmap(idx, maddr_to_mfn(phys), PAGE_HYPERVISOR);
-- mapped_size += PAGE_SIZE;
-- }
-
-- return ((char *) base + offset);
-+ do {
-+ set_fixmap(idx, mfn, PAGE_HYPERVISOR);
-+ size -= min(size, (unsigned long)PAGE_SIZE);
-+ mfn = mfn_add(mfn, 1);
-+ idx++;
-+ } while ( size > 0 );
-+
-+ return (char *)base;
- }
-
- bool __acpi_unmap_table(const void *ptr, unsigned long size)
- {
- vaddr_t vaddr = (vaddr_t)ptr;
-+ unsigned int idx;
-+
-+ /* We are only handling fixmap address in the arch code */
-+ if ( (vaddr < FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) ||
-+ (vaddr >= (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)) )
-+ return false;
-+
-+ /*
-+ * __acpi_map_table() will always return a pointer in the first page
-+ * for the ACPI fixmap region. The caller is expected to free with
-+ * the same address.
-+ */
-+ ASSERT((vaddr & PAGE_MASK) == FIXMAP_ADDR(FIXMAP_ACPI_BEGIN));
-+
-+ /* The region allocated fit in the ACPI fixmap region. */
-+ ASSERT(size < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - vaddr));
-+ ASSERT(fixmap_inuse);
-+
-+ fixmap_inuse = false;
-+
-+ size += vaddr - FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
-+ idx = FIXMAP_ACPI_BEGIN;
-+
-+ do
-+ {
-+ clear_fixmap(idx);
-+ size -= min(size, (unsigned long)PAGE_SIZE);
-+ idx++;
-+ } while ( size > 0 );
-
-- return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
-- (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
-+ return true;
- }
-
- /* True to indicate PSCI 0.2+ is implemented */
diff -Nru
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
---
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,39 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 21:16:55 +0100
-Subject: xen/arm: Check if the platform is not using ACPI before initializing
- Dom0less
-
-Dom0less requires a device-tree. However, since commit 6e3e77120378
-"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
-device-tree will not get unflatten when using ACPI.
-
-This will lead to a crash during boot.
-
-Given the complexity to setup dom0less with ACPI (for instance how to
-assign device?), we should skip any code related to Dom0less when using
-ACPI.
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Tested-by: Rahul Singh <rahul.singh at arm.com>
-Reviewed-by: Rahul Singh <rahul.singh at arm.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
-(cherry picked from commit dac867bf9adc1562a4cf9db5f89726597af13ef8)
----
- xen/arch/arm/setup.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
-index 34b1c1a..fb2f45e 100644
---- a/xen/arch/arm/setup.c
-+++ b/xen/arch/arm/setup.c
-@@ -961,7 +961,8 @@ void __init start_xen(unsigned long boot_phys_offset,
- if ( construct_dom0(dom0) != 0)
- panic("Could not set up DOM0 guest OS\n");
-
-- create_domUs();
-+ if ( acpi_disabled )
-+ create_domUs();
-
- /*
- * This needs to be called **before** heap_init_late() so modules
diff -Nru
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
---
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,124 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Sat, 26 Sep 2020 21:30:14 +0100
-Subject: xen/arm: Introduce fw_unreserved_regions() and use it
-
-Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
-later on in the boot", the device-tree will not be kept mapped when
-using ACPI.
-
-However, a few places are calling dt_unreserved_regions() which expects
-a valid DT. This will lead to a crash.
-
-As the DT should not be used for ACPI (other than for detecting the
-modules), a new function fw_unreserved_regions() is introduced.
-
-It will behave the same way on DT system. On ACPI system, it will
-unreserve the whole region.
-
-Take the opportunity to clarify that bootinfo.reserved_mem is only used
-when booting using Device-Tree.
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0)
----
- xen/arch/arm/kernel.c | 2 +-
- xen/arch/arm/setup.c | 22 +++++++++++++++++-----
- xen/include/asm-arm/setup.h | 3 ++-
- 3 files changed, 20 insertions(+), 7 deletions(-)
-
-diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
-index 8eff074..27dace0 100644
---- a/xen/arch/arm/kernel.c
-+++ b/xen/arch/arm/kernel.c
-@@ -307,7 +307,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
- * Free the original kernel, update the pointers to the
- * decompressed kernel
- */
-- dt_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-+ fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
-
- return 0;
- }
-diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
-index fb2f45e..c94827e 100644
---- a/xen/arch/arm/setup.c
-+++ b/xen/arch/arm/setup.c
-@@ -183,8 +183,9 @@ static void __init processor_id(void)
- processor_setup();
- }
-
--void __init dt_unreserved_regions(paddr_t s, paddr_t e,
-- void (*cb)(paddr_t, paddr_t), int first)
-+static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
-+ void (*cb)(paddr_t, paddr_t),
-+ int first)
- {
- int i, nr = fdt_num_mem_rsv(device_tree_flattened);
-
-@@ -231,6 +232,17 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
- cb(s, e);
- }
-
-+void __init fw_unreserved_regions(paddr_t s, paddr_t e,
-+ void (*cb)(paddr_t, paddr_t), int first)
-+{
-+ if ( acpi_disabled )
-+ dt_unreserved_regions(s, e, cb, first);
-+ else
-+ cb(s, e);
-+}
-+
-+
-+
- struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size,
- bool domU)
-@@ -392,7 +404,7 @@ void __init discard_initial_modules(void)
- !mfn_valid(maddr_to_mfn(e)) )
- continue;
-
-- dt_unreserved_regions(s, e, init_domheap_pages, 0);
-+ fw_unreserved_regions(s, e, init_domheap_pages, 0);
- }
-
- mi->nr_mods = 0;
-@@ -699,7 +711,7 @@ static void __init setup_mm(void)
- n = mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages));
- }
-
-- dt_unreserved_regions(s, e, init_boot_pages, 0);
-+ fw_unreserved_regions(s, e, init_boot_pages, 0);
-
- s = n;
- }
-@@ -752,7 +764,7 @@ static void __init setup_mm(void)
- if ( e > bank_end )
- e = bank_end;
-
-- dt_unreserved_regions(s, e, init_boot_pages, 0);
-+ fw_unreserved_regions(s, e, init_boot_pages, 0);
- s = n;
- }
- }
-diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
-index 2f8f24e..28bf622 100644
---- a/xen/include/asm-arm/setup.h
-+++ b/xen/include/asm-arm/setup.h
-@@ -67,6 +67,7 @@ struct bootcmdlines {
-
- struct bootinfo {
- struct meminfo mem;
-+ /* The reserved regions are only used when booting using Device-Tree */
- struct meminfo reserved_mem;
- struct bootmodules modules;
- struct bootcmdlines cmdlines;
-@@ -96,7 +97,7 @@ int construct_dom0(struct domain *d);
- void create_domUs(void);
-
- void discard_initial_modules(void);
--void dt_unreserved_regions(paddr_t s, paddr_t e,
-+void fw_unreserved_regions(paddr_t s, paddr_t e,
- void (*cb)(paddr_t, paddr_t), int first);
-
- size_t boot_fdt_info(const void *fdt, paddr_t paddr);
diff -Nru
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
---
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,60 +0,0 @@
-From: Julien Grall <julien.grall at arm.com>
-Date: Wed, 30 Sep 2020 12:25:04 +0100
-Subject: xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro
-
-Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
-
- The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
- of the MADT. In the ACPI 5.1 version of the spec, the struct for the
- GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
- ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
- in ACPICA for this struct -- and that is the 6.0 version. Hence, when
- BAD_MADT_ENTRY() compares the struct size to the length in the GICC
- subtable, it fails if 5.1 structs are in use, and there are systems in
- the wild that have them.
-
- This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
- only, accounting for the difference in specification versions that are
- possible. The BAD_MADT_ENTRY() will continue to work as is for all other
- MADT subtables.
-
- This code is being added to an arm64 header file since that is currently
- the only architecture using the GICC subtable of the MADT. As a GIC is
- specific to ARM, it is also unlikely the subtable will be used elsewhere.
-
- Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT
table.")
- Signed-off-by: Al Stone <al.stone at linaro.org>
- Acked-by: Will Deacon <will.deacon at arm.com>
- Acked-by: "Rafael J. Wysocki" <rjw at rjwysocki.net>
- [catalin.marinas at arm.com: extra brackets around macro arguments]
- Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
-
-Signed-off-by: Julien Grall <julien.grall at arm.com>
-Signed-off-by: Andre Przywara <andre.przywara at arm.com>
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Acked-by: Stefano Stabellini <sstabellini at kernel.org>
-Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
-(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
----
- xen/include/asm-arm/acpi.h | 8 ++++++++
- 1 file changed, 8 insertions(+)
-
-diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
-index 5034028..b52ae2d 100644
---- a/xen/include/asm-arm/acpi.h
-+++ b/xen/include/asm-arm/acpi.h
-@@ -54,6 +54,14 @@ void acpi_smp_init_cpus(void);
- */
- paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
-
-+/* Macros for consistency checks of the GICC subtable of MADT */
-+#define ACPI_MADT_GICC_LENGTH \
-+ (acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
-+
-+#define BAD_MADT_GICC_ENTRY(entry, end) \
-+ (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \
-+ (entry)->header.length != ACPI_MADT_GICC_LENGTH)
-+
- #ifdef CONFIG_ACPI
- extern bool acpi_disabled;
- /* Basic configuration for ACPI */
diff -Nru
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
---
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
2021-09-13 10:25:25.000000000 -0400
+++
xen-4.14.3/debian/patches/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
1969-12-31 19:00:00.000000000 -0500
@@ -1,29 +0,0 @@
-From: Julien Grall <jgrall at amazon.com>
-Date: Thu, 5 Nov 2020 22:31:06 +0000
-Subject: xen/arm: traps: Don't panic when receiving an unknown debug trap
-
-Even if debug trap are only meant for debugging purpose, it is quite
-harsh to crash Xen if one of the trap sent by the guest is not handled.
-
-So switch from a panic() to a printk().
-
-Signed-off-by: Julien Grall <jgrall at amazon.com>
-Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
-(cherry picked from commit 957708c2d1ae25d7375abd5e5e70c3043d64f1f1)
----
- xen/arch/arm/traps.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
-index 2197df2..22bd1bd 100644
---- a/xen/arch/arm/traps.c
-+++ b/xen/arch/arm/traps.c
-@@ -1411,7 +1411,7 @@ static void do_debug_trap(struct cpu_user_regs *regs,
unsigned int code)
- show_execution_state(regs);
- break;
- default:
-- panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
-+ printk("DOM%d: Unhandled debug trap %#x\n", domid, code);
- break;
- }
- }
diff -Nru
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
---
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,105 @@
+From: Stefano Stabellini <sstabellini at kernel.org>
+Date: Fri, 2 Oct 2020 13:47:17 -0700
+Subject: xen/rpi4: implement watchdog-based reset
+
+The preferred method to reboot RPi4 is PSCI. If it is not available,
+touching the watchdog is required to be able to reboot the board.
+
+The implementation is based on
+drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
+
+Signed-off-by: Stefano Stabellini <stefano.stabellini at xilinx.com>
+Acked-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Bertrand Marquis <bertrand.marquis at arm.com>
+Tested-by: Roman Shaposhnik <roman at zededa.com>
+CC: roman at zededa.com
+(cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9)
+---
+ xen/arch/arm/platforms/brcm-raspberry-pi.c | 61 ++++++++++++++++++++++++++++++
+ 1 file changed, 61 insertions(+)
+
+diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
+index f5ae58a..811b40b 100644
+--- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
++++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
+@@ -17,6 +17,10 @@
+ * GNU General Public License for more details.
+ */
+
++#include <xen/delay.h>
++#include <xen/mm.h>
++#include <xen/vmap.h>
++#include <asm/io.h>
+ #include <asm/platform.h>
+
+ static const char *const rpi4_dt_compat[] __initconst +@@ -37,12 +41,69 @@
static const struct dt_device_match rpi4_blacklist_dev[] __initconst + *
The aux peripheral also shares a page with the aux UART.
+ */
+ DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
++ /* Special device used for rebooting */
++ DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
+ { /* sentinel */ },
+ };
+
++
++#define PM_PASSWORD 0x5a000000
++#define PM_RSTC 0x1c
++#define PM_WDOG 0x24
++#define PM_RSTC_WRCFG_FULL_RESET 0x00000020
++#define PM_RSTC_WRCFG_CLR 0xffffffcf
++
++static void __iomem *rpi4_map_watchdog(void)
++{
++ void __iomem *base;
++ struct dt_device_node *node;
++ paddr_t start, len;
++ int ret;
++
++ node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
++ if ( !node )
++ return NULL;
++
++ ret = dt_device_get_address(node, 0, &start, &len);
++ if ( ret )
++ {
++ printk("Cannot read watchdog register address\n");
++ return NULL;
++ }
++
++ base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
++ if ( !base )
++ {
++ printk("Unable to map watchdog register!\n");
++ return NULL;
++ }
++
++ return base;
++}
++
++static void rpi4_reset(void)
++{
++ uint32_t val;
++ void __iomem *base = rpi4_map_watchdog();
++
++ if ( !base )
++ return;
++
++ /* use a timeout of 10 ticks (~150us) */
++ writel(10 | PM_PASSWORD, base + PM_WDOG);
++ val = readl(base + PM_RSTC);
++ val &= PM_RSTC_WRCFG_CLR;
++ val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
++ writel(val, base + PM_RSTC);
++
++ /* No sleeping, possibly atomic. */
++ mdelay(1);
++}
++
+ PLATFORM_START(rpi4, "Raspberry Pi 4")
+ .compatible = rpi4_dt_compat,
+ .blacklist_dev = rpi4_blacklist_dev,
++ .reset = rpi4_reset,
+ .dma_bitsize = 30,
+ PLATFORM_END
+
diff -Nru
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
---
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,91 @@
+From: Elliott Mitchell <ehem+xen at m5p.com>
+Date: Sun, 11 Oct 2020 18:11:39 -0700
+Subject: tools/python: Pass linker to Python build process
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Unexpectedly the environment variable which needs to be passed is
+$LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
+of the host `ld`.
+
+Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects
+it can load at runtime, not executables.
+
+This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS
+to $LDFLAGS which breaks many linkers.
+
+Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
+Acked-by: Marek Marczykowski-G?recki <marmarek at invisiblethingslab.com>
+(cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38)
+
+[ Hans van Kranenburg ]
+Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in
+between in the same lines. The line wrap mess makes it a bit hard to
+follow.
+---
+ tools/pygrub/Makefile | 11 ++++++-----
+ tools/python/Makefile | 9 +++++----
+ 2 files changed, 11 insertions(+), 9 deletions(-)
+
+diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile
+index 4cd1a95..2950f37 100644
+--- a/tools/pygrub/Makefile
++++ b/tools/pygrub/Makefile
+@@ -3,21 +3,22 @@ XEN_ROOT = $(CURDIR)/../..
+ include $(XEN_ROOT)/tools/Rules.mk
+
+ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
+-PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
++PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
+ INSTALL_LOG = build/installed_files.txt
+
+ .PHONY: all
+ all: build
+ .PHONY: build
+ build:
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py
build
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" \
++ LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) setup.py build
+
+ .PHONY: install
+ install: all
+ $(INSTALL_DIR) $(DESTDIR)/$(bindir)
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" \
+- LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON) \
+- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
++ LDFLAGS="$(PY_LDFLAGS)" LIBEXEC_LIB=$(LIBEXEC_LIB) $(PYTHON)
setup.py install \
++ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
+ --root="$(DESTDIR)" --install-scripts=$(LIBEXEC_BIN) --force
+ set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \
+ "`readlink -f $(DESTDIR)/$(bindir)`" != \
+diff --git a/tools/python/Makefile b/tools/python/Makefile
+index 8d22c03..b675f5b 100644
+--- a/tools/python/Makefile
++++ b/tools/python/Makefile
+@@ -5,19 +5,20 @@ include $(XEN_ROOT)/tools/Rules.mk
+ all: build
+
+ PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
+-PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
++PY_LDFLAGS = $(SHLIB_LDFLAGS) $(APPEND_LDFLAGS)
+ INSTALL_LOG = build/installed_files.txt
+
+ .PHONY: build
+ build:
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py
build
+
+ .PHONY: install
+ install:
+ $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
+
+- CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
+- setup.py install --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
++ CC="$(CC)" CFLAGS="$(PY_CFLAGS)"
LDSHARED="$(CC)" \
++ LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py install \
++ --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \
+ --root="$(DESTDIR)" --force
+
+ $(INSTALL_PYTHON_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
diff -Nru
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
---
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,47 @@
+From: Elliott Mitchell <ehem+xen at m5p.com>
+Date: Wed, 21 Oct 2020 15:12:53 -0700
+Subject: xen/arm: acpi: Don't fail if SPCR table is absent
+
+Absence of a SPCR table likely means the console is a framebuffer. In
+such case acpi_iomem_deny_access() should NOT fail.
+
+Signed-off-by: Elliott Mitchell <ehem+xen at m5p.com>
+Acked-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 861f0c110976fa8879b7bf63d9478b6be83d4ab6)
+---
+ xen/arch/arm/acpi/domain_build.c | 19 ++++++++++---------
+ 1 file changed, 10 insertions(+), 9 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/domain_build.c
b/xen/arch/arm/acpi/domain_build.c
+index 1b1cfab..bbdc90f 100644
+--- a/xen/arch/arm/acpi/domain_build.c
++++ b/xen/arch/arm/acpi/domain_build.c
+@@ -42,17 +42,18 @@ static int __init acpi_iomem_deny_access(struct domain *d)
+ status = acpi_get_table(ACPI_SIG_SPCR, 0,
+ (struct acpi_table_header **)&spcr);
+
+- if ( ACPI_FAILURE(status) )
++ if ( ACPI_SUCCESS(status) )
+ {
+- printk("Failed to get SPCR table\n");
+- return -EINVAL;
++ mfn = spcr->serial_port.address >> PAGE_SHIFT;
++ /* Deny MMIO access for UART */
++ rc = iomem_deny_access(d, mfn, mfn + 1);
++ if ( rc )
++ return rc;
++ }
++ else
++ {
++ printk("Failed to get SPCR table, Xen console may be
unavailable\n");
+ }
+-
+- mfn = spcr->serial_port.address >> PAGE_SHIFT;
+- /* Deny MMIO access for UART */
+- rc = iomem_deny_access(d, mfn, mfn + 1);
+- if ( rc )
+- return rc;
+
+ /* Deny MMIO access for GIC regions */
+ return gic_iomem_deny_access(d);
diff -Nru
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
---
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,163 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 17:44:29 +0100
+Subject: xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory()
+
+The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
+while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
+
+Currently, the former are still containing x86 specific code.
+
+To avoid this rather strange split, the generic helpers are reworked so
+they are arch-agnostic. This requires the introduction of a new helper
+__acpi_os_unmap_memory() that will undo any mapping done by
+__acpi_os_map_memory().
+
+Currently, the arch-helper for unmap is basically a no-op so it only
+returns whether the mapping was arch specific. But this will change
+in the future.
+
+Note that the x86 version of acpi_os_map_memory() was already able to
+able the 1MB region. Hence why there is no addition of new code.
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Rahul Singh <rahul.singh at arm.com>
+Reviewed-by: Jan Beulich <jbeulich at suse.com>
+Acked-by: Stefano Stabellini <sstabellini at kernel.org>
+Tested-by: Rahul Singh <rahul.singh at arm.com>
+Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
+(cherry picked from commit 1c4aa69ca1e1fad20b2158051eb152276d1eb973)
+---
+ xen/arch/arm/acpi/lib.c | 12 ++++++++++++
+ xen/arch/x86/acpi/lib.c | 18 ++++++++++++++++++
+ xen/drivers/acpi/osl.c | 34 ++++++++++++++++++----------------
+ xen/include/xen/acpi.h | 1 +
+ 4 files changed, 49 insertions(+), 16 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
+index 4fc6e17..fcc186b 100644
+--- a/xen/arch/arm/acpi/lib.c
++++ b/xen/arch/arm/acpi/lib.c
+@@ -30,6 +30,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ unsigned long base, offset, mapped_size;
+ int idx;
+
++ /* No arch specific implementation after early boot */
++ if ( system_state >= SYS_STATE_boot )
++ return NULL;
++
+ offset = phys & (PAGE_SIZE - 1);
+ mapped_size = PAGE_SIZE - offset;
+ set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+@@ -49,6 +53,14 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ return ((char *) base + offset);
+ }
+
++bool __acpi_unmap_table(const void *ptr, unsigned long size)
++{
++ vaddr_t vaddr = (vaddr_t)ptr;
++
++ return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
++ (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
++}
++
+ /* True to indicate PSCI 0.2+ is implemented */
+ bool __init acpi_psci_present(void)
+ {
+diff --git a/xen/arch/x86/acpi/lib.c b/xen/arch/x86/acpi/lib.c
+index 265b9ad..a22414a 100644
+--- a/xen/arch/x86/acpi/lib.c
++++ b/xen/arch/x86/acpi/lib.c
+@@ -46,6 +46,10 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ if ((phys + size) <= (1 * 1024 * 1024))
+ return __va(phys);
+
++ /* No further arch specific implementation after early boot */
++ if (system_state >= SYS_STATE_boot)
++ return NULL;
++
+ offset = phys & (PAGE_SIZE - 1);
+ mapped_size = PAGE_SIZE - offset;
+ set_fixmap(FIX_ACPI_END, phys);
+@@ -66,6 +70,20 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ return ((char *) base + offset);
+ }
+
++bool __acpi_unmap_table(const void *ptr, unsigned long size)
++{
++ unsigned long vaddr = (unsigned long)ptr;
++
++ if ((vaddr >= DIRECTMAP_VIRT_START) &&
++ (vaddr < DIRECTMAP_VIRT_END)) {
++ ASSERT(!((__pa(ptr) + size - 1) >> 20));
++ return true;
++ }
++
++ return ((vaddr >= __fix_to_virt(FIX_ACPI_END)) &&
++ (vaddr < (__fix_to_virt(FIX_ACPI_BEGIN) + PAGE_SIZE)));
++}
++
+ unsigned int acpi_get_processor_id(unsigned int cpu)
+ {
+ unsigned int acpiid, apicid;
+diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
+index 4c8bb78..389505f 100644
+--- a/xen/drivers/acpi/osl.c
++++ b/xen/drivers/acpi/osl.c
+@@ -92,27 +92,29 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
+ void __iomem *
+ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
+ {
+- if (system_state >= SYS_STATE_boot) {
+- mfn_t mfn = _mfn(PFN_DOWN(phys));
+- unsigned int offs = phys & (PAGE_SIZE - 1);
+-
+- /* The low first Mb is always mapped on x86. */
+- if (IS_ENABLED(CONFIG_X86) && !((phys + size - 1) >> 20))
+- return __va(phys);
+- return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
+- ACPI_MAP_MEM_ATTR, VMAP_DEFAULT) + offs;
+- }
+- return __acpi_map_table(phys, size);
++ void *ptr;
++ mfn_t mfn = _mfn(PFN_DOWN(phys));
++ unsigned int offs = PAGE_OFFSET(phys);
++
++ /* Try the arch specific implementation first */
++ ptr = __acpi_map_table(phys, size);
++ if (ptr)
++ return ptr;
++
++ /* No common implementation for early boot map */
++ if (unlikely(system_state < SYS_STATE_boot))
++ return NULL;
++
++ ptr = __vmap(&mfn, PFN_UP(offs + size), 1, 1,
++ ACPI_MAP_MEM_ATTR, VMAP_DEFAULT);
++
++ return !ptr ? NULL : (ptr + offs);
+ }
+
+ void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
+ {
+- if (IS_ENABLED(CONFIG_X86) &&
+- (unsigned long)virt >= DIRECTMAP_VIRT_START &&
+- (unsigned long)virt < DIRECTMAP_VIRT_END) {
+- ASSERT(!((__pa(virt) + size - 1) >> 20));
++ if (__acpi_unmap_table(virt, size))
+ return;
+- }
+
+ if (system_state >= SYS_STATE_boot)
+ vunmap((void *)((unsigned long)virt & PAGE_MASK));
+diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
+index c945ab0..21d5e9f 100644
+--- a/xen/include/xen/acpi.h
++++ b/xen/include/xen/acpi.h
+@@ -68,6 +68,7 @@ typedef int (*acpi_table_entry_handler) (struct
acpi_subtable_header *header, co
+
+ unsigned int acpi_get_processor_id (unsigned int cpu);
+ char * __acpi_map_table (paddr_t phys_addr, unsigned long size);
++bool __acpi_unmap_table(const void *ptr, unsigned long size);
+ int acpi_boot_init (void);
+ int acpi_boot_table_init (void);
+ int acpi_numa_init (void);
diff -Nru
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
---
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,131 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 19:53:27 +0100
+Subject: xen/arm: acpi: The fixmap area should always be cleared during
+ failure/unmap
+
+Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
+{set, clear}_fixmap()" enforced that each set_fixmap() should be
+paired with a clear_fixmap(). Any failure to follow the model would
+result to a platform crash.
+
+Unfortunately, the use of fixmap in the ACPI code was overlooked as it
+is calling set_fixmap() but not clear_fixmap().
+
+The function __acpi_os_map_table() is reworked so:
+ - We know before the mapping whether the fixmap region is big
+ enough for the mapping.
+ - It will fail if the fixmap is already in use. This is not a
+ change of behavior but clarifying the current expectation to avoid
+ hitting a BUG().
+
+The function __acpi_os_unmap_table() will now call clear_fixmap().
+
+Reported-by: Wei Xu <xuwei5 at hisilicon.com>
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 4d625ff3c3a939dc270b03654337568c30c5ab6e)
+---
+ xen/arch/arm/acpi/lib.c | 73 +++++++++++++++++++++++++++++++++++++------------
+ 1 file changed, 56 insertions(+), 17 deletions(-)
+
+diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
+index fcc186b..a59cc40 100644
+--- a/xen/arch/arm/acpi/lib.c
++++ b/xen/arch/arm/acpi/lib.c
+@@ -25,40 +25,79 @@
+ #include <xen/init.h>
+ #include <xen/mm.h>
+
++static bool fixmap_inuse;
++
+ char *__acpi_map_table(paddr_t phys, unsigned long size)
+ {
+- unsigned long base, offset, mapped_size;
+- int idx;
++ unsigned long base, offset;
++ mfn_t mfn;
++ unsigned int idx;
+
+ /* No arch specific implementation after early boot */
+ if ( system_state >= SYS_STATE_boot )
+ return NULL;
+
+ offset = phys & (PAGE_SIZE - 1);
+- mapped_size = PAGE_SIZE - offset;
+- set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+- base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
++ base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) + offset;
++
++ /* Check the fixmap is big enough to map the region */
++ if ( (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - base) < size )
++ return NULL;
++
++ /* With the fixmap, we can only map one region at the time */
++ if ( fixmap_inuse )
++ return NULL;
+
+- /* Most cases can be covered by the below. */
++ fixmap_inuse = true;
++
++ size += offset;
++ mfn = maddr_to_mfn(phys);
+ idx = FIXMAP_ACPI_BEGIN;
+- while ( mapped_size < size )
+- {
+- if ( ++idx > FIXMAP_ACPI_END )
+- return NULL; /* cannot handle this */
+- phys += PAGE_SIZE;
+- set_fixmap(idx, maddr_to_mfn(phys), PAGE_HYPERVISOR);
+- mapped_size += PAGE_SIZE;
+- }
+
+- return ((char *) base + offset);
++ do {
++ set_fixmap(idx, mfn, PAGE_HYPERVISOR);
++ size -= min(size, (unsigned long)PAGE_SIZE);
++ mfn = mfn_add(mfn, 1);
++ idx++;
++ } while ( size > 0 );
++
++ return (char *)base;
+ }
+
+ bool __acpi_unmap_table(const void *ptr, unsigned long size)
+ {
+ vaddr_t vaddr = (vaddr_t)ptr;
++ unsigned int idx;
++
++ /* We are only handling fixmap address in the arch code */
++ if ( (vaddr < FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) ||
++ (vaddr >= (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)) )
++ return false;
++
++ /*
++ * __acpi_map_table() will always return a pointer in the first page
++ * for the ACPI fixmap region. The caller is expected to free with
++ * the same address.
++ */
++ ASSERT((vaddr & PAGE_MASK) == FIXMAP_ADDR(FIXMAP_ACPI_BEGIN));
++
++ /* The region allocated fit in the ACPI fixmap region. */
++ ASSERT(size < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - vaddr));
++ ASSERT(fixmap_inuse);
++
++ fixmap_inuse = false;
++
++ size += vaddr - FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
++ idx = FIXMAP_ACPI_BEGIN;
++
++ do
++ {
++ clear_fixmap(idx);
++ size -= min(size, (unsigned long)PAGE_SIZE);
++ idx++;
++ } while ( size > 0 );
+
+- return ((vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN)) &&
+- (vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE)));
++ return true;
+ }
+
+ /* True to indicate PSCI 0.2+ is implemented */
diff -Nru
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
---
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,39 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 21:16:55 +0100
+Subject: xen/arm: Check if the platform is not using ACPI before initializing
+ Dom0less
+
+Dom0less requires a device-tree. However, since commit 6e3e77120378
+"xen/arm: setup: Relocate the Device-Tree later on in the boot", the
+device-tree will not get unflatten when using ACPI.
+
+This will lead to a crash during boot.
+
+Given the complexity to setup dom0less with ACPI (for instance how to
+assign device?), we should skip any code related to Dom0less when using
+ACPI.
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Tested-by: Rahul Singh <rahul.singh at arm.com>
+Reviewed-by: Rahul Singh <rahul.singh at arm.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
+(cherry picked from commit dac867bf9adc1562a4cf9db5f89726597af13ef8)
+---
+ xen/arch/arm/setup.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
+index 34b1c1a..fb2f45e 100644
+--- a/xen/arch/arm/setup.c
++++ b/xen/arch/arm/setup.c
+@@ -961,7 +961,8 @@ void __init start_xen(unsigned long boot_phys_offset,
+ if ( construct_dom0(dom0) != 0)
+ panic("Could not set up DOM0 guest OS\n");
+
+- create_domUs();
++ if ( acpi_disabled )
++ create_domUs();
+
+ /*
+ * This needs to be called **before** heap_init_late() so modules
diff -Nru
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
---
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,124 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Sat, 26 Sep 2020 21:30:14 +0100
+Subject: xen/arm: Introduce fw_unreserved_regions() and use it
+
+Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree
+later on in the boot", the device-tree will not be kept mapped when
+using ACPI.
+
+However, a few places are calling dt_unreserved_regions() which expects
+a valid DT. This will lead to a crash.
+
+As the DT should not be used for ACPI (other than for detecting the
+modules), a new function fw_unreserved_regions() is introduced.
+
+It will behave the same way on DT system. On ACPI system, it will
+unreserve the whole region.
+
+Take the opportunity to clarify that bootinfo.reserved_mem is only used
+when booting using Device-Tree.
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0)
+---
+ xen/arch/arm/kernel.c | 2 +-
+ xen/arch/arm/setup.c | 22 +++++++++++++++++-----
+ xen/include/asm-arm/setup.h | 3 ++-
+ 3 files changed, 20 insertions(+), 7 deletions(-)
+
+diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
+index 8eff074..27dace0 100644
+--- a/xen/arch/arm/kernel.c
++++ b/xen/arch/arm/kernel.c
+@@ -307,7 +307,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
+ * Free the original kernel, update the pointers to the
+ * decompressed kernel
+ */
+- dt_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
++ fw_unreserved_regions(addr, addr + size, init_domheap_pages, 0);
+
+ return 0;
+ }
+diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
+index fb2f45e..c94827e 100644
+--- a/xen/arch/arm/setup.c
++++ b/xen/arch/arm/setup.c
+@@ -183,8 +183,9 @@ static void __init processor_id(void)
+ processor_setup();
+ }
+
+-void __init dt_unreserved_regions(paddr_t s, paddr_t e,
+- void (*cb)(paddr_t, paddr_t), int first)
++static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
++ void (*cb)(paddr_t, paddr_t),
++ int first)
+ {
+ int i, nr = fdt_num_mem_rsv(device_tree_flattened);
+
+@@ -231,6 +232,17 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
+ cb(s, e);
+ }
+
++void __init fw_unreserved_regions(paddr_t s, paddr_t e,
++ void (*cb)(paddr_t, paddr_t), int first)
++{
++ if ( acpi_disabled )
++ dt_unreserved_regions(s, e, cb, first);
++ else
++ cb(s, e);
++}
++
++
++
+ struct bootmodule __init *add_boot_module(bootmodule_kind kind,
+ paddr_t start, paddr_t size,
+ bool domU)
+@@ -392,7 +404,7 @@ void __init discard_initial_modules(void)
+ !mfn_valid(maddr_to_mfn(e)) )
+ continue;
+
+- dt_unreserved_regions(s, e, init_domheap_pages, 0);
++ fw_unreserved_regions(s, e, init_domheap_pages, 0);
+ }
+
+ mi->nr_mods = 0;
+@@ -699,7 +711,7 @@ static void __init setup_mm(void)
+ n = mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages));
+ }
+
+- dt_unreserved_regions(s, e, init_boot_pages, 0);
++ fw_unreserved_regions(s, e, init_boot_pages, 0);
+
+ s = n;
+ }
+@@ -752,7 +764,7 @@ static void __init setup_mm(void)
+ if ( e > bank_end )
+ e = bank_end;
+
+- dt_unreserved_regions(s, e, init_boot_pages, 0);
++ fw_unreserved_regions(s, e, init_boot_pages, 0);
+ s = n;
+ }
+ }
+diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
+index 2f8f24e..28bf622 100644
+--- a/xen/include/asm-arm/setup.h
++++ b/xen/include/asm-arm/setup.h
+@@ -67,6 +67,7 @@ struct bootcmdlines {
+
+ struct bootinfo {
+ struct meminfo mem;
++ /* The reserved regions are only used when booting using Device-Tree */
+ struct meminfo reserved_mem;
+ struct bootmodules modules;
+ struct bootcmdlines cmdlines;
+@@ -96,7 +97,7 @@ int construct_dom0(struct domain *d);
+ void create_domUs(void);
+
+ void discard_initial_modules(void);
+-void dt_unreserved_regions(paddr_t s, paddr_t e,
++void fw_unreserved_regions(paddr_t s, paddr_t e,
+ void (*cb)(paddr_t, paddr_t), int first);
+
+ size_t boot_fdt_info(const void *fdt, paddr_t paddr);
diff -Nru
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
---
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,60 @@
+From: Julien Grall <julien.grall at arm.com>
+Date: Wed, 30 Sep 2020 12:25:04 +0100
+Subject: xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro
+
+Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6:
+
+ The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
+ of the MADT. In the ACPI 5.1 version of the spec, the struct for the
+ GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
+ ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
+ in ACPICA for this struct -- and that is the 6.0 version. Hence, when
+ BAD_MADT_ENTRY() compares the struct size to the length in the GICC
+ subtable, it fails if 5.1 structs are in use, and there are systems in
+ the wild that have them.
+
+ This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
+ only, accounting for the difference in specification versions that are
+ possible. The BAD_MADT_ENTRY() will continue to work as is for all other
+ MADT subtables.
+
+ This code is being added to an arm64 header file since that is currently
+ the only architecture using the GICC subtable of the MADT. As a GIC is
+ specific to ARM, it is also unlikely the subtable will be used elsewhere.
+
+ Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT
table.")
+ Signed-off-by: Al Stone <al.stone at linaro.org>
+ Acked-by: Will Deacon <will.deacon at arm.com>
+ Acked-by: "Rafael J. Wysocki" <rjw at rjwysocki.net>
+ [catalin.marinas at arm.com: extra brackets around macro arguments]
+ Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
+
+Signed-off-by: Julien Grall <julien.grall at arm.com>
+Signed-off-by: Andre Przywara <andre.przywara at arm.com>
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Acked-by: Stefano Stabellini <sstabellini at kernel.org>
+Tested-by: Elliott Mitchell <ehem+xen at m5p.com>
+(cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd)
+---
+ xen/include/asm-arm/acpi.h | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
+index 5034028..b52ae2d 100644
+--- a/xen/include/asm-arm/acpi.h
++++ b/xen/include/asm-arm/acpi.h
+@@ -54,6 +54,14 @@ void acpi_smp_init_cpus(void);
+ */
+ paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
+
++/* Macros for consistency checks of the GICC subtable of MADT */
++#define ACPI_MADT_GICC_LENGTH \
++ (acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
++
++#define BAD_MADT_GICC_ENTRY(entry, end) \
++ (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \
++ (entry)->header.length != ACPI_MADT_GICC_LENGTH)
++
+ #ifdef CONFIG_ACPI
+ extern bool acpi_disabled;
+ /* Basic configuration for ACPI */
diff -Nru
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
---
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
1969-12-31 19:00:00.000000000 -0500
+++
xen-4.14.3/debian/patches/rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
2021-09-13 10:25:25.000000000 -0400
@@ -0,0 +1,29 @@
+From: Julien Grall <jgrall at amazon.com>
+Date: Thu, 5 Nov 2020 22:31:06 +0000
+Subject: xen/arm: traps: Don't panic when receiving an unknown debug trap
+
+Even if debug trap are only meant for debugging purpose, it is quite
+harsh to crash Xen if one of the trap sent by the guest is not handled.
+
+So switch from a panic() to a printk().
+
+Signed-off-by: Julien Grall <jgrall at amazon.com>
+Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
+(cherry picked from commit 957708c2d1ae25d7375abd5e5e70c3043d64f1f1)
+---
+ xen/arch/arm/traps.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
+index 2197df2..22bd1bd 100644
+--- a/xen/arch/arm/traps.c
++++ b/xen/arch/arm/traps.c
+@@ -1411,7 +1411,7 @@ static void do_debug_trap(struct cpu_user_regs *regs,
unsigned int code)
+ show_execution_state(regs);
+ break;
+ default:
+- panic("DOM%d: Unhandled debug trap %#x\n", domid, code);
++ printk("DOM%d: Unhandled debug trap %#x\n", domid, code);
+ break;
+ }
+ }
diff -Nru xen-4.14.3/debian/patches/series xen-4.14.3/debian/patches/series
--- xen-4.14.3/debian/patches/series 2021-09-13 10:25:25.000000000 -0400
+++ xen-4.14.3/debian/patches/series 2021-09-27 11:51:04.000000000 -0400
@@ -24,15 +24,15 @@
0024-tools-don-t-build-ship-xenmon.patch
0025-tools-Partially-revert-Cross-compilation-fixes.patch
0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch
-0027-xen-rpi4-implement-watchdog-based-reset.patch
-0028-tools-python-Pass-linker-to-Python-build-process.patch
-0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
-0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
-0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
-0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
-0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
-0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
-0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
+rpi4/0027-xen-rpi4-implement-watchdog-based-reset.patch
+rpi4/0028-tools-python-Pass-linker-to-Python-build-process.patch
+rpi4/0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch
+rpi4/0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
+rpi4/0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch
+rpi4/0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch
+rpi4/0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch
+rpi4/0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch
+rpi4/0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch
0036-fix-spelling-errors.patch
0037-xen-don-t-have-timestamp-inserted-in-config.gz.patch
0038-x86-EFI-don-t-insert-timestamp-when-SOURCE_DATE_EPOC.patch
diff -Nru xen-4.14.3/debian/rules xen-4.14.3/debian/rules
--- xen-4.14.3/debian/rules 2021-07-10 08:01:39.000000000 -0400
+++ xen-4.14.3/debian/rules 2021-09-27 10:16:19.000000000 -0400
@@ -176,9 +176,13 @@
# /bin/sh: 1: Syntax error: Unterminated quoted string
# probably because the CFLAGS value contains multiple options and
# therefore spaces. See also the note by `undefine CFLAGS', above.
+# Also, restore the RPI4 patches if they were disabled in the last build
override_dh_auto_clean:
rm -f debian/xen-tools-built.stamp
$(MAKE) -j1 distclean
+ quilt pop 0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch \
+ && sed s/#rpi4/rpi4/ debian/patches/series > series.tmp \
+ && mv series.tmp debian/patches/series && quilt push -a
# To avoid that the build dirties the tree, our delta queue deletes
# config.sub and config.guess. dh_update_autotools_config can get
@@ -213,6 +217,7 @@
--enable-ovmf --with-system-ovmf=/usr/share/ovmf/OVMF.fd \
--with-system-seabios=/usr/share/seabios/bios-256k.bin
+# To fix #994899, we disable the patches that support the RPI4 on amd64|i386
# tools/firmware/xen-dir is the `shim' used for booting PV guests
# in an HVM container, for security (particularly, for meltdown/spectre
# mitigation). It's actually a hypervisor. On i386 it is not built
@@ -221,6 +226,12 @@
# build it with $(make_args_xen) not $(make_args_tools). So do it
# separately.
override_dh_auto_build:
+ case $(flavour) in \
+ amd64|i386) \
+ quilt pop 0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch \
+ && sed s/rpi4/#rpi4/ debian/patches/series > series.tmp &&
\
+ mv series.tmp debian/patches/series && quilt push -a ;; \
+ esac
$(MAKE) $(make_args_xen) xen
$(MAKE) $(make_args_tools) tools docs CONFIG_PV_SHIM=n
case $(flavour) in \
Chuck Zmudzinski
2021-Sep-27 16:52 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
A patch has been uploaded (see message #67). For more information, see message #34.
Hans van Kranenburg
2021-Oct-04 09:46 UTC
[Pkg-xen-devel] Bug#994899: Bug#991967: Simply ACPI powerdown/reset issue?
Hi Elliot and others, Also including #994899 for once, since that's the bug number for the Xen issue now. On 9/26/21 5:27 AM, Elliott Mitchell wrote:> On Tue, Sep 21, 2021 at 06:33:20AM -0400, Chuck Zmudzinski wrote: >> I presume you are suggesting I try booting 4.19.181-1 on the >> current version of Xen-4.14 for bullseye as a dom0. I am not >> inclined to try it until an official Debian developer endorses >> your opinion that the bug I am seeing is distinct >> from #991967, at which point I will report the bug I am >> seeing as a new bug. > > Chuck Zmudzinski you are getting rather close to my threshold for calling > harrassment. You're not /quite/ there, but I'm concerned. > > > Since the purpose of the bug reports is to find and diagnose bugs, I did > a bit of experimentation and made some observations. > > I checked out the Debian Xen source via git. I got the current > "master" branch which is presently the candidate 4.14.3-1 version, > which includes urgent fixes. The hash is: > e7a17db0305c8de891b366ad37777528e5a43015 > > On top of this I cherry-picked 3 commits from Xen's main branch: > 5a4087004d1adbbb223925f3306db0e5824a2bdc > 0f089bbf43ecce6f27576cb548ba4341d0ec46a8 > bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b > > (these can be retrieved via Xen's gitweb at > https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=<$hash> which is > suitable for the `git am` command) > > With these I built 4.14.3-1 and then tried kernels 4.19.181-1 and > 4.19.194-3 (this system is presently mostly on oldstable). The results > were: > > Xen 4.14.3-1 with Linux 4.19.181-1: system reboots were successful > > Xen 4.14.3-1 with Linux 4.19.194-3: system reboots hungOk, so it included 0f089bbf43, which is probably the most important of the 3 fixes that we need indeed. And, it's good that the above difference is still visible afterwards, since it confirms that we're looking at two distinct problems.> Unfortunately I was too quick at installing the rebuilt 4.14.3-1 and I > missed trying the vanilla Debian 4.14.2+25-gb6a8c4f72d-2 with > Linux 4.19.181-1. I believe this combination would have hung during > reboot.The Xen related breakage was introduced in 4.14.0+88-g1d1d1f5391-2, so with that combination, I would expect you would experience both of the bugs at the same time, yes.> As such, I believe there are in fact two distinct bugs being observed. > The presence of EITHER of these is sufficient to cause hangs during > powerdown or reboot. > > First, some patch originally from Linux's main branch breaks Xen reboots > was backported somewhere between 4.19.181-1 and 4.19.194-3. This may > either have been introduced before 5.10 diverged from main, or may also > have been backported to 5.10. THIS is Debian bug #991967. > > Second, the Xen patch 3c428e9ecb1f290689080c11e0c37b793425bef1 which is > valuable to ARM devices breaks reboots and powerdowns on x86. This is > correctly fixed by 0f089bbf43ecce6f27576cb548ba4341d0ec46a8. Presently > this has no Debian bug report.Correct. Thanks a lot for your help with hunting down and confirming this. And now we have #994899 for it. So, I would like to kindly ask everyone to stop hijacking this one, #991967, for discussing the Xen problem.> The first is presently unidentified, someone enthusiastic either needs to > read git logs/source code, or bisect and build to find where it got > broken. > > The second we seem to have a fix. The only question is how many patches > to cherry pick? bc141e8ca562 is non-urgent as it is merely superficial > and not needed for functionality. > 5a4087004d1a is a workaround for Linux kernel breakage, but how likely > are we to see that fixed in the Linux kernel packages? The fix is > well-contained and needed for some highly popular ARM devices.Diederik also helped with testing changes, and when combining results, the best thing we can do is pick the 4 changes that were initially posted in Nov 2020 as "x86: ACPI and DMI table mapping fixes", and ended up in Xen 4.15 as well. ---- >8 ---- commit 8b6d55c1261820bb9db8d867ce9ee77397d05203 Author: Jan Beulich <jbeulich at suse.com> Date: Tue Nov 24 11:26:02 2020 +0100 x86/ACPI: fix mapping of FACS commit f390941a92f102ebbbbce1b54be206a602187fd7 Author: Jan Beulich <jbeulich at suse.com> Date: Tue Nov 24 11:26:34 2020 +0100 x86/DMI: fix table mapping when one lives above 1Mb commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8 Author: Jan Beulich <jbeulich at suse.com> Date: Tue Jan 5 13:09:55 2021 +0100 x86/ACPI: fix S3 wakeup vector mapping commit 16ca5b3f873f17f4fbdaecf46c133e1aa3d623b2 Author: Jan Beulich <jbeulich at suse.com> Date: Tue Jan 5 13:11:04 2021 +0100 x86/ACPI: don't invalidate S5 data when S3 wakeup vector cannot be determined ---- >8 ---- The 4th one is not explicitly tagged with Fixes: 1c4aa69ca1e1, but I agree with Diederik that we should keep them all together. I do not know if this is also the thing Chuck tested in the end, but I'm a bit lost in the walls of text that were produced in these two bugs. https://salsa.debian.org/xen-team/debian-xen/-/merge_requests/14 These fixes were actually posted before 4.14.0+88-g1d1d1f5391-2 happened. It's unfortunate that we did not notice it, since the above could have been part of the package that was in the archive when Debian 11 released. Or if anyone owning the specific type of hardware had ran into it during testing during the freeze, we could also have found them in time. But yeah, that happens. Diederik, I think we should omit the 5th one, since it's a cosmetics commit, which also starts touching (older) code unrelated to this issue. What I plan to do is include these as regression fixes in the next package update. The issue is only affecting a subset of hardware types. There's a workaround (pull the plug), the fixes are known. There is no security risk, there is no data corruption or unexpected crashes during normal operation. Hans
Diederik de Haas
2021-Oct-04 10:57 UTC
[Pkg-xen-devel] Bug#994899: Bug#991967: Simply ACPI powerdown/reset issue?
On Monday, 4 October 2021 11:46:54 CEST Hans van Kranenburg wrote:> The 4th one is not explicitly tagged with Fixes: 1c4aa69ca1e1, but I > agree with Diederik that we should keep them all together.Context: Those 4 are part of 1 patch-set posted here: https://lists.xen.org/archives/html/xen-devel/2020-11/msg01516.html The 5th was already debatable and I choose to include it in my MR, but I'm fine with not including that one. Cheers, Diederik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20211004/4c6103ee/attachment.sig>
Chuck Zmudzinski
2021-Oct-04 15:27 UTC
[Pkg-xen-devel] Bug#994899: Bug#991967: Simply ACPI powerdown/reset issue?
On 10/4/2021 6:57 AM, Diederik de Haas wrote:> On Monday, 4 October 2021 11:46:54 CEST Hans van Kranenburg wrote: >> The 4th one is not explicitly tagged with Fixes: 1c4aa69ca1e1, but I >> agree with Diederik that we should keep them all together. > Context: Those 4 are part of 1 patch-set posted here: > https://lists.xen.org/archives/html/xen-devel/2020-11/msg01516.html > > The 5th was already debatable and I choose to include it in my MR, but I'm fine > with not including that one. > > Cheers, > DiederikAs the submitter of #994899, I can confirm these 4 fix the bug on my hardware. I agree this fix can close #994899 and #995341, since as Hans noted, they are part of the upstream stable 4.15 branch and I presume that will make them stable enough for bullseye. Thank you Hans, Diederik, and Elliott. All the best, Chuck
Chuck Zmudzinski
2021-Oct-04 15:52 UTC
[Pkg-xen-devel] Bug#994899: Bug#991967: Simply ACPI powerdown/reset issue?
As discussed in message #91, the submitter of this bug accepts the package maintainer's fix which will close this bug.
Diederik de Haas
2021-Oct-04 17:51 UTC
[Pkg-xen-devel] Bug#994899: Bug#991967: Simply ACPI powerdown/reset issue?
On Monday, 4 October 2021 17:27:22 CEST Chuck Zmudzinski wrote:> I can confirm these 4 fix the bug on my hardware.\o/ Thanks for testing and reporting back :-) Cheers, Diederik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20211004/f57ce509/attachment-0001.sig>
Chuck Zmudzinski
2021-Oct-05 00:16 UTC
[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
On 10/4/2021 1:51 PM, Diederik de Haas wrote:> On Monday, 4 October 2021 17:27:22 CEST Chuck Zmudzinski wrote: >> I can confirm these 4 fix the bug on my hardware. > \o/ > Thanks for testing and reporting back :-) > > Cheers, > DiederikThank you, Diederik, for your good work finding the commits from upstream that fix the bug. And also thanks to you, Andy, for helping fix this bug in the IRC and for your interest and support of the Debian Xen Team's work. Cheers, Chuck
Hans van Kranenburg
2021-Nov-27 20:15 UTC
[Pkg-xen-devel] Bug#994899: Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye
Hi all, On 10/5/21 2:16 AM, Chuck Zmudzinski wrote:> On 10/4/2021 1:51 PM, Diederik de Haas wrote: >> On Monday, 4 October 2021 17:27:22 CEST Chuck Zmudzinski wrote: >>> I can confirm these 4 fix the bug on my hardware. >> \o/ >> Thanks for testing and reporting back :-) > > Thank you, Diederik, for your good work finding the commits > from upstream that fix the bug. And also thanks to you, Andy, > for helping fix this bug in the IRC and for your interest and > support of the Debian Xen Team's work.So, we're in the process of actually doing a package update now, which includes these fixes. I can confirm that my HP DL360 hardware at work also did not fully power off. And now, it does: ---- >8 ---- [ OK ] Reached target Late Shutdown Services. [ OK ] Finished System Power Off. [ OK ] Reached target System Power Off. [16302.044148] reboot: Power down (XEN) Disabling non-boot CPUs ... (XEN) Broke affinity for IRQ12, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ1, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ9, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ16, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ17, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ99, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ112, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ113, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ114, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ115, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ116, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ117, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ118, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ119, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ120, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ121, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ122, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ123, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ124, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ125, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ126, new: ffffffff,ffffffff (XEN) Broke affinity for IRQ127, new: ffffffff,ffffffff (XEN) Entering ACPI S5 state. The server is not powered on. The Virtual Serial Port is not available. ---- >8 ---- So, this one will get closed when we do the upload to unstable. Besides that, it will of course also be fixed in stable if we get the same thing into there in the next days. Hans
Debian Bug Tracking System
2021-Nov-28 21:09 UTC
[Pkg-xen-devel] Bug#994899: marked as done (xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye)
Your message dated Sun, 28 Nov 2021 21:08:23 +0000 with message-id <E1mrRPL-000878-P5 at fasolo.debian.org> and subject line Bug#994899: fixed in xen 4.14.3+32-g9de3671772-1 has caused the Debian Bug report #994899, regarding xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 994899: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Chuck Zmudzinski <brchuckz at netscape.net> Subject: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye Date: Wed, 22 Sep 2021 15:50:16 -0400 Size: 11216 URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20211128/f1ef7209/attachment.eml> -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters <ftpmaster at ftp-master.debian.org> Subject: Bug#994899: fixed in xen 4.14.3+32-g9de3671772-1 Date: Sun, 28 Nov 2021 21:08:23 +0000 Size: 6470 URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20211128/f1ef7209/attachment-0001.eml>