On Thu, Sep 25, 2014 at 04:21:14PM +0200, Levente Kurusa wrote:
Hi,
On Thu, Sep 25, 2014 at 03:37:46PM +0200, Michal Privoznik wrote:
> On 25.09.2014 11:45, Martin Kletzander wrote:
> [...]
>
> Where do these restrictions come from? If they're result of qemu
> implementation, than they should be checked in 3/3. If other HV learned
> shmem these limitations may not apply to it. Or is it a kernel thing that
> only areas with 1MB granularity can be mapped? Moreover, if such granularity
> is required, does it makes sense to store the size in bytes?
>
I wanted to make it more future-proof. That is that this way we can
start storing the size in MB any time we want and we can lax the
parsing whenever wanted.
If you want, I can just store the value in MiB for now or remove the
check (but not both, of course). I'd be in favour of the first thing.
It's ivshmem... The problem is that ivshmem predominantly thinks that
any size argument without a suffix like 'g/G' or 'm/M' is in
megabytes. I believe this is nice, but it would be nicer to have a
'k/K' suffix so that we could tell ivshmem that we want the size in
kilobytes... Maybe even a 'b' suffix for bytes.
That should be working after re-factoring done by David Marchand if
I'm correct, but it's not yet available.
Do you guys see any value in this? If yes, I will cook a patch ASAP,
so we might as well remove this check from the QEMU parts...
But yes, this check is definitely not needed here.
It would be nice if you could help move the QEMU parts a little bit.
I haven't heard about any status since we discussed some ivshmem
server details with David.
Martin