From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
Subject: Re: [Qemu-devel] KVM call agenda for tuesday 31
Date: Fri, 10 Feb 2012 00:17:54 +0100
Message-ID: <4F345422.5080208@suse.de>
References: <87ehuhrpel.fsf@elfo.elfo> <4F272A92.2010609@suse.de>	<4F272D8C.8020608@codemonkey.ws> <4F27E98E.2080501@suse.de> <CAFEAcA_u2qTgnaNMvVRn_K+3SrbaTLMUs4NH654wgQGAnFGxTg@mail.gmail.com> <4F344A90.6020705@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Peter Maydell <peter.maydell@linaro.org>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Mitsyanko Igor <i.mitsyanko@samsung.com>,
	Developers qemu-devel <qemu-devel@nongnu.org>,
	quintela@redhat.com, Alexander Graf <agraf@suse.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Return-path: <kvm-owner@vger.kernel.org>
Received: from cantor2.suse.de ([195.135.220.15]:42228 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757927Ab2BIXR5 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 9 Feb 2012 18:17:57 -0500
In-Reply-To: <4F344A90.6020705@codemonkey.ws>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Am 09.02.2012 23:37, schrieb Anthony Liguori:
> On 02/09/2012 04:23 PM, Peter Maydell wrote:
>> Ping re the VMState and variable sized arrays issue. I don't
>> see any consensus in this discussion for a different approach,
>> so should we just commit Mitsyanko's patchset?
>=20
> I don't know if I mentioned this, but do we really need variable size=
s?

You didn't in this context. :)

I didn't write the original code so don't know what use cases beyond
ICH9 it had in mind. Alex?

> Can we just use a fixed size (pre-allocated) array and then use a
> VMSTATE_SUB_ARRAY?

my RFC did something similar. Apparently I forgot the link:

http://patchwork.ozlabs.org/patch/133065/

In the case of AHCI allocating 32 structs when we know we only need six
seems like a waste - although I agree that preallocation can be a good
thing (but that's for a different thread).

> If it's truly variable size with no upper bound, then that's actually=
 a
> security problem since it implies a guest can do unbounded memory
> allocation.

In the cases we're talking about here, I believe the allocation is
always in the init or realize phase based on user parameters, not the g=
uest.

And whatever we decide, we definitely need better documentation on
VMState! There's also a small part that wasn't moved to vmstate.h. I'd
volunteer for the easy macros but honestly don't understand all of them=
=2E

Andreas

--=20
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=
=BCrnberg