RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps

[Alex Williamson <alex.williamson@xxxxxx>]

Hi Eddie,

On Tue, 2008-03-11 at 06:43 +0800, Dong, Eddie wrote:
> Alex Williamson wrote: 
> >    In your slide set, you mention removing running_on_xen since it
> > conflicts with pv_ops.  I think this is a really good goal, but I
> have
> > doubts about whether it's achievable.  We're not likely to make a
> 
> My assumption is that Linux maintainer won't expect to see 
> running_on_xen, running_on_kvm, running_on_lguest, 
> running_on_hybrid_xen, running_on_hybrid_kvm etc. It is too ugly.
> 
> But if you mean we keep it temporary for now, I am fine. 

   Right, it's a pretty lightweight test to keep around for now, and
maybe we can eventually remove it completely.  However, we might end up
with something that only one VMM cares about and need to keep it around.
If all the VMMs are tripping on the same issue, then we can upgrade it
or integrate it into a pv_op.

> > pv_ops to fit every corner case, and we may have to resort to an
> ugly
> > direct test for xen.  Let's try to avoid them, but we already have a
> > few cases of checking machine vector names for this type of thing in
> > other parts of the ia64 code.  Thanks,
> 
> Could you point me to the code that you feel pv_ops may be hard here?

  I don't have any architecture specific examples off the top of my
head, but how about skipping serial port detection on dom0?  It's rather
Xen specific and we haven't yet come up with a way to hide Xen's UART
(ioport & mmio) from dom0.  KVM/Lguest wouldn't care about this, so it
may not be worthy of a pv_op.  Thanks,

        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


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