Re: [Xen-devel] [PATCH 05/15] Nested Virtualization: core

Christoph Egger
Thu, 19 Aug 2010 10:44:54 -0000

On Thursday 19 August 2010 12:38:09 Christoph Egger
wrote:
> On Thursday 19 August 2010 04:46:50 Dong, Eddie wrote:
> > Keir Fraser wrote:
> > > On 18/08/2010 09:27, "Dong, Eddie"
<eddie.dong@intel.com> wrote:
> > >>> +enum nestedhvm_vmexits
> > >>> +nestedhvm_vcpu_vmexit(struct vcpu *v, struct
cpu_user_regs *regs,
> > >>> +   uint64_t exitcode) +{
> > >>
> > >> I doubt about the necessary of this kind of wrapper.
> > >>
> > >> In single layer virtualization, SVM and VMX have its own
handler for
> > >> each VM exit. Only when certain common function is invoked,
the
> > >> control goes from SVM/VMX to common one, because they have
quit many
> > >> differences and the savings by wrapping that function is
really
> > >> small, however we pay with additional complexity in both SVM
and VMX
> > >> side as well as readability and performance. Further more, it
may
> > >> limit the flexibility to implement something new for both
side.
> > >>
> > >> Back to the nested virtualization. I am not fully convinced
we need
> > >> a common handler for the VM_entry/exit, at least not for now.
It is
> > >> basically same situation with above single layer
virtualization.
> > >> Rather we prefer to jump from SVM/VMX to common code when
certain
> > >> common service is requested.
> > >>
> > >> Will that be easier?
> > >
> > > I''m sure there ahs to be conversion-and-demux anyway in
> > > SVM-VMX-specific code. At which point you may as well break out
to
> > > individual common handler functions just where that makes sense,
as
> > > you say. Also I agree this model fits better with what we do in
the
> > > non-nested case.
>
> I see the arch specific code as the backend and the hvm code as the
> frontend. Not the other way around.
>
> The vmentry/vmexit code is invoked from the arch-specific exit code.
> That''s not do-able the other way around due to the way the
hardware works.
> The vmentry/vmexit calls out to arch specific code where access to the
> vmcb/vmcs is needed.
>
> Where I need Eddie''s help is in finding the nuances in the common
> vmentry/vmexit code that prevents him to make the VMX specific code
> working from the algorithm point of view.

Err.. just to make it clear: The need in help from Eddie is not limited to
the common vmentry/vmexit code. This also includes the interfaces
where they don''t fit to VMX, etc.

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