Xen devel - Oct 2010 - conditional clearing of dom0_l2 in i386''s zap_low_mappings() ?

What is the reason for not unconditionally clearing the whole L2
directory here? There shouldn''t be anything in the first Gb that
wasn''t placed there just temporarily by Xen...

Thanks, Jan


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

On 28/10/2010 15:50, "Jan Beulich" <JBeulich@novell.com> wrote:
> What is the reason for not unconditionally clearing the whole L2
> directory here? There shouldn''t be anything in the first Gb that
> wasn''t placed there just temporarily by Xen...
You mean the conditional within the for loop that clears dom0 l2 entries? If
we zapped all of dom0''s l2 entries, we''d also be zapping the
entries
legitimately just created by the dom0 builder!

 -- Keir
> Thanks, Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

>>> On 28.10.10 at 17:30, Keir Fraser <keir@xen.org> wrote:
> On 28/10/2010 15:50, "Jan Beulich" <JBeulich@novell.com>
wrote:
> 
>> What is the reason for not unconditionally clearing the whole L2
>> directory here? There shouldn''t be anything in the first Gb
that
>> wasn''t placed there just temporarily by Xen...
> 
> You mean the conditional within the for loop that clears dom0 l2 entries?
If
> we zapped all of dom0''s l2 entries, we''d also be zapping
the entries
> legitimately just created by the dom0 builder!
Oh, I didn''t look closely enough. I actually just meant all the
entries in the first of the four L2 tables.

Jan


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

On 28/10/2010 16:49, "Jan Beulich" <JBeulich@novell.com> wrote:
>>>> On 28.10.10 at 17:30, Keir Fraser <keir@xen.org> wrote:
>> On 28/10/2010 15:50, "Jan Beulich"
<JBeulich@novell.com> wrote:
>> 
>>> What is the reason for not unconditionally clearing the whole L2
>>> directory here? There shouldn''t be anything in the first
Gb that
>>> wasn''t placed there just temporarily by Xen...
>> 
>> You mean the conditional within the for loop that clears dom0 l2
entries? If
>> we zapped all of dom0''s l2 entries, we''d also be
zapping the entries
>> legitimately just created by the dom0 builder!
> 
> Oh, I didn''t look closely enough. I actually just meant all the
> entries in the first of the four L2 tables.
Oh I see. Well possibly. But you might still need the conditional for the
other three slots anyway, so it wouldn''t be a simplification in that
case.

 -- Keir
> Jan
> 


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

>>> On 28.10.10 at 18:06, Keir Fraser <keir@xen.org> wrote:
> On 28/10/2010 16:49, "Jan Beulich" <JBeulich@novell.com>
wrote:
>>>>> On 28.10.10 at 17:30, Keir Fraser <keir@xen.org>
wrote:
>>> On 28/10/2010 15:50, "Jan Beulich"
<JBeulich@novell.com> wrote:
>>> 
>>>> What is the reason for not unconditionally clearing the whole
L2
>>>> directory here? There shouldn''t be anything in the
first Gb that
>>>> wasn''t placed there just temporarily by Xen...
>>> 
>>> You mean the conditional within the for loop that clears dom0 l2
entries? If
>>> we zapped all of dom0''s l2 entries, we''d also be
zapping the entries
>>> legitimately just created by the dom0 builder!
>> 
>> Oh, I didn''t look closely enough. I actually just meant all
the
>> entries in the first of the four L2 tables.
> 
> Oh I see. Well possibly. But you might still need the conditional for the
> other three slots anyway, so it wouldn''t be a simplification in
that case.
I''m not after a simplification really. I''m trying to eliminate
some
restrictions on initrd size (as well as possible collisions between
the various memory areas used during early boot), and in the
process I need to switch the 1:1 mapping of the first Gb to a
more flexible model (the target is x86-64, but to avoid adding
more conditionals in the Dom0 building code I prefer to do the
same to i386 too).

I was just asking because I may need to flush out temporary
mappings in Dom0''s first L2 that wouldn''t match those under
idle_page_table_l2[0] (though right now I think I may get away
without having to).

Jan


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

On 29/10/2010 07:51, "Jan Beulich" <JBeulich@novell.com> wrote:
>> Oh I see. Well possibly. But you might still need the conditional for
the
>> other three slots anyway, so it wouldn''t be a simplification
in that case.
> 
> I''m not after a simplification really. I''m trying to
eliminate some
> restrictions on initrd size (as well as possible collisions between
> the various memory areas used during early boot), and in the
> process I need to switch the 1:1 mapping of the first Gb to a
> more flexible model (the target is x86-64, but to avoid adding
> more conditionals in the Dom0 building code I prefer to do the
> same to i386 too).
> 
> I was just asking because I may need to flush out temporary
> mappings in Dom0''s first L2 that wouldn''t match those
under
> idle_page_table_l2[0] (though right now I think I may get away
> without having to).
I''d prefer we don''t mess around with the i386 boot process
really. The build
is obsolescent - anyone wanting big initrds should run the 64-bit build of
Xen. Who doesn''t have a 64b processor these days, really?

 -- Keir



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

On 29/10/2010 08:02, "Keir Fraser" <keir@xen.org> wrote:
> On 29/10/2010 07:51, "Jan Beulich" <JBeulich@novell.com>
wrote:
> 
>>> Oh I see. Well possibly. But you might still need the conditional
for the
>>> other three slots anyway, so it wouldn''t be a
simplification in that case.
>> 
>> I''m not after a simplification really. I''m trying to
eliminate some
>> restrictions on initrd size (as well as possible collisions between
>> the various memory areas used during early boot), and in the
>> process I need to switch the 1:1 mapping of the first Gb to a
>> more flexible model (the target is x86-64, but to avoid adding
>> more conditionals in the Dom0 building code I prefer to do the
>> same to i386 too).
>> 
>> I was just asking because I may need to flush out temporary
>> mappings in Dom0''s first L2 that wouldn''t match those
under
>> idle_page_table_l2[0] (though right now I think I may get away
>> without having to).
> 
> I''d prefer we don''t mess around with the i386 boot
process really. The build
> is obsolescent - anyone wanting big initrds should run the 64-bit build of
> Xen. Who doesn''t have a 64b processor these days, really
Oh yes, you''re doing it mainly for x64 I see. Go wild then. :-)

 -- Keir
>  -- Keir
> 
> 


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