[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v3 0/8] x86: more or less log-dirty related improvements


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 26 Apr 2022 12:20:26 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8mF7sdl0jbfeZ0WAUgPUUQdPB6IKJPyJIzvkMw/O2vk=; b=SmZYrStnqxHetS1O4zb4nBGnGn49IXxo9uVWkY4ol1jt8/0WBRQPMIfiITo77n1TeadRN1HRAC6XbuECStTh9n0Fewar/E7Sdi6ZGNm0vLx00/MIJXQ9M325kNZ6+rWPXxVj7HVZbjWW+LUZLv+UFSFBVN4LfZyHrwSaiw2IY9bdX2Z873IM/Efu+8lstxXIjgld62NCqIx9fZjhZZavT9loLrr27QSBaRtVr2AUPhfBKjne4xOcgZEQONtSrdkIJ3Z/56RcsJD4P04u6xme9HHSdPgwC3294n9ozyIVPQqb54c5mbLmnvj0jXn15pTAZBVsii/orwtvaEIaid+vIw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WhKmIofS9ZOShRW+BUCLulQDksLhhnECYVcp4ZCn15+pKtm0AO7ZWDjDsSY0q0f+ek8zkdiyIIZXD0l6/XJnofUOUAApgC1UFUCyqBPwn1PMW/hk4nA8A5m7+B1xigMBx2QowmLUKlYuQ1Xo2tg+CF43Y+DgdzpYFmkW584fRXvhOslMPC3FtC4LP3KY41WvsslDhfblFiHguU2/xK/pn65UEV09amJmZzW7y2r/I3PZSBbToK7KB+tRY/tQdHdIcoHfrLVdR/V4vPpnoUjTPZ8aLDROy+XVqYaSGl9R/ZqGupGb+NZ6hglJgQR9pBGA49K1YTIe4fqSwqNFREhdpA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Tue, 26 Apr 2022 10:20:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

... 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 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.

No significant changes in v3 (individual patches have details); a
controversial patch was moved later in the series.

1: libxenguest: short-circuit "all-dirty" handling
2: libxenguest: avoid allocating unused deferred-pages bitmap
3: libxenguest: guard against overflow from too large p2m when checkpointing
4: libxenguest: restrict PV guest size
5: libxenguest: deal with log-dirty op stats overflow
6: x86/paging: supply more useful log-dirty page count
7: x86/mm: update log-dirty bitmap when manipulating P2M
8: SUPPORT.md: write down restriction of 32-bit tool stacks

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.