On Thursday 19 August 2010 04:46:50 Dong, Eddie wrote:
> Keir Fraser wrote:
> > On 18/08/2010 09:27, "Dong, Eddie" <eddie.dong@xxxxxxxxx> 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.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home