On Wed, 2023-02-01 at 16:50 +0000, Peter Maydell wrote: > On Wed, 1 Feb 2023 at 15:25, James Bottomley <j...@linux.ibm.com> > wrote: > > > > On Wed, 2023-02-01 at 10:10 -0500, Jason A. Donenfeld wrote: > > > This is already fixed via the patch that MST just sent in his > > > pull. > > > So wait a few days for that to be merged and it'll be all set. > > > > > > No need for this patch here. Do not merge. > > > > If it's not a secret, would it be too much trouble to point to the > > branch so we can actually test it? It does seem that the biggest > > problem this issue shows is that there wasn't wide enough > > configuration > > testing done on the prior commits before they were merged. > > In general you shouldn't expect commits to be visible in > a git branch before they get merged -- the QEMU process > is not exactly identical to the kernel one. > > For a particular patch on the mailing list, you can get a git branch > with it applied by looking for the patch in https://patchew.org/QEMU/ > if that's more convenient than just applying it by hand.
The real issue is there have been so many patches flying around for this, it's not clear exactly what combination needed to be tested. Dov found the branch in tags/for_upstream but it's still failing measured direct boot, although the failure has shifted from the hash check of the kernel to the hash check of the command line. All I really wanted was a link to the patch ... I don't need the tree because inspection will tell me that it adds unexpected data at the end of an integrity checked file. > We also don't tend to want patches hanging around for testing > before they get merged[*] -- we figure that "in upstream git" > is the place that actually gets tested in practice; almost > nobody will be working with or testing anything else. > > [*] The fix Jason refers to here that's in MST's pullreq > unfortunately hasn't made it upstream as quickly as I > would like, due to a combination of things including us > having to pause CI for a week when we ran out of minutes. OK, so the problem is still the same as it was before: adding unexpected data to an integrity checked file. I don't get why there's all this dancing around trying to find space. Surely when the parameter was added, since it was a fixed size, the kernel header was expanded and the boot protocol version bumped? So we can use that to identify kernels which can use this property and have the space to insert it directly. James
