From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5uy-000892-Ls for qemu-devel@nongnu.org; Wed, 19 Nov 2014 09:07:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr5ut-0007qz-NJ for qemu-devel@nongnu.org; Wed, 19 Nov 2014 09:07:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5ut-0007qr-Ec for qemu-devel@nongnu.org; Wed, 19 Nov 2014 09:07:31 -0500 From: Juan Quintela In-Reply-To: (Peter Maydell's message of "Wed, 19 Nov 2014 13:58:54 +0000") References: <1416254843-16859-1-git-send-email-mst@redhat.com> <1416254843-16859-3-git-send-email-mst@redhat.com> Date: Wed, 19 Nov 2014 15:07:26 +0100 Message-ID: <87a93nmggx.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , QEMU Developers , "Dr. David Alan Gilbert" , "Michael S. Tsirkin" Peter Maydell wrote: > On 17 November 2014 20:08, Michael S. Tsirkin 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.