All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Dong, Eddie" <eddie.dong@intel.com>
Subject: Re: [PATCH 03/14] Nested Virtualization: data structure
Date: Tue, 17 Aug 2010 12:02:41 +0100	[thread overview]
Message-ID: <C8902AE1.1E231%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <201008171248.37216.Christoph.Egger@amd.com>

On 17/08/2010 11:48, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> All of this is possible but a union is actually only needed if you want
> to access svm or vmx specific data from common code which is
> bad from the software engineering side.
> The advantage of using a pointer is that gcc can point you to
> such a mistake.
>
> In svm/vmx code you don't need explicit casts with a pointer.
> Have a look at the top of the nsvm_vmcb_prepare4vmrun() function
> in the nh_svm patch. There you see how I access 'struct nestedsvm'
> w/o a cast.

Hm, I see. Well that's okay I guess. Two further comments then, by the by:
(1) Not sure why you hide it behind macro VCPU_NESTEDHVM(). That seems quite
pointless and you may as well reference v->...nh_arch directly. Apart from
that I don't like capitalised macros much anyway. If you must keep a macro
(why?) then at least don't capitalise it.
(2) No text speak in function names please. I get fed up enough with
blah2blah for conversion functions. Don't bring the numeral 4 into the fray
as well. This function would be just as clear with the '4' changed to '_'.

>> What is the nh_arch_size field for? Well I can guess what it represents,
>> but why do you need such a thing?
> 
> It's purpose is to allow to copy svm/vmx specific data to somewhere else
> w/o knowing them.

Yeah, it's pointless then. Noone's going to want to copy gobs of anonymous
arcbitrary vcpu-specific data.

 -- Keir

> It is currently nowhere needed. Once it turns out
> it is neither needed for VMX it can go away.

  reply	other threads:[~2010-08-17 11:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1A42CE6F5F474C41B63392A5F80372B2291436DC@shsmsx501.ccr.corp.intel.com>
2010-08-17  7:47 ` [PATCH 03/14] Nested Virtualization: data structure Dong, Eddie
2010-08-17  8:03   ` Keir Fraser
2010-08-17 10:01     ` Christoph Egger
2010-08-17 10:28       ` Keir Fraser
2010-08-17 10:48         ` Christoph Egger
2010-08-17 11:02           ` Keir Fraser [this message]
2010-08-05 15:00 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=C8902AE1.1E231%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=Christoph.Egger@amd.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 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.