On 17 November 2014 20:08, Michael S. Tsirkin <m...@redhat.com> 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
