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

Re: [PATCH 03/10] x86 setup: change bootstrap map to accept new boot module structures


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 27 Jul 2023 16:42:07 +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=LPoj3KrIj/M8bNceDaw9DeN9H1cWbuIBQAI71tdvnts=; b=hY8xZ3YOFvvwpzkSq9mJcfSSKQzwfMc7olBrGiZZegZ+jypGpdfo7pdegZXgccwBPU7dsn17QI2gGx51J2tvfeHmhAHH/dEHTi1LUQ+75gcpCqhvMdooHUja6McJhJw710z++2u2o1d97AHcgDYy1bNAoG9SOCHnUaMul/fGsm2X4tDL6ccTRqc3xLVaSvKxx7na/hugUM4pNRvx8Igz/OioH1T/UqcrsoHiyeQYBOuRQNptztO8OYYVPt7aSEMmevQDaNDyVfbML2uGs9KEAQNpHzypoHol1NRMbT0APODJsJvvlszo/3HtES/rW/VvpzAodOq6boKM4hN63F7EUg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l5ATGptCbJQFeoK+E+RJe48m3wwhK3LGCkXPmsLg3DqrPQt29n047ROakSyQ6fDG/dEPrLqgoBLxXoxmoNu7nSaFk7yilw/N9dbwnZJDo6N7VhKZxUWhFuwQIO05ISxzxPwQ/1wCFKopMHQXSB3DObZfylpZohnJT9Belm7+nzUSmRWxunSy69qgbq1KRCg50BQ4lWrEyeFpgBgjYyq8dMUjn7wA/IIvqG8oVkiSVEgboIuY7Yb/63jTVGzhWVzLCHN3rErwYtZ42Sz8pi1qzE1vE1YVVJe54dKZXBHzVzPhb8yepcVVdonZluIzQz2VwEBoNsjnYcw1WMtixZ1oXw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, stefano.stabellini@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Luca Fancellu <luca.fancellu@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Rich Persaud <persaur@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Christopher Clark <christopher.w.clark@xxxxxxxxx>
  • Delivery-date: Thu, 27 Jul 2023 14:42:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.07.2023 15:26, Daniel P. Smith wrote:
> Let's bring this back to the actual implementation instead of the 
> theoretical. Your position is that Xen's paddr_t is desired because it 
> can store larger values than that of size_t. Now if you look in Xen 
> proper (main 64bit code on x86), paddr_t is a typedef for a 64bit 
> unsigned integer. And if you look at size_t, it is also a typedef to a 
> 64bit unsigned integer, they are literally a couple of lines apart in 
> types.h. Thus they are the same size and can only represent the same 
> maximum size.

What about 32-bit Arm, or any other 32-bit architecture that we might
see Xen ported to, with wider than 32-bit physical address space?

> The only area of issue for x86 is during the short bit of 
> code that runs in 32bit mode during startup. In this series, we address 
> this by using a set of macros in the 32bit code to provide 64bit clean 
> definition of the structures. This approach is acceptable because as far 
> as I am aware, x86 is the only platform where the hypervisor has to 
> transition from one bit size to another, e.g. Arm just starts in 64bit 
> mode when on a 64bit device.
> 
> At the end of the day, size_t is the same size as paddr_t for the end 
> execution environments and I would levy a guess that should x86 suddenly 
> find itself having a 128bit mode which would likely drive paddr_t to 
> 128bits, so would follow size_t.

Likely. Yet when we still had ix86 (x86-32) support, paddr_t also
wasn't the same as size_t. Even on x86-64 it's possible we'd see
physical address width go beyond 64 bits before virtual address width
would, just like had happened for ix86 (which initially only allowed
for 32-bit physical addresses, until PSE36 arrived).

In your implementation you want to cover the general case, not a subset
of special ones.

Jan



 


Rackspace

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