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]_guest to use hvm_copy() for hvm guests. Without this the hvm domain gets hung and eventually hangs dom0 as well. o Modify hvmloader to use VMMCALL symbols from vmmcall.h. With these changes you can make raw hypercalls from HVM guests. Testing included 32/64 bit guests on both VMX hardware and SVM hardware. Signed-off-by: Steve Ofsthun <sofsthun@virtualiron.com> Steve -- Steve Ofsthun - Virtual Iron Software, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21 Apr 2006, at 19:13, Steve Ofsthun wrote:> With these changes you can make raw hypercalls from HVM guests.You probably want a separate hypercall table from that of paravirtualized guests, for several reasons: 1. Some hypercalls will not be HVM aware and are probably unsafe to run from an HVM context 2. Some hypercalls may want different implementations (or at least a wrapper) on HVM 3. On 64-bit, you may even want a separate 32-bit hypercall table containing wrappers that interface between 32-bit callers and the core 64-bit hypercall functions. (1) is most important right now -- we should only permit the hypercalls we need, and audit any others before they are added to the list. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> > On 21 Apr 2006, at 19:13, Steve Ofsthun wrote: > >> With these changes you can make raw hypercalls from HVM guests. > > You probably want a separate hypercall table from that of > paravirtualized guests, for several reasons: > 1. Some hypercalls will not be HVM aware and are probably unsafe to run > from an HVM contextWhich hypercalls in particular should be excluded from HVM use? A number will require changes to perform properly for HVM guests. This work will require this patch. In particular, follow on patches for grant table operations, event channel operations, and memory operations all require this initial groundwork. Are you concerned that enabling this patch will make the hypervisor more vulnerable in some way? Shouldn''t the hypervisor interface be made robust enough to deal with HVM guests (as well as malfunctioning paravirtualized guests)? If it is just a matter of testing, I could filter all HVM requests for now and only allow requests through that have been exercised. As additional patches are submitted, we could enable new hypercalls to be passed through the HVM interface.> 2. Some hypercalls may want different implementations (or at least a > wrapper) on HVMIf this becomes necessary, it can be added to the interface.> 3. On 64-bit, you may even want a separate 32-bit hypercall table > containing wrappers that interface between 32-bit callers and the core > 64-bit hypercall functions.At the moment, all of this can be dealt with in HVM DomU code. By doing it there, we can avoid explicit parameter copying on every hypercall. The 32-bit vs. 64-bit hypercall interface variations are not unique to HVM code. Adding conversion interfaces in the hypervisor is only one solution to this problem. The interfaces themselves could be made size invariant. Except for backward compatibility, the 32-bit interfaces could be made identical to the 64-bit interfaces using proper data typing and explicit data alignment.> (1) is most important right now -- we should only permit the hypercalls > we need, and audit any others before they are added to the list.OK, is a bitmap filter of the inbound requests sufficient? For this patch, I''ll just filter every hypercall except HYPERVISOR_xen_version() and return ENOSYS? Steve -- Steve Ofsthun - Virtual Iron Software, Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22 Apr 2006, at 16:16, Steve Ofsthun wrote:>> (1) is most important right now -- we should only permit the >> hypercalls we need, and audit any others before they are added to the >> list. > > OK, is a bitmap filter of the inbound requests sufficient? For this > patch, I''ll > just filter every hypercall except HYPERVISOR_xen_version() and return > ENOSYS?That would be okay, but also: 1. VMMCALL_MAGIC needs to go, and be replaced by a first-class hypercall (HYPERVISOR_hvm_op maybe). Either by having an hvm-specific hypercall table, or by adding to the main jump table and have the hvm_op function itself bail on non-hvm guests. 2. guest_handle_okay() should always return TRUE for an hvm guest 3. get rid of the __user modifiers in your new functions in guest_access.h. We don''t use those in Xen (except in a few files taken fairly directly from Linux). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 2006-04-22 at 11:16 -0400, Steve Ofsthun wrote:> > > 3. On 64-bit, you may even want a separate 32-bit hypercall table > > containing wrappers that interface between 32-bit callers and the > core > > 64-bit hypercall functions. > > At the moment, all of this can be dealt with in HVM DomU code. By > doing it > there, we can avoid explicit parameter copying on every hypercall. > The 32-bit > vs. 64-bit hypercall interface variations are not unique to HVM code. > Adding > conversion interfaces in the hypervisor is only one solution to this > problem. > The interfaces themselves could be made size invariant. Except for > backward > compatibility, the 32-bit interfaces could be made identical to the > 64-bit > interfaces using proper data typing and explicit data alignment.Sounds like a good idea to me... ;) -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel