Re: [virtio] [OASIS Issue Tracker] Created: (VIRTIO-28) Implement new balloon device (ID 13)

[Rusty Russell <rusty@au1.ibm.com>]

Daniel Kiper <daniel.kiper@oracle.com> writes:
> On Thu, Dec 12, 2013 at 11:40:11AM +1030, Rusty Russell wrote:
>> If this is true, it means Xen cannot offer this device.  We can't have
>> Xen offer a device which a generic virtio-spec compliant OS can't drive.
>>
>> We can, however, have a differently-numbered "Xen Balloon Device" which
>> takes xen-specific PFNs instead, and is otherwise identical.  This is
>> perfectly sane, and even the Linux driver (which will support both) will
>> look clean.
>
> This make sens but I think that it is last resort solution. IMO all
> devices/drivers should work on any hypervisor. I will play with new
> VIRTIO balloon device/driver and we will see what is possible.

Agreed.

>> It would have to be a feature bit: VIRTIO_BALLOON_F_UNLIMITED ?
>
> OK.
>
>> I think it would create an extra burden for non-Xen balloon devices:
>> - The PFN extracted from the balloon would either be a PFN which had
>>    been put into the balloon, or the lowest available PFN (ie. just
>>    above current top of mem)
>>
>> Otherwise a guest might get a crazily sparse memory map.
>>
>> Thoughts?
>
> I used this simplistic solution in Xen balloon driver and it does not
> work well if there is an I/O region above max_pfn. So we should not
> make this mistake here. I think that we could use solution similar
> to used on real hardware with ACPI. In memory hotplug case VIRTIO
> balloon device should send start address of hotplugged region and its
> size. Later everything should work as in pure balloon driver.

That makes perfect sense (though the name "UNLIMITED" now sucks... Hmm,
VIRTIO_BALLOON_F_EXTRAMEM maybe?).  

So if that feature is negotiated, then two new RO config fields become
available, which specify the range where the extra memory will appear?

Cheers,
Rusty.