[libvirt] [PATCH v2 1/3] docs, conf, schema: add support for shmem device

[Martin Kletzander]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140925/955c697b/attachment-0001.sig>