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
|
Home