Stefano Stabellini
2009-Jan-13 12:17 UTC
[Xen-devel] [PATCH 0 of 4] videoram allocation and stdvga improvements
Hi all, now the videoram is allocated by hvmloader, that takes care of communicating to qemu the address where the videoram is allocated, writing to a xen_platform ioport. The situation gets more complicated when we let the user configure the amount of videoram to give to the guest: hvmloader has to read the videoram size from xen_platform, allocate the videoram and write the address back to xen_platform. In order to simplify the codepath and the libxc API, this patch series removes the videoram allocation code from hvmloader and lets qemu do the job, using xc_domain_memory_populate_physmap. After this change I ported the "stdvga improvements" patches by Trolle to this new videoram allocation system: the changes are few, mainly to set_vram_mapping. The series consists of 4 patches: PATCH 1 of 4: populate guest videoram this patch applies to xen-unstable and removes the videoram allocation code from hvmloader, it also moves hvmloader memory base from 0xff000000 to 0xfc000000. PATCH 2 of 4: ioemu: populate guest videoram this patch applies to qemu-xen-unstable and implements the new way of populating the videoram in the guest and mapping it in qemu. Initially the videoram is populated at the address 0xff000000 in guest memory address space. PATCH 3 of 4: stdvga improvements this patch is the "stdvga improvements" patch to xen-unstable without any change to hvmloader (they are not needed any more). It also moves the xc_hvm_build special pages top address from 0x100000 to 0xff000, to leave more room for the videoram. PATCH 4 of 4: ioemu: stdvga improvements this patch is the "stdvga improvements" patch to qemu-xen-unstable with the due changes for the new videoram allocation system. Best Regards, Stefano Stabellini Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Samuel Thibault
2009-Jan-13 14:01 UTC
Re: [Xen-devel] [PATCH 0 of 4] videoram allocation and stdvga improvements
Stefano Stabellini, le Tue 13 Jan 2009 12:17:47 +0000, a écrit :> In order to simplify the codepath and the libxc API, this patch series > removes the videoram allocation code from hvmloader and lets qemu do the > job, using xc_domain_memory_populate_physmap.That''s what it was doing before I made hvmloader do it. The reason was to make save/restore work fine with stubdomains dirty log, etc. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Samuel Thibault
2009-Jan-13 14:31 UTC
Re: [Xen-devel] [PATCH 0 of 4] videoram allocation and stdvga improvements
Samuel Thibault, le Tue 13 Jan 2009 15:01:08 +0100, a écrit :> Stefano Stabellini, le Tue 13 Jan 2009 12:17:47 +0000, a écrit : > > In order to simplify the codepath and the libxc API, this patch series > > removes the videoram allocation code from hvmloader and lets qemu do the > > job, using xc_domain_memory_populate_physmap. > > That''s what it was doing before I made hvmloader do it. The reason was > to make save/restore work fine with stubdomains dirty log, etc.Ah, now I remember the precise reason, written in the 18383 changelog: When creating an HVM domain, if e.g. another domain is created before qemu allocates video memory, the extra 8MB memory ballooning is not available any more, because it got consumed by the other domain. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jan-13 14:45 UTC
Re: [Xen-devel] [PATCH 0 of 4] videoram allocation and stdvga improvements
On 13/01/2009 14:31, "Samuel Thibault" <samuel.thibault@ens-lyon.org> wrote:>> That''s what it was doing before I made hvmloader do it. The reason was >> to make save/restore work fine with stubdomains dirty log, etc. > > Ah, now I remember the precise reason, written in the 18383 changelog: > > When creating an HVM domain, if e.g. another domain is created before > qemu allocates video memory, the extra 8MB memory ballooning is not > available any more, because it got consumed by the other domain.That explains why HVM guests were starting up with an 8MB memory overhead and yet were allocating video memory out of their ordinary RAM allocation. :-) Hmmm then perhaps it makes sense to have hvmloader continue to allocate the framebuffer. It can attempt to allocate fresh memory, and it can fall back to relocating ordinary RAM pages if allocations fail (hvmloader has the capability to relocate pseudophys pages now!). I''ll talk to Stefano some more about it.... Thanks, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2009-Jan-14 19:00 UTC
Re: [Xen-devel] [PATCH 0 of 4] videoram allocation and stdvga improvements
Samuel Thibault wrote:> Samuel Thibault, le Tue 13 Jan 2009 15:01:08 +0100, a écrit : >> Stefano Stabellini, le Tue 13 Jan 2009 12:17:47 +0000, a écrit : >>> In order to simplify the codepath and the libxc API, this patch series >>> removes the videoram allocation code from hvmloader and lets qemu do the >>> job, using xc_domain_memory_populate_physmap. >> That''s what it was doing before I made hvmloader do it. The reason was >> to make save/restore work fine with stubdomains dirty log, etc. > > Ah, now I remember the precise reason, written in the 18383 changelog: > > When creating an HVM domain, if e.g. another domain is created before > qemu allocates video memory, the extra 8MB memory ballooning is not > available any more, because it got consumed by the other domain. >The current design of the autoballoner is limited, as a consequence the autoballoner is racy and it should not be used at all if the user plans to start multiple domains at the same time. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Samuel Thibault
2009-Jan-14 22:19 UTC
Re: [Xen-devel] [PATCH 0 of 4] videoram allocation and stdvga improvements
Stefano Stabellini, le Wed 14 Jan 2009 19:00:38 +0000, a écrit :> Samuel Thibault wrote: > > > Samuel Thibault, le Tue 13 Jan 2009 15:01:08 +0100, a écrit : > >> Stefano Stabellini, le Tue 13 Jan 2009 12:17:47 +0000, a écrit : > >>> In order to simplify the codepath and the libxc API, this patch series > >>> removes the videoram allocation code from hvmloader and lets qemu do the > >>> job, using xc_domain_memory_populate_physmap. > >> That''s what it was doing before I made hvmloader do it. The reason was > >> to make save/restore work fine with stubdomains dirty log, etc. > > > > Ah, now I remember the precise reason, written in the 18383 changelog: > > > > When creating an HVM domain, if e.g. another domain is created before > > qemu allocates video memory, the extra 8MB memory ballooning is not > > available any more, because it got consumed by the other domain. > > > > The current design of the autoballoner is limited, as a consequence the > autoballoner is racy and it should not be used at all if the user plans > to start multiple domains at the same time.The problem is that with stubdomain-based qemu you _always_ start multiple domains at the same time. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel