Re: [PATCH v4 1/2] XEN/X86: Improve semantic support for x86_init.mapping.pagetable_reserve
From: Attilio Rao
Date: Fri Aug 24 2012 - 06:24:36 EST
On 24/08/12 11:03, Borislav Petkov wrote:
On Thu, Aug 23, 2012 at 06:13:39PM +0100, Attilio Rao wrote:
You seriously think that adding a single-check, that will be
certainly skipped (now), in a boot-time function is going to add any
performance burden?
What you are doing is actively wrong. You suggest that it's fine to
call that function with something different than pgt_buf_start as the
start argument. That's complete nonsense. The early pages are
allocated bottom up beginning at pgt_buf_start. So what the heck would
make it sane to change that argument ever?
If you really don't like this approach, at this point I think the
best thing to do is to assume that the start address will be
pgt_buf_start and loose the starting argument at all.
If you agree I can make a patch for that.
One thing I don't understand is why is xen touching x86 code when it
doesn't have to? At least I cannot find a single reason for it in this
thread.
I really don't understand why you are saying here:
1) Are you implying that xen_mapping_pagetable_reserve() is unnecessary?
2) Are you implying that my patch is unnecessary?
In the 1 case you are wrong becsause it is of course necessary, unless
you have a better way to fix the same bug keeping the same level of
cleaniness. The reasons are reported earlier in the thread, but for
your's sake they are summarized further here:
commit 279b706bf800b5967037f492dbe4fc5081ad5d0f
Author: Stefano Stabellini<stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu Apr 14 15:49:41 2011 +0100
x86,xen: introduce x86_init.mapping.pagetable_reserve
In the case 2 you are wrong again. This is not a XEN-specific patch.
pagetable_reserve() has no documentation and no clear semantic right
now. hpa has asked to document all the kernel hooks, for a reference
look here:
http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000070.html
So I'm sure this is something that is welcome also by Linux community.
Thomas is clearly explaining to you that what you're trying to
enforce cannot happen on baremetal x86 and you're still insisting on
"documenting" that.
I think that foundamentally there is a bit of misunderstanding here.
There were 2 ways to provide a correct semantic:
1) Leave the arguments in place, but taking care to give some formalism
to them
2) Remove the arguments and let handle all the pgt_buf_start,
pgt_buf_end logic within the functions themselves.
Consensus by me, Konrad and Stefano went to case n.1, but now I see that
Thomas has issues with it. I don't agree at all with his objections for
several points:
- Few extra-checks, which are not necessary now but would leave the
function sane in the future, in a boot-time mechanism aren't really a
performance critical issue.
- He says that this function is not going to be used by drivers, but it
is however part of the kernel infrastructure, so you cannot really leave
it unlifted. Besides, Linux doesn't have a formal way to split his
functions into private and public KPI, thus any function can be
considered potentially usable by thirdy-part module (but I'm sure this
is an arguable point)
However, the conclusion is that I respect Thomas authority here and I
will implement approach 2, hoping that he would then consider patch for
inclusion into tips.
Here's a simple answer: if it doesn't fix a bug on x86 baremetal (and
you're changing x86 native code only for the sake of xen), there's no
reason wasting energy to create patches.
You really should read (and understand) patches and e-mail more
carefully before to send such mis-informed responses.
Attilio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/