From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: ctfconvert problems with build on illumos based platform Date: Tue, 14 Jan 2014 20:58:11 +0000 Message-ID: <52D5A4E3.1080405@citrix.com> References: <52D5A230.3010005@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3114380352825263795==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Igor Kozhukhov Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============3114380352825263795== Content-Type: multipart/alternative; boundary="------------050807050109070802020105" --------------050807050109070802020105 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 14/01/14 20:52, Igor Kozhukhov wrote: > > On Jan 15, 2014, at 12:46 AM, Andrew Cooper wrote: > >> On 14/01/14 20:38, Igor Kozhukhov wrote: >>> Hello All, >>> >>> I have problems with ctfconvert with build sources of xen-4.2 on >>> illumos based platform: >>> https://www.illumos.org/issues/3205 >>> >>> could you please let me know - what the reason to have a variable in >>> structure 'struct hvm_hw_cpu_xsave' with zero size: >>> struct { char x[0]; } ymm; /* YMM */ >>> -- >>> Best regards, >>> Igor Kozhukhov >>> >>> >> >> The structure is variable length depending on whether the VM has >> enabled AVX support. >> >> It is rather unfortunate that we have non-complient C used to specify >> the ABI. > > can we use here ? > struct { char x[1]; } ymm; > > it will fix my problem. > > -Igor > No, it wont. The 'ymm' is either not present and has a size of 0 as far as save_area is concerned, or is present, and has a size of 16 * 256bit registers. The content of this structure is only relevant as far as hvm_{save,load}_cpu_xsave_states() goes, which resorts to some pointer-trickary to move the data. Changing that char x[0] to char x[1] will break the pointer trickary, and migration will suffer an ABI breakage. ~Andrew --------------050807050109070802020105 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 14/01/14 20:52, Igor Kozhukhov wrote:

On Jan 15, 2014, at 12:46 AM, Andrew Cooper wrote:

On 14/01/14 20:38, Igor Kozhukhov wrote:
Hello All,

I have problems with ctfconvert with build sources of xen-4.2 on illumos based platform:

could you please let me know - what the reason to have a variable in structure 'struct hvm_hw_cpu_xsave'  with zero size:
struct { char x[0]; } ymm;    /* YMM */
--
Best regards,
Igor Kozhukhov



The structure is variable length depending on whether the VM has enabled AVX support.

It is rather unfortunate that we have non-complient C used to specify the ABI.

can we use here ?
struct { char x[1]; } ymm;

it will fix my problem.

-Igor


No, it wont.

The 'ymm' is either not present and has a size of 0 as far as save_area is concerned, or is present, and has a size of 16 * 256bit registers.

The content of this structure is only relevant as far as hvm_{save,load}_cpu_xsave_states() goes, which resorts to some pointer-trickary to move the data.  Changing that char x[0] to char x[1] will break the pointer trickary, and migration will suffer an ABI breakage.

~Andrew
--------------050807050109070802020105-- --===============3114380352825263795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3114380352825263795==--