Re: [PATCH 06/16] vmx: nest: handling VMX instruction exits

[Christoph Egger <Christoph.Egger@amd.com>]

On Wednesday 15 September 2010 09:31:13 Keir Fraser wrote:
> On 15/09/2010 07:49, "Dong, Eddie" <eddie.dong@intel.com> wrote:
> >> What is wrong with simply extending x86_emulate to handle these
> >> VMX-related instructions? We've dealt with emulators provided by
> >> Intel guys in the past and frankly they were full of holes.
> >
> > Certainly fine to move those VMX instruction emulation to hvm/emulate.c
> > as if you don't think that is VMX specific :)
>
> It's the right place to put all instruction emulation, if at all possible.
> You will then presumably require at least one or two call-back hooks to
> caller context, at least to read/write VMCS, and that would be the place to
> determine whether these VMX instructions are executable. For example, SVM
> and PV emulation contexts would either leave the VMX callback hooks as
> NULL, and/or there will be checks for is-nested-VMX-guest in the VMX
> callback hooks, injecting #UD otherwise.
>
> The main trick with x86_emulate extensions is determining the correct neat
> small set of callback hooks to add, which is somewhat driven by deciding
> what should be emulated within x86_emulate and what should be left without
> for implementation in the caller's context.

There is a case where the host must emulate an instruction of the l2 guest
when the l1 guest doesn't intercept it.

When the vcpu is in guest mode, the fields in struct hvm_vcpu and
guest_cpu_user_regs() represent the l2 guest state in my patch series.

That way the instruction emulator works out-of-the box.
You need to add instructions to the emulator that are missing there.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632