Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize

[Juan Quintela]

Peter Maydell <address@hidden> wrote:
> On 17 November 2014 20:08, Michael S. Tsirkin <address@hidden> wrote:
>> Add API to manage on-device RAM.
>> This looks just like regular RAM from migration POV,
>> but has two special properties internally:
>>
>>     - it is never exposed to guest
>>     - block is sized on migration, making it easier to extend
>>       without breaking migration compatibility or wasting
>>       virtual memory
>>     - callers must specify an upper bound on size
>
>> +/* On-device RAM allocated with g_malloc: supports realloc,
>> + * not accessible to vcpu on kvm.
>> + */
>> +#define RAM_DEVICE     (1 << 2)
>
> Does this comment mean "KVM guests cannot access this
> memory, so it's a board bug to attempt to map it into
> guest address space"?. If so, what breaks? Can we have
> an assert or something to catch usage errors if it is
> mapped? Would it be possible to drop the restriction?
>
> I'm not convinced about the naming either -- isn't this
> for BIOSes rather than generic on-device scratch RAM
> (which you'd model either with a plain RAM memoryregion
> or with a locally allocated block of memory or array,
> depending on the device semantics)?

My understanding is that it is a "trick".  We have internal memory for a
device that is needed for the emulation, but not showed to the guest.
And it is big enough that we want to save it during the "live" stage of
migration, so we mark it as RAM.  if it is somekind of cash, we can just
enlarge it on destination, and it don't matter.  If this has anything
different on the other part of the RAM, we are on trouble.

Have I understood it correctly?

If so, it appears that all the cases (or the ones that mst cares about)
don't care about this size.

Later, Juan.