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

[Brian Woods <brian.woods@amd.com>]

On Fri, Aug 17, 2018 at 01:33:43AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 00:04, <brian.woods@amd.com> 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@suse.com>
> > 
> > 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@amd.com>
> 
> 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.
> 
> Jan

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?

-- 
Brian Woods

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