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

[Peter Maydell]

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)?

thanks
-- PMM