(1) and (2): I want to kill off use of vcpu_guest_context in dom0 tools,
make hvm save/restore a generic state load/save interface, and define
extensible structures at that interface (pass a stream of state chunks back
and forth at the interface, each chunk having a size in its header, and so
increasing the size of a chunk allows it to be naturally appended to and
hence extended).
(3) Bump the XEN_INTERFACE_VERSION, rename current CALLBACKTYPE_sysenter to
a compat name, and introduce new define for CALLBACKTYPE_sysenter with
proper native semantics.
-- Keir
On 21/6/07 09:10, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> Being in the process of trying to enable sysenter/syscall use from compat mode
> guests and compat mode apps in native guests (for performance to a certain
> degree, but more importantly - at least for the compat mode app case - to get
> closer to native behavior, i.e. mid/long term requiring less kernel
> modifications)
> I'm facing a few backwards compatibility issues that I'm not really sure how
> to
> deal with:
>
> 1) Obviously I need to extend the guest_context structure (to store the
> additional callback addresses), but there do not seem to be provisions to do
> so without breaking the dom0 interface. I'm currently considering adding a
> flag indicating use of the larger structure, but this certainly doesn't scale
> well
> considering future additions. An alternative might be to add a single flag
> covering all future additions, and using the first field past the current size
> to
> store the overall or add-on size, so that the hypervisor has a way to know
> how much of the structure to copy.
>
> 2) While the x86-32 hv can't support syscall and is unlikely to support
> sysenter,
> save/restore/migration (which hopefully will work at least from 32-bit hv to
> 64-bit hv in the future) imposes an issue here in that native wouldn't need
> these extra fields, but a compat mode guest would have to have a way to
> store them (in compat mode format), implying that guest_context would also
> need to be extended for 32-bits.
>
> 3) Currently, the 32-bit kernel check X86_FEATURE_SEP and the return
> status of setting the sysenter hypercall, to detect its availability when run
> in supervisor mode. This, however, is being done only on the boot CPU,
> which works thanks to a quirk in how Xen handles the hypercall - MSRs for
> all CPUs get set by this single call, which clearly doesn't match native
> behavior (where in theory all CPUs could have distinct settings and have
> to establish them as they come up). The problem with this is that if things
> turn out to work as intended, X86_FEATURE_SEP will be seen enabled by
> the guest when run on a 64-bit hv, and setting the sysenter callback will
> also succeed, but existing guests will fail to set the callback on all CPUs.
> I have to admit that I'm rather reluctant to add the same kind of quirk for
> !supervisor_mode_kernel in the hypervisor's handling of CALLBACK_sysenter.
>
> Thanks for suggestions/opinions,
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home