qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH][RESEND v3 3/3] Add a Hyper-V Dynamic Memory Protocol driver


From: David Hildenbrand
Subject: Re: [PATCH][RESEND v3 3/3] Add a Hyper-V Dynamic Memory Protocol driver (hv-balloon)
Date: Tue, 28 Feb 2023 18:12:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 28.02.23 17:18, Igor Mammedov wrote:
On Fri, 24 Feb 2023 22:41:16 +0100
"Maciej S. Szmigiero" <mail@maciej.szmigiero.name> wrote:

From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>

This driver is like virtio-balloon on steroids: it allows both changing the
guest memory allocation via ballooning and inserting extra RAM into it by
adding required memory backends and providing them to the driver.


this sounds pretty much like what virtio-mem does, modulo used protocol.
Would it be too crazy ask to reuse virtio-mem by teaching it new protocol
and avoid adding new device with all mgmt hurdles that virtio-mem has
already solved?

There are some main differences between both approaches that make a 1:1 reuse impossible. As one example, the hv-balloon can operate (inflate) on the whole VM memory, which is very different to the virtio-mem model. As another example, the hv-balloon does not support variable (large) block sizes, and must be able to operate in page granularity IIRC. This not only restricts which memory backends we can use, it also means that vfio support is rather problematic (just like with virtio-balloon).

So there is more to that than a simple protocol difference and I don't think we can simply implement a proxy devices.

But I do think that we would be able to reuse some of the ideas/infrastructure virtio-mem implemented: for example, using a single large sparse memory region.

--
Thanks,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]