[Xen-devel] [RFC][PATCH] Hypercalls from HVM guests (0/2)

[Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>]

Here is the basic plumbing for hypercalls from HVM guests.  The changes cover
the following:

o Modify VMX VMCALL exit handler to call the generic hvm_hypercall()
o Modify SVM VMMCALL exit handler to safely handle VMMCALL for hvmloader
  else call the generic hvm_hypercall()
o Modify copy_[to/from]_user to use hvm_copy() for hvm guests.  Without
  this the hvm domain gets hung and eventually hangs dom0 as well.  I'm
  guessing that we are in some infinite page fault loop.
o Modify hvmloader to use VMMCALL symbols from vmmcall.h.

With these changes you can make raw hypercalls from HVM guests.  Additional
plumbing for event channels and grant tables will be submitted separately.

Testing included 32/64 bit guests on both VMX hardware and SVM hardware.

Signed-off-by: Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>

Open Issues:

A) 32-bit hypercalls on 64-bit hypervisors

32-bit hypercalls on 64-bit hypervisors will run into trouble due to the
fact that most of the hypercall structures passed through the interface
change layout between 32/64 bits due to the usage of pointers/longs
in the interface structure definitions.

This can be avoided by using explicitly sized types and including explicit
pad fields where needed.  This, along with versioning the structures should
be considered the next time the binary hypervisor interface is changed (4.0?).

For now, 32-bit guests on 64-bit hypervisors need to redefine their interface
structure by hand.  I am working on some automated include file generation
that will take care of this.  Any better ideas are welcome.

B) copy_[to/from]_user calls made to hypervisor VAs.

Today the hypervisor uses copy_[to/from]_user to access hypervisor VAs.
This directly conflicts with accessing those very same address regions
in an HVM guest.  For now we are lucky that inbound hypercalls don't
reference these regions.

C) Removal of old VMCALL/VMMCALL behavior (calling hvm_print_line).

This seemed to be debug code, but I would like confirmation from the list
that this removal is OK.  If not, the interface needs adjusted to coexist
with a full function hypercall interface.

Thanks,
Steve
--
Steve Ofsthun - Virtual Iron Software, Inc.

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