>>> On 12.06.17 at 12:53, <paul.durr...@citrix.com> wrote: >> -----Original Message----- > [snip] >> > > >> > > What do you think it best to do for Xen 4.9? Hardcoding a 4k alignment is >> > > clearly easy and would work around this BIOS issue but, as you say, it >> does >> > > grow the image. Reverting Juergen's patch also works round the issue, >> but >> > > that is more by luck. Re-working the code is preferable, but I guess it's >> too >> > > late to introduce such code-churn in 4.9. >> > >> > Reverting Jürgen's code is out of question with all the information >> > you've gathered by now. I think re-working the EDD code slightly >> > is the best option. Would you mind giving the attached patch a >> > try? This still slightly grows the trampoline due to a few more >> > instructions being needed, but should still be far better than >> > embedding a whole 4k buffer (and then later finding a BIOS/disk >> > combination which wants even more). Note that I've left a tiny >> > bit of debugging code in there. >> > >> >> Sure, I'll give that a go now. >> > > That worked fine: > > (XEN) MBR[80] @ 85e0 (86000)
But that's contrary to your earlier findings: Didn't you say simply avoiding a 4k-boundary wasn't enough? And it certainly tells us that this isn't a 4k drive (or at least the BIOS doesn't surface 4k sectors) - I was really expecting a larger gap between the two logged values. > so you can add my Tested-by to that. I.e. I'm not sure about this, as I'm still uncertain whether some corruption didn't again occur. Of course APs coming up properly would already be a relatively good sign (as now the permanent part of the trampoline would be the predestined area for corruption to occur in). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
