This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: tmem on 4.1 (was [Xen-devel] Re: Freeze schedule)

>>> On 12.01.11 at 19:32, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>> >>> On 11.01.11 at 19:28, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
>> wrote:
>> > After consultation with Keir, here's a revised proposal:
>> >
>> >   Feature submission freeze
>> >   after 31 Dec
>> >
>> >     New feature patches posted before this point can be committed
>> >     afterwards if they needed the time to get into shape.
>> >
>> >     New features not previously posted have missed the boat.
>> Based on 4.0 experience, I'm afraid we'll have to default-disable
>> tmem again for 4.1, since (to my knowledge) there hasn't been
>> much (if any) work to eliminate non-order-0 post-boot allocations.
> I haven't tested it due to other commitments, but didn't someone
> (Tim?) submit a patch to change shadow tables to use order-0,
> and Keir submit a patch to change domain struct to order-0?

alloc_{domain,vcpu}_struct() use order 1, and both containing
one or more instances of cpumask_t this size is configuration

> IIRC, that's not everything... I think passthrough uses order>0
> still... but I assumed the vast majority of the problem was solved.

Yes, pass-through is one violator, domain_create() is another,
all but one allocating d->nr_pirqs sized arrays (the one other
case being even worse in allocating a nr_irqs sized array of
struct timer).

Only the shadow mode case was addressed iirc.


Xen-devel mailing list