Re: [PATCH v2] hw/arm/virt enable support for virtio-mem

[David Hildenbrand]

> Ah. I'd missed that quirk around MAX_ORDER.  It's also true of ARM64 with
> 4k pages.  As you can probably guess I'd forgotten to recompile my 4k test
> kernel after adding that particular check. :(
> 
> Ah well. Given we are already in a situation where adding 2MiB doesn't 
> actually
> do anything useful, I guess it's not really a problem to merrily let the host
> add less than the guest can make use of.  So we allow adding any multiple of
> 2MiB but reality is the guest isn't going to use anything other than 512MiB
> chunks.

Right, and the host can observe the change not happening when not
aligned to 512 MB. There are plans for a virtio-mem extension for the
guest to present a status - e.g., why the requested size cannot be
achieved (requested size not alignment, usable region too small,
ENOMEM/EBUSY when unplugging, ...).

[...]

>>>
>>> 4K guest on 64K host seems fine and no such limit is needed - though there
>>> may be performance issues doing that.  
>>
>> Yeah, if one is lucky to get one of these 512 MiB huge pages at all :)
> 
> Not too hard on my 1TB test system that's running nothing much else, but 
> agreed it
> won't be trivial more generally.

Hehe, right ! (... and here I am, testing with 64GB machines ... :) )

It's more of an issue in the guest to get 512 MB without ZONE_MOVABLE to
unplug ... especially with smaller VMs.

> 
>>
>>>
>>> 64k guest on 4k host with 512MiB block size seems fine.
>>>
>>> If there are any places anyone thinks need particular poking I'd appreciate 
>>> a hint :)  
>>
>> If things seem to work for now, that's great :) Thanks!
>>
> Cool.  I'll run a few more comprehensive tests then send out the
> trivial patch to enable the kernel option + v2 of the qemu support.

Perfect, thanks!

-- 
Thanks,

David / dhildenb