* Steve Ofsthun (sofsthun@xxxxxxxxxxxxxxx) wrote:
> for passing data to hypercalls. A 32-bit guest must redefine every
> structure
> in the public interfaces to properly pass data to the hypervisor.
Exactly, and that breaks the ABI for normal 32-bit guest on 32-bit
hypervisor. Hence the pain that Hollis is dealing with.
> 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.
Yup, that's same interest that Hollis has. I'm simply suggesting that
mixed mode becomes the vehicle for evolving that interface.
> >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?
Userspace effectively makes hypercalls directly (see privcmd). The
wider the ABI is exposed, the harder it is to make changes.
> >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.
Yes, that's why I suggested compat.
> 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.
Look forward to seeing that.
> 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.
What did you do here? Specifically, how much does the PV driver in HVM
guest diverge from normal PV guest? This will effect merging this code
into Linux which is why I care.
thanks,
-chris
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home