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

[Michael S. Tsirkin]

On Wed, Nov 19, 2014 at 01:58:54PM +0000, Peter Maydell 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"?.

Yes.

> If so, what breaks?

When memory is reallocated, we don't update KVM.

> Can we have
> an assert or something to catch usage errors if it is
> mapped? Would it be possible to drop the restriction?

Yes, it's definitely possible.  It's a bit tricky: we need to tweak a
bunch of page flags on realloc, for example DONT_FORK:
clear them on old pages copy and set on new ones.
So I simply didn't want to bother.



> 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

Hmm I don't exactly see the difference.  This RAM is internal to FW CFG
device.  Other devices might want to use this too if they keep guest
code in their internal RAM.


I'm fine with changing the name though - what's your
suggestion?



-- 
MST