[PATCH 0 of 4] videoram allocation and stdvga improvements

[PATCH 0 of 4] videoram allocation and stdvga improvements

[Stefano Stabellini]

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>

Re: [PATCH 0 of 4] videoram allocation and stdvga improvements

[Samuel Thibault]

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

Re: [PATCH 0 of 4] videoram allocation and stdvga improvements

[Samuel Thibault]

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

Re: [PATCH 0 of 4] videoram allocation and stdvga improvements

[Keir Fraser]

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

Re: [PATCH 0 of 4] videoram allocation and stdvga improvements

[Stefano Stabellini]

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.

Re: [PATCH 0 of 4] videoram allocation and stdvga improvements

[Samuel Thibault]

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