(cc Greg)
On Wed, 11 Dec 2024 at 13:30, Marek Marczykowski-Górecki
<marma...@invisiblethingslab.com> wrote:
>
> On Wed, Dec 11, 2024 at 01:24:08PM +0100, Ard Biesheuvel wrote:
> > On Wed, 11 Dec 2024 at 12:53, Jürgen Groß <jgr...@suse.com> wrote:
> > >
> > > Jason, Ard,
> > >
> > > I guess there are some prereq patches missing in stable 6.6.y branch?
> > >
> > >
> > > Juergen
> > >
> > > On 11.12.24 12:41, Marek Marczykowski-Górecki wrote:
> > > > Hi,
> > > >
> > > > With Linux 6.6.64 I get the following crash on domU boot:
> > > >
> > > > (XEN) d5v0 Triple fault - invoking HVM shutdown action 1
> > > > (XEN) *** Dumping Dom5 vcpu#0 state: ***
> > > > (XEN) ----[ Xen-4.19.0 x86_64 debug=n Tainted: M ]----
...
> > > >
> > > > Linux 6.6.63 works fine.
> > > >
> > > > Looking at the changes, I suspect one of those:
> > > >
> > > > 83d123e27623 x86/pvh: Call C code via the kernel virtual mapping
> > > > f662b4a69e1d x86/pvh: Set phys_base when calling xen_prepare_pvh()
> > > >
> >
> > The second patch shouldn't have been backported. It is unnecessary,
> > given that in the old situation, the kernel image needs to be loaded
> > at a fixed address. And it assumes that %rbp is set to the physical
> > load offset, but those patches were not backported.
>
> It has this tag:
>
> Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel virtual
> mapping")
>
That was added by the stable maintainers - someone grabbed a patch
from the middle of an unrelated series to make e8fbc0d9cab6 apply
without lexical conflicts.
> Does it mean neither of them should be backported?
>
> But then, the e8fbc0d9cab6 has "Fixes:" tag (pointing at very old
> commit).
>
If someone thinks e8fbc0d9cab6 should be backported, they should
rebase it onto v6.6.y, not backport random other patches until
git-apply stops complaining. And ideally, someone would build and boot
the result to check whether it works.
For now, it would be better to revert both.
