Re: [Qemu-devel] [PATCH v2] pc: memhp: enforce minimal 128Mb alignment for pc-dimm

[Igor Mammedov <imammedo@redhat.com>]

On Tue, 27 Oct 2015 10:53:08 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Tue, Oct 27, 2015 at 09:48:37AM +0100, Igor Mammedov wrote:
> > On Tue, 27 Oct 2015 10:31:21 +0200
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > 
> > > On Mon, Oct 26, 2015 at 02:24:32PM +0100, Igor Mammedov wrote:
> > > > Yep it's workaround but it works around QEMU's broken virtio
> > > > implementation in a simple way without need for guest side changes.
> > > > 
> > > > Without foreseeable virtio fix it makes memory hotplug unusable and even
> > > > more so if there were a virtio fix it won't fix old guests since you've
> > > > said that virtio fix would require changes of both QEMU and guest sides.
> > > 
> > > What makes it not foreseeable?
> > > Apparently only the fact that we have a work-around in place so no one
> > > works on it.  I can code it up pretty quickly, but I'm flat out of time
> > > for testing as I'm going on vacation soon, and hard freeze is pretty
> > > close.
> > I can lend a hand for testing part.
> > 
> > > 
> > > GPA space is kind of cheap, but wasting it in chunks of 512M
> > > seems way too aggressive.
> > hotplug region is sized with 1Gb alignment reserve per DIMM so we aren't
> > actually wasting anything here.
> >
> 
> If I allocate two 1G DIMMs, what will be the gap size? 512M? 1G?
> It's too much either way.
minimum would be 512, and if backend is 1Gb-hugepage gap will be
backend's natural alignment (i.e. 1Gb).

We always reserve extra 1Gb per slot for max possible alignment so
that we could map 1Gb hugepage aligned. It's over reserve but
we don't know in advance what will be plugged in slot and so we
always reserve max possible alignment.