On Thu, Aug 04, 2022 at 12:08:07AM +0200, Jason A. Donenfeld wrote: > Hi Michael, > > On Wed, Aug 03, 2022 at 06:03:20PM -0400, Michael S. Tsirkin wrote: > > On Wed, Aug 03, 2022 at 07:07:52PM +0200, Jason A. Donenfeld wrote: > > > On Wed, Aug 03, 2022 at 03:34:04PM +0200, Jason A. Donenfeld wrote: > > > > On Wed, Aug 03, 2022 at 03:11:48PM +0200, Jason A. Donenfeld wrote: > > > > > Thanks for the info. Very helpful. Looking into it now. > > > > > > > > So interestingly, this is not a new issue. If you pass any type of setup > > > > data, OVMF appears to be doing something unusual and passing 0xffffffff > > > > for all the entries, rather than the actual data. The reason this isn't > > > > new is: try passing `-dtb any/dtb/at/all/from/anywhere` and you get the > > > > same page fault, on all QEMU versions. The thing that passes the DTB is > > > > the thing that passes the RNG seed. Same mechanism, same bug. > > > > > > > > I'm looking into it... > > > > > > Fixed with: > > > https://lore.kernel.org/all/20220803170235.1312978-1-ja...@zx2c4.com/ > > > > > > Feel free to join into the discussion there. I CC'd you. > > > > > > Jason > > > > Hmm I don't think this patch will make it in 7.1 given the > > timeframe. I suspect we should revert the patch for now. > > > > Which is where you maybe begin to see why we generally > > prefer doing it with features - one can then work around > > bugs by turning the feature on and off. > > The bug actually precedes this patch. Just boot with -dtb on any qemu > version and you'll trigger it.
Sure but it's still a regression. > We're still at rc0; there should be time > enough for a bug fix. Please do chime in on that thread and maybe we can > come up with something reasonable fast enough. > > Jason Maybe. -- MST
