Xen devel - Apr 2005 - RE: Xen/ia64 presentation

> It is a bit scary that IA64 assembly is so difficult that HP Research
> doesn''t want to touch it with a 10-foot pole. ;)
That''s what compilers are for :-)  Actually, it''s not the
assembly
I''m afraid of, it''s assembly that''s been
hand-optimized because
the code is so performance-critical.
 
> Actually I''m a bit surprised that you can reuse Linux assembly so
> easily. Exception vectors are exactly one of the places I would expect
> hypervisor code to differ the most from OS code.
Since ia64 (and even VTi as far as I know) doesn''t have the
sophisticated
exception vector reflection capabilities that ppc has, and because
most exceptions are relatively low frequency, a lot of the
reused code is just for getting to the point where C can be called.
Yes, this can be rewritten since it is not performance critical;
but we tried that in vBlades and it was a bear to maintain (especially
compared with using code from Linux that just works).
> But at what cost? It is not direct leverage -- you need look 
> no further
> than xen/arch/ia64/patch/ for evidence of that.
If you are pointing out that I''ve overdone it, I plead guilty.
I''ve been meaning to clean up the worst patch offenders for some time.
Once those are fixed, there should be more files reused than
total patch lines.
> And even with the
> patching, the result is inconsistent at best; for example, "struct
> pt_regs" used in Linux code and "struct xen_regs" used in
native Xen
> code. That really hurts readability and maintainability. And 
> unless you
> run through the IA64 patch process, tools like cscope won''t 
> even see all
> that Linux code.
Agreed, but this is just a tug-of-war on the API showing up in syntax.
> I''m all about the portability, but it may turn out that the 
> architecture
> API is drawn at a different level in a hypervisor than in an 
> OS. I think
> that''s something we should see for ourselves, rather than 
> copying Linux
> verbatim.
> 
> Don''t get me wrong; I definitely think Linux is an excellent model
for
> portable systems code. But it is just that -- a model.
A model which is better than the previous alternative, which was
(no offense intended, just being glib) "make it work for x86 and
fix it up in other arch''s".
 
> Oh absolutely, but I think you''re doing a lot more than just
looking.
> When I want to know how something works, Linux code is at the 
> top of my
> reading list, but having looked I can then implement it myself. Being
> able to copy/paste/modify isn''t a requirement IMHO.
Looking at it and implementing it yourself is fine once the Linux
code is stable.   But if it is evolving, you may find yourself falling
behind code that is a lot better staffed and maintained.
 
> Maybe it''s just me, but I find the Xen/ia64 code confusing 
> enough that I
> wouldn''t call it just a little aesthetics... :)
Guilty again of not cleaning up fast enough :-)
 
> I''ve had the same thought actually... an "exec_domain"
is really a
> virtual CPU state, and having a separate vcpu_info_t is 
> rather confusing.
> 
> However, I don''t think it helps things to go renaming core 
> structures in
> arch code because it sounds better... :)
Just explaining the past, not defending the future.

Looks like more discussion is flowing in, so I will cut my reply
off here.

Dan

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