On 19.07.2021 09:46, Jan Beulich wrote: > On 05.07.2021 17:09, Jan Beulich wrote: >> ... or so I hope. This series continues the attempt to deal with >> the ovmf change putting the shared info page at a very high address >> (which is now planned to get reverted there, but the general >> problem doesn't go away by them doing so). There are further issues >> with truncated value, which are being dealt with here. But there >> are also not directly related changes, when I simply spotted things >> that aren't very likely to be right the way they are. And then >> there are also adjustments to the underlying hypervisor >> implementation, with the goal of making the returned data more >> useful to the consumers. >> >> With these changes in place, a 1Gb guest which has "inflated" >> itself by putting a page right below the 16Tb boundary migrates >> successfully, albeit the process takes from some 20 minutes to over >> half an hour on my test system. >> >> In v2, besides integrating 2 patches that were previously sent, >> there's one new patch and otherwise review feedback addressed >> (albeit there wasn't any for a number of patches). >> >> 01: libxl/x86: check return value of SHADOW_OP_SET_ALLOCATION domctl > > while I did get an R-b from Anthony on this one, but ... > >> 02: libxc: split xc_logdirty_control() from xc_shadow_control() >> 03: libxenguest: deal with log-dirty op stats overflow >> 04: libxenguest: short-circuit "all-dirty" handling >> 05: libxenguest: avoid allocating unused deferred-pages bitmap
with Jürgen's R-b for 2, 4, and 5, may I ask for a maintainer ack on at least patch 2? While I did address Andrew's comments on v1 of 4 and 5 (verbally), he didn't indicate back whether he was okay with my replies, so some judgement may need applying there when deciding whether to also give an ack there. Thanks. Patch 3 remains controversial as it seems, unfortunately. Jan
