[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 03/14] Nested Virtualization: data structure



On 17/08/2010 11:48, "Christoph Egger" <Christoph.Egger@xxxxxxx> 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.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.