WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [Xen-devel] [rfc] [patch] more 'long' in the hypervisor interface

On Thu, 2006-06-29 at 10:37 -0400, Steve Ofsthun wrote:
> Chris Wright wrote:
> > * Hollis Blanchard (hollisb@xxxxxxxxxx) wrote:
> > 
> >>We discussed a bit on IRC (developers are welcome to join OFTC #xen),
> >>but to recap for the list...
> >>
> >>PPC will have
> >>    typedef uint64_t xen_ulong_t;
> >>That means that the fields in memory.h will keep the same
> >>size/alignment, whether compiled 32- or 64-bit. This is the way the
> >>interface should have been designed in the first place, but we're locked
> >>into the current ABI on x86. However, since PPC has no current users, we
> >>can define the ABI correctly from the start.
> > 
> > 
> > I see.  I think it would be nice to work on the ABI such that it makes
> > sense for the future 32/64 mixed modes.  So I guess I actually agree
> > with your legacy typedef name ;-)
> 
> X86 32/64 mixed modes really have 2 independent compatibility issues.  One
> is the calling conventions used to pass parameters through the hypercall
> interface.  The second is the format of the data structures passed through
> the calling conventions to the underlying hypervisor.
> 
> Today, we run 32/64 mixed mode HVM guests on a 64 bit hypervisor.  The
> hypercall interface was modified to handle both 32-bit and 64-bit calling
> conventions.  The underlying hypervisor however only supports 64-bit
> structure formats.  A 64-bit guest can continue to use the standard headers
> for passing data to hypercalls.  A 32-bit guest must redefine every structure
> in the public interfaces to properly pass data to the hypervisor.

The work I've been doing should cover most of the userland/hypervisor
interface, i.e. everything in libxc. Since it doesn't affect me
personally right now, I haven't been looking at the kernel/hypervisor
interface, though I certainly support similar changes there.

> We would like to see the 32-bit and 64-bit structure definitions evolve
> to a single size invariant version of the interface structures for both
> 32-bit and 64-bit guests.

Definitely.

> > One issue is that 32-bit userspace effectively has direct access to
> > 64-bit hypercall interface.  This can be handled in the 64-bit kernel by
> > doing compat translation, by having 32-bit compat hypercall interface
> > and jumping to right spot on hypercall page, or by having fixed size
> > structure.  It's not clear to me the value of effectively exposing the
> > ABI all the way to userspace.
> 
> I'm not sure I understand your use of the term 'userspace' here.  Do you
> mean guest kernel mode, or actual unprivileged user code?

Unprivileged user code, specifically applications using libxc.

> > What is the current plan for 32-bit kernel on 64-bit hv?  In this case
> > a 32-bit compat hypercall page might be useful, or having fixed size
> > structure.
> 
> For X86 there are probably two plans.  For paravirtual guests, there is a
> strong desire to formalize the existing ABI.  This will force the 32-bit
> and 64-bit ABIs to remain significantly different.  Since the underlying
> hypervisors don't allow 32/64 mixed mode guests, there is little reason
> to reconcile the two ABIs.  If the ABIs were identical today, you still
> couldn't run mixed mode guests.

Not sure I follow here. Identical ABIs would enable mixed mode guests,
even if the current implementation doesn't support that, right? So that
sounds like a good goal.

> For HVM guests, the ABI is less established.  I'm not sure anyone but us
> (Virtual Iron), is doing much with hypercalls from HVM guests.  We are
> currently running paravirtualized drivers in HVM guests.  As the code
> matures, we will be posting these patches.
> 
> We have had to deal with issues separate from the mechanical ABI issues.
> For example, grant table transfers (used by the standard netfront/netback)
> don't play well with QEMU's one time direct map of the entire HVM guest
> address space.  In addition, the xen support needed by PV drivers is
> specific to later 2.6 kernels.  Getting this code to work on older linux
> kernels requires some additional work.
> 
> > My concern is that we'll never make a clean break if we slowly cobble up
> > the interface with more hacks.  Maybe a forward looking compat interface
> > would be a good breaking point.
> 
> I agree with you on this.  The longer this goes unaddressed, the more work it
> will be to fix.

I think we all agree we should make sure all future interfaces are
correct.

By "forward-looking compat interface", I think Chris means a set of new
hypercall numbers that are written for newly designed fixed-layout data
structures. I'm fine with that.

In this case, it looks like all the do_memory_op() functions (e.g.
increase_reservation()) could be directly called by a new
do_memory_op_compat() function. In other cases, some code reorganization
may be necessary. For example, duplicating do_dom0_op() doesn't look
like fun.

-- 
Hollis Blanchard
IBM Linux Technology Center


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