
On Tue, Jun 05, 2018 at 04:05:38PM +0200, Andrea Bolognani wrote:
On Mon, 2018-06-04 at 11:33 +1000, David Gibson wrote:
On Thu, May 24, 2018 at 07:34:25AM +0200, Peter Krempa wrote:
On Wed, May 23, 2018 at 19:09:59 +0200, Andrea Bolognani wrote:
To be fair, it would perhaps make sense to perform the conversion directly inside QEMU, in order to make it more convenient not only for libvirt but for for people driving it directly as well.
If strictly only powers of two make sense for this knob then this gives you input validation for free. On the other hand, specifying a big number can overflow internally if it is ever used in the non-exponent form. I think the format does not matter much, since libvirt's job is to shield users from such weirdness.
Yeah, the above is basically my reasoning for using the exponent, not the final page size.
As Peter mentioned, what format is used doesn't matter much from libvirt's point of view, and in fact this RFC already implements the necessary format conversion; however, it might be convenient for people spawning QEMU directly to be able to specify the page size in a more human-friendly format.
How do you feel about that? If that's off the table, we'll just go ahead with the current implementation.
So, I need to keep the internal representation as a shift, since we only have 8 bits in the capability field. But that doesn't prevent changing the command line representation, since we could convert in the getter/setter functions. Personally I think the shift is *more* usable than a raw page size, since the latter is inevitably going to involve counting a bunch of zeroes to see if it's the number you meant. Allowing forms like "16M" / "16G" could be nicer; not sure if we have existing helper functions which will make that easy. TBH, if the user is already thinking about page sizes at this low level, I don't think doing it by shift is much of a stretch. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson