From: Christoph Egger <Christoph.Egger@amd.com>
To: "Dong, Eddie" <eddie.dong@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [PATCH 05/15] Nested Virtualization: core
Date: Thu, 19 Aug 2010 12:38:09 +0200 [thread overview]
Message-ID: <201008191238.10341.Christoph.Egger@amd.com> (raw)
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B22A3E5C0B@shsmsx501.ccr.corp.intel.com>
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.
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
next prev parent reply other threads:[~2010-08-19 10:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 8:27 [PATCH 05/15] Nested Virtualization: core Dong, Eddie
2010-08-18 8:36 ` Keir Fraser
2010-08-19 2:46 ` Dong, Eddie
2010-08-19 10:38 ` Christoph Egger [this message]
2010-08-19 10:44 ` Christoph Egger
-- strict thread matches above, loose matches on Subject: below --
2010-06-03 16:09 Christoph Egger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201008191238.10341.Christoph.Egger@amd.com \
--to=christoph.egger@amd.com \
--cc=eddie.dong@intel.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.