From: Christoph Egger <Christoph.Egger@amd.com>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Dong, Eddie" <eddie.dong@intel.com>
Subject: Re: [PATCH 07/14] Nested Virtualization: trap
Date: Mon, 23 Aug 2010 18:03:01 +0200 [thread overview]
Message-ID: <201008231803.01394.Christoph.Egger@amd.com> (raw)
In-Reply-To: <20100819143056.GH20252@whitby.uk.xensource.com>
On Thursday 19 August 2010 16:30:56 Tim Deegan wrote:
> At 14:53 +0100 on 19 Aug (1282229594), Dong, Eddie wrote:
> > I see the real
> > code start from "exitcode = nestedhvm_exception2exitcode(trapnr);"
> > (half of this function code is just for wrapper check.). The real work
> > is ~20LOC. However we added at least 2 new wrapper APIs:
> > nestedhvm_exception2exitcode & nestedhvm_exception2exitcode.
>
> That's one. :) And it wouldn't be needed if the call to arch-specific
> code to cause a vmexit and the test for interception took trapnr
> directly (which they probably could).
>
> If the new namespace of vmexit codes goes away entirely, that's fine by
> me, btw.
Using namespace is the C-way to "define" a class and prevents
namespace pollution for other things in the future.
> Maybe the generic code can pass exit codes as opaque numbers,
> with a few flags to steer it? Christoph, what do you think? You'll
> have the best idea of how useful the new namespace is.
Look at the nh_structdata patch, you find a nh_forcevmexit structure
within nestedhvm. It contains the generic exit code and additional
information for the conversion and the vmexit injection code in exitinfo1
and exitinfo2. The meanings of exitinfo1 and exitinfo2 are directly related
to the generic exitcode in use and are described in the nh_core patch
in the C comments within the enum nestedhvm_intercepts.
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-23 16:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1A42CE6F5F474C41B63392A5F80372B22A3E5B97@shsmsx501.ccr.corp.intel.com>
2010-08-19 2:44 ` [PATCH 07/14] Nested Virtualization: trap Dong, Eddie
2010-08-19 8:35 ` Tim Deegan
2010-08-19 10:32 ` Christoph Egger
2010-08-19 14:12 ` Dong, Eddie
2010-08-19 13:53 ` Dong, Eddie
2010-08-19 14:30 ` Tim Deegan
2010-08-23 3:12 ` Dong, Eddie
2010-08-31 10:34 ` Tim Deegan
2010-08-23 16:03 ` Christoph Egger [this message]
2010-08-05 15:02 Christoph Egger
2010-08-09 12:44 ` Tim Deegan
2010-08-10 8:55 ` Christoph Egger
2010-08-10 10:48 ` Tim Deegan
2010-08-10 12:25 ` Christoph Egger
2010-08-10 12:56 ` Tim Deegan
2010-08-10 13:37 ` 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=201008231803.01394.Christoph.Egger@amd.com \
--to=christoph.egger@amd.com \
--cc=Tim.Deegan@citrix.com \
--cc=eddie.dong@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).