Re: [Xen-ia64-devel] Time for hybrid virtualization?

[Alex Williamson <alex.williamson@xxxxxx>]

Hi all,

   Lots of really good discussion, thanks!  At this point, I don't see a
need to remove any of the PV guest interfaces or in any way prevent
running PV domains.  I'm looking at the hybrid approach more as a means
to get support upstream with fewer, less intrusive changes to the base
Linux kernel.  Xen started from a fully PV approach because that was the
processor technology at the time.  Now that VT is here and performs as
well as PV, at least on ia64, I think we might need to step back and
figure out where PV makes sense.  Can we, in good conscience, try to
push patches supporting PV dom0/domU into upstream Linux when it only
buys us a couple percent (if that) over much less intrusive patches?
There's obviously some need for support on non-VT capable processors
today, but will those needs exist in a few years or will the code to
support them just become cruft in the kernel?  In my mind, starting with
a requirement of VT doesn't preclude adding PV interfaces later to
support non-VT processors if it's still necessary.  I would expect
RHEL5.x will always support a PV dom0 and not require VT processors for
Xen.

   I think Anthony and I are thinking similarly about what a VT mode
dom0 might look like.  The processor would run in VT mode, but have
direct access to hardware, make use of the platform firmware, and
maintain things like event channels and balloon drivers from PV-type
code.  I think the emphasis would be on using common PV code shared with
other architectures and using VT to reduce the code changes required for
architecture code.  Anthony mentioned platform detection could be done
with CPUID, but there are even easier methods like changing the OEM ID
on ACPI tables.  Intercepting firmware calls looks like an area that
would need some new code, but I don't see any insurmountable problems
there.  I think with hybrid virtualization, we could treat the ia64
specific boot code as if we were running on any other DIG64 compliant
system, and PV-type functionality will get added later in a more
plug-able, modular way.

   More benchmarking and performance analysis would be nice, but PV
interfaces can always be added later where it makes sense and can be
well architected.  We also need to think about what functionality we
might lose.  Driver domains come to mind here.  PV driver domains aren't
exactly safe today, would it be any worse if we tried to do PCI
pass-through before we get VT-d?  We also don't currently have HVM
domain migration, but that seems like a short term problem.

   I think we all recognize that getting upstream Linux support for
Xen/ia64 is going to be a huge amount of work.  We imagined the steps to
achieve this would start with PV domU support, then follow-on with PV
dom0 support.  With this hybrid approach, I think we would start with VT
mode dom0, then consider whether to implement a PV domU or dom0 as the
follow-on.  We would need to make some changes in Xen to support dom0 VT
mode, but is it more than the effort required to re-architect xenlinux
into something acceptable to upstream?  Which is better long term for
Linux?  In the end, it's a community decision on how we proceed, I
certainly can't do this work on my own.  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