> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 07 June 2017 13:19 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Julien Grall (julien.gr...@arm.com) <julien.gr...@arm.com>; Andrew > Cooper <andrew.coop...@citrix.com>; xen-devel (xen- > de...@lists.xenproject.org) <xen-de...@lists.xenproject.org>; 'Boris > Ostrovsky' <boris.ostrov...@oracle.com>; Juergen Gross > <jgr...@suse.com> > Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot > > >>> On 07.06.17 at 14:02, <paul.durr...@citrix.com> wrote: > >> From: Juergen Gross [mailto:jgr...@suse.com] > >> Sent: 07 June 2017 12:57 > >> > >> On 07/06/17 13:06, Paul Durrant wrote: > >> > It appears that it is just the code that needs to go at the end. The > following > >> patch is sufficient to avoid the problem. This may be preferable to a full > >> reversion... > >> > >> I believe this is wrong. You risk the wakeup_stack extending into wakeup > >> code and the main reason of the patch is gone, as now the permanent > >> trampoline no longer is on a single page. > >> > > > > I must be misunderstanding something then. The stack grows down from > > wakeup_stack towards wakeup_stack_start doesn't it? So why would > there be an > > issue with the stack overwriting wakeup code? > > I think this is a pointless discussion: Once we know memory is being > corrupted, it doesn't help shuffling things around. By putting the > wakeup code at the end, it'll be that which gets corrupted, and > hence S3 wakeup would not work. We can really only try to figure > out what parts of memory we need to avoid touching _at all_. >
Yes, fair enough. I'm currently trying to figure out what the code in head.S just ahead of trampoline_setup is trying to do. Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
