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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list