Re: [Xen-devel] [PATCH] x86: use VMLOAD for PV context switch

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.08.18 at 16:55, <brian.woods@xxxxxxx> wrote:
> On Fri, Aug 17, 2018 at 01:33:43AM -0600, Jan Beulich wrote:
>> >>> On 17.08.18 at 00:04, <brian.woods@xxxxxxx> wrote:
>> > On Tue, Jul 10, 2018 at 04:14:11AM -0600, Jan Beulich wrote:
>> >> Having noticed that VMLOAD alone is about as fast as a single of the
>> >> involved WRMSRs, I thought it might be a reasonable idea to also use it
>> >> for PV. Measurements, however, have shown that an actual improvement can
>> >> be achieved only with an early prefetch of the VMCB (thanks to Andrew
>> >> for suggesting to try this), which I have to admit I can't really
>> >> explain. This way on my Fam15 box context switch takes over 100 clocks
>> >> less on average (the measured values are heavily varying in all cases,
>> >> though).
>> >> 
>> >> This is intentionally not using a new hvm_funcs hook: For one, this is
>> >> all about PV, and something similar can hardly be done for VMX.
>> >> Furthermore the indirect to direct call patching that is meant to be
>> >> applied to most hvm_funcs hooks would be ugly to make work with
>> >> functions having more than 6 parameters.
>> >> 
>> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> > 
>> > I have confirmed it with a senior hardware engineer and using vmload in
>> > this fashion is safe and recommended for performance.  As far as using
>> > vmload with PV.
>> > 
>> > Acked-by: Brian Woods <brian.woods@xxxxxxx>
>> 
>> Thanks. There's another aspect in this same area that I'd like to
>> improve, and hence seek clarification on up front: Currently SVM
>> code uses two pages per CPU, one for host_vmcb and the other
>> for hsa. Afaict the two uses are entirely dis-joint: The host save
>> area looks to be simply yet another VMCB, and the parts accessed
>> during VMRUN / VM exit are fully separate from the ones used by
>> VMLOAD / VMSAVE. Therefore I think both could be folded,
>> reducing code size as well as memory (and perhaps cache) footprint.
>> 
>> I think this separation was done because the PM mentions both
>> data structures separately, but iirc there's nothing said anywhere
>> that the two structures indeed need to be distinct.
> 
> From APM Vol 2
> 
> 15.30.4 VM_HSAVE_PA MSR (C001_0117h)
> The 64-bit read/write VM_HSAVE_PA MSR holds the physical address of a
> 4KB block of memory where VMRUN saves host state, and from which
> #VMEXIT reloads host state. The VMM software is expected to set up this
> register before issuing the first VMRUN instruction. Software must not
> attempt to read or write the host save-state area directly.
> 
> Writing this MSR causes a #GP if:
> ●  any of the low 12 bits of the address written are nonzero, or
> ●  the address written is greater than or equal to the maximum
>    supported physical address for this implementation.
> 
> 
> 
> It seems that the HSA is needed for the state of the guest/host.  I
> don't see how they can be folded in together.  Am I missing something?

Well, as said, the set of elements saved/loaded by VMRUN / #VMEXIT
has nothing in common with the set of elements saved/loaded by
VMSAVE / VMLOAD.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel