Re: [Xen-devel] page ref/type count overflows

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 26.01.09 15:19 >>>
>On 26/01/2009 14:10, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> But (just having got your second response) if we can do without that ugly
>> cmpxchg8b altogether, then of course this is the much preferred solution.
>> The growing of struct page_info of course isn't very fortunate, but pretty
>> much unavoidable.
>
>I'm having at the cmpxchg8b right now. I'll also widen the fields I guess,
>since that's pretty easy.

The count_info one only, or are you also intending to change _domain?
With struct page_info pretty large already, I'd want to avoid growing it
needlessly.

Partly related to this and partly to the recent heap changes - the need to
constrain the Xen heap to the lower 4G is purely due pickle_domptr(), right?
Wouldn't it make sense to change alloc_domain_struct() then to allocate
a page directly, have pickle_domptr() convert to pfn, and remove the
restriction? Apart from the (auto-ballooning) issues pointed out before, I
realize that such a restriction may make it impossible to create domains
altogether, since there continues to be no way to control what specific
pages can be ballooned out of Dom0 (which as we know has been limiting
the ability to create 32-bit domains).

And in order to possibly buy back the amount the structure will grow now,
wouldn't it make sense to have specialized linked list handling for the
page_info structures that also uses pfn encoding (rather than a full
pointer)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel