qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] pc: memhotplug: rise minimum DIMM addr/size ali


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH] pc: memhotplug: rise minimum DIMM addr/size alignment to 128Mb
Date: Mon, 21 Sep 2015 15:32:31 +0200

On Mon, 21 Sep 2015 15:13:17 +0200
Paolo Bonzini <address@hidden> wrote:

> 
> 
> On 21/09/2015 15:05, Igor Mammedov wrote:
> >> > To some extend, enforcing natural alignment would be okay as a
> >> > workaround for the virtio bug as well.  It would also make it easier to
> >> > ensure that hotplugged hugetlbfs-backed memory can use hugepages in the
> >> > guest.  Does it make sense to you?
> > in current machine types we already enforce backend-s address/size 
> > alignment,
> > which is file's page size for hugetlbfs-backed memory and 2Mb for RAM 
> > backend.
> 
> Right, but it's not enough if the guest's physical address is not
> aligned to 2Mb/1Gb too.  This is why we changed i440FX and q35 to have
> only 3 and 2 gigabytes of low memory (down from 3.5 and 2 IIRC).
DIMM's GPA is aligned to backend's alignment since 2.2,
it should be aligned 2Mb/1Gb depending on what hugetlbfs file is used
so that already works as expected

> 
> > So I guess we could try to apply workaround to virtio on guest side,
> > aligning and limiting max buffer size to 2Mb, it should work for 'old'
> > machine types as well.
> 
> That would make sense and it would be complementary to natural alignment
> of DIMMs in the host.  This would give:
> 
>       host    guest
>       old     old     fails
>       old     new     works (virtio workaround)
>       new     old     works (natural alignment)
            + not sure if it would work,
              I've though that virtio refactoring, that drops requirement
              for buffer to be inside of only one MemoryRegion, would 
              touch virtio in QEMU and on guest side too.

>       new     new     works (choose your favorite workaround)
> 
> Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]