public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
To: Paul Turner <pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	avi-atKUWr5tajDk1uMJSBkQmQ@public.gmane.org
Subject: Re: [PATCH] move structures to svm/vmx.c, use untyped arch_data in independent code
Date: Wed, 18 Jul 2007 21:40:19 -0500	[thread overview]
Message-ID: <469ECF13.6050004@codemonkey.ws> (raw)
In-Reply-To: <ed628a920707181849h603b5741nf5dfe2c5ea43e9a6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Paul Turner wrote:
>> >> > +     struct vmcs *vmcs;
>>
>> +     struct kvm_vcpu vcpu;
>>
>
> In this approach you might as well embed that at the start so that the
> arch independent code can still allocate/free, that or move the memory
> alloc/dealloc entirely to the arch specific code.  Although that
> should probably be done anyway with this approach otherwise it's not
> clear exactly what is occurring from the arch independent code path's
> pov.

If it's not too much churn, I'd think that allocating the vcpu structure 
in the arch dependent code would make the most sense since it's that 
code that knows how large the structure should be.

>> >> >   #define IOPM_ALLOC_ORDER 2
>> >> >   #define MSRPM_ALLOC_ORDER 1
>> >> >
>> >> > @@ -95,7 +115,7 @@ static inline u32 svm_has(u32 feat)
>> >> >
>> >> >   static unsigned get_addr_size(struct kvm_vcpu *vcpu)
>> >> >   {
>> >> > -     struct vmcb_save_area *sa = &vcpu->svm->vmcb->save;
>> >> > +     struct vmcb_save_area *sa = &svm(vcpu)->vmcb->save;
>>
>> I think this needs to be:
>>
>> struct kvm_svm_data *svm = kvm_vcpu_to_svm_data(vcpu);
>> struct vmcb_save_area *sa = &svm->vmcb->save;
>>
>> The rest should just follow the same style.
>
> Motivating reason?

Clarity on the part of the reader.  The problem with using a macro like 
this is that it's not very clear in this function what the type of 
svm(vcpu) is.  There's also a bit of magic as to how svm() gets the 
whatever the type is from a vcpu.  Not to mention the fact that svm() is 
a horrible function name :-)

By using the typeX_to_typeY idiom, it's very clear to the reader what's 
going on.  It's just another embedded structure who's conversion 
function is container_of() based.

Regards,

Anthony Liguori

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

  parent reply	other threads:[~2007-07-19  2:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-19  0:04 [PATCH] move structures to svm/vmx.c, use untyped arch_data in independent code Paul Turner
     [not found] ` <Pine.LNX.4.64.0707181656540.4769-hxTPNdr267xSzHKm+aFRNNkmqwFzkYv6@public.gmane.org>
2007-07-19  0:12   ` Anthony Liguori
     [not found]     ` <469EAC5A.2070900-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-07-19  0:17       ` Paul Turner
     [not found]         ` <ed628a920707181717t33f95f15v1919bbde0c656cd5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-07-19  0:18           ` Paul Turner
2007-07-19  1:15           ` Anthony Liguori
     [not found]             ` <469EBB26.5080106-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-07-19  1:49               ` Paul Turner
     [not found]                 ` <ed628a920707181849h603b5741nf5dfe2c5ea43e9a6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-07-19  2:40                   ` Anthony Liguori [this message]
     [not found]                     ` <469ECF13.6050004-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>
2007-07-19  8:33                       ` Avi Kivity
2007-07-19  8:30                   ` Avi Kivity
2007-07-19  8:26       ` Avi Kivity

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=469ECF13.6050004@codemonkey.ws \
    --to=anthony-rdkfgonbjusknkdkm+me6a@public.gmane.org \
    --cc=avi-atKUWr5tajDk1uMJSBkQmQ@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    /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