Xen devel - Nov 2011 - [PATCH 0/6] IOMMU, vtd and iotlb flush rework (v8)

In one of my previous email I detailed a bug I was seeing when passing
through a Intel GPU on a guest that has more that 4G or RAM.

Allen suggested that I go for the Plan B but after a discussion with Tim
we agreed that Plan B was way to disruptive in term of code change.

This patch series implements Plan A.

http://xen.1045712.n5.nabble.com/VTD-Intel-iommu-IOTLB-flush-really-slow-td4952866.html

Changes between v7 and v8:
        - Rebase on new add_to_physmap from Andres Lagar-Cavilla
        - Only do copy_to_guest on the new XENMAPSPACE (XENMAPSPACE_gmfn_range).
        - Convert the xatp argument to a pointer in xenmem_add_to_physmap.
        - Modify xenmem_add_to_physmap so it doesn''t touchs the input
(xatp is const now).

Changes between v6 and v7:
       - xenmem_add_to_physmap_once can''t take a pointer on xatp
because
         it modifies .idx and .gpfn.
       - Cancel hypercall continuation in the compat layer if the copy_to_guest
         failed.

Changes between v5 and v6:
      - Rework the patch queue to make it more readable.
      - Modify xatp in place in xenmem_add_to_physmap
      - Only check for preemption if we are not at the last iteration
      - Copy xatp guest handler back to the guest only in case of continuation
      - Add continuation only when dealing with the new xenmem space
        (XENMAPSPACE_gmfn_range).

Changes between v4 and v5:
      - Fix hypercall continuation for add_to_physmap in compat mode.

Changes between v3 and v4:
      - Move the loop for gmfn_range from arch_memory_op to
xenmem_add_to_physmap.
      - Add a comment to comment to explain the purpose of
iommu_dont_flush_iotlb.

Changes between v2 and v3:
      - Check for the presence iotlb_flush_all callback before calling it.

Changes between v1 and v2:
      - Move size in struct xen_add_to_physmap in padding between .domid and
.space.
      - Store iommu_dont_flush per cpu
      - Change the code in hvmloader to relocate by batch of 64K, .size is now
16 bits.

Jean Guyader (6):
  vtd: Refactor iotlb flush code
  iommu: Introduce iommu_flush and iommu_flush_all.
  add_to_physmap: Move the code for XENMEM_add_to_physmap
  mm: New XENMEM space, XENMAPSPACE_gmfn_range
  hvmloader: Change memory relocation loop when overlap with PCI hole
  Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary
    iotlb flush

 tools/firmware/hvmloader/pci.c      |   20 +++-
 xen/arch/x86/mm.c                   |  212 +++++++++++++++++++++++------------
 xen/arch/x86/x86_64/compat/mm.c     |   18 +++
 xen/drivers/passthrough/iommu.c     |   25 ++++
 xen/drivers/passthrough/vtd/iommu.c |  100 ++++++++++-------
 xen/include/public/memory.h         |    4 +
 xen/include/xen/iommu.h             |   17 +++
 7 files changed, 277 insertions(+), 119 deletions(-)


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

Factorize the iotlb flush code from map_page and unmap_page into
it''s own function.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 xen/drivers/passthrough/vtd/iommu.c |   86 +++++++++++++++++-----------------
 1 files changed, 43 insertions(+), 43 deletions(-)



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

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 xen/drivers/passthrough/iommu.c     |   20 ++++++++++++++++++++
 xen/drivers/passthrough/vtd/iommu.c |   12 ++++++++++++
 xen/include/xen/iommu.h             |    5 +++++
 3 files changed, 37 insertions(+), 0 deletions(-)



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

Move the code for the XENMEM_add_to_physmap case into it''s own
function (xenmem_add_to_physmap).

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 xen/arch/x86/mm.c |  161 ++++++++++++++++++++++++++++------------------------
 1 files changed, 87 insertions(+), 74 deletions(-)



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

XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
a range of pages. The size of the range is defined in a new field.

This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 xen/arch/x86/mm.c               |   55 ++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/x86_64/compat/mm.c |   15 ++++++++++
 xen/include/public/memory.h     |    4 +++
 3 files changed, 70 insertions(+), 4 deletions(-)



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

Change the way we relocate the memory page if they overlap with pci hole.
Use new map space (XENMAPSPACE_gmfn_range) to move the loop into xen.

This code usually get triggered when a device is pass through to a guest
and the PCI hole has to be extended to have enough room to map the device BARs.
The PCI hole will starts lower and it might overlap with some RAM that has been
alocated for the guest. That usually happen if the guest has more than 4G of
RAM.
We have to relocate those pages in high mem otherwise they won''t be
accessible.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/firmware/hvmloader/pci.c |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)



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

Add cpu flag that will be checked by the iommu low level code
to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 xen/arch/x86/mm.c                   |   12 ++++++++++++
 xen/drivers/passthrough/iommu.c     |    5 +++++
 xen/drivers/passthrough/vtd/iommu.c |    6 ++++--
 xen/include/xen/iommu.h             |   12 ++++++++++++
 4 files changed, 33 insertions(+), 2 deletions(-)



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

On 16/11/2011 19:25, "Jean Guyader" <jean.guyader@eu.citrix.com>
wrote:
> 
> In one of my previous email I detailed a bug I was seeing when passing
> through a Intel GPU on a guest that has more that 4G or RAM.
> 
> Allen suggested that I go for the Plan B but after a discussion with Tim
> we agreed that Plan B was way to disruptive in term of code change.
> 
> This patch series implements Plan A.
I''ll check these in when they get an Ack from Jan.

 -- Keir
>
http://xen.1045712.n5.nabble.com/VTD-Intel-iommu-IOTLB-flush-really-slow-td495
> 2866.html
> 
> Changes between v7 and v8:
>         - Rebase on new add_to_physmap from Andres Lagar-Cavilla
>         - Only do copy_to_guest on the new XENMAPSPACE
> (XENMAPSPACE_gmfn_range).
>         - Convert the xatp argument to a pointer in xenmem_add_to_physmap.
>         - Modify xenmem_add_to_physmap so it doesn''t touchs the
input (xatp is
> const now).
> 
> Changes between v6 and v7:
>        - xenmem_add_to_physmap_once can''t take a pointer on xatp
because
>          it modifies .idx and .gpfn.
>        - Cancel hypercall continuation in the compat layer if the
> copy_to_guest
>          failed.
> 
> Changes between v5 and v6:
>       - Rework the patch queue to make it more readable.
>       - Modify xatp in place in xenmem_add_to_physmap
>       - Only check for preemption if we are not at the last iteration
>       - Copy xatp guest handler back to the guest only in case of
continuation
>       - Add continuation only when dealing with the new xenmem space
>         (XENMAPSPACE_gmfn_range).
> 
> Changes between v4 and v5:
>       - Fix hypercall continuation for add_to_physmap in compat mode.
> 
> Changes between v3 and v4:
>       - Move the loop for gmfn_range from arch_memory_op to
> xenmem_add_to_physmap.
>       - Add a comment to comment to explain the purpose of
> iommu_dont_flush_iotlb.
> 
> Changes between v2 and v3:
>       - Check for the presence iotlb_flush_all callback before calling it.
> 
> Changes between v1 and v2:
>       - Move size in struct xen_add_to_physmap in padding between .domid
and
> .space.
>       - Store iommu_dont_flush per cpu
>       - Change the code in hvmloader to relocate by batch of 64K, .size is
now
> 16 bits.
> 
> Jean Guyader (6):
>   vtd: Refactor iotlb flush code
>   iommu: Introduce iommu_flush and iommu_flush_all.
>   add_to_physmap: Move the code for XENMEM_add_to_physmap
>   mm: New XENMEM space, XENMAPSPACE_gmfn_range
>   hvmloader: Change memory relocation loop when overlap with PCI hole
>   Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary
>     iotlb flush
> 
>  tools/firmware/hvmloader/pci.c      |   20 +++-
>  xen/arch/x86/mm.c                   |  212
> +++++++++++++++++++++++------------
>  xen/arch/x86/x86_64/compat/mm.c     |   18 +++
>  xen/drivers/passthrough/iommu.c     |   25 ++++
>  xen/drivers/passthrough/vtd/iommu.c |  100 ++++++++++-------
>  xen/include/public/memory.h         |    4 +
>  xen/include/xen/iommu.h             |   17 +++
>  7 files changed, 277 insertions(+), 119 deletions(-)
> 


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

>>> On 17.11.11 at 10:20, Keir Fraser <keir@xen.org> wrote:
> On 16/11/2011 19:25, "Jean Guyader"
<jean.guyader@eu.citrix.com> wrote:
> 
>> 
>> In one of my previous email I detailed a bug I was seeing when passing
>> through a Intel GPU on a guest that has more that 4G or RAM.
>> 
>> Allen suggested that I go for the Plan B but after a discussion with
Tim
>> we agreed that Plan B was way to disruptive in term of code change.
>> 
>> This patch series implements Plan A.
> 
> I''ll check these in when they get an Ack from Jan.
While they now look fine to me, I didn''t really plan on acking these; I
would rather have Tim expected to for the mm parts, and I think
Allen did already do so for the passthrough changes.

Jan


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

On Wed, Nov 16, Jean Guyader wrote:
> Move the code for the XENMEM_add_to_physmap case into it''s own
> function (xenmem_add_to_physmap).
This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite failures.
(XEN) Assertion ''!in_atomic()'' failed at softirq.c:61

preempt_count is like fffffc52 or fffffc00 in my testing.

Olaf

On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
> On Wed, Nov 16, Jean Guyader wrote:
> 
>> Move the code for the XENMEM_add_to_physmap case into it''s own
>> function (xenmem_add_to_physmap).
> 
> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
> failures.
> (XEN) Assertion ''!in_atomic()'' failed at softirq.c:61
> 
> preempt_count is like fffffc52 or fffffc00 in my testing.
Thanks, hopefully fixed by c/s 24167.

 -- keir
> Olaf

On 19 November 2011 14:14, Keir Fraser <keir.xen@gmail.com>
wrote:
> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>> On Wed, Nov 16, Jean Guyader wrote:
>>
>>> Move the code for the XENMEM_add_to_physmap case into it''s
own
>>> function (xenmem_add_to_physmap).
>>
>> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
>> failures.
>> (XEN) Assertion ''!in_atomic()'' failed at softirq.c:61
>>
>> preempt_count is like fffffc52 or fffffc00 in my testing.
>
> Thanks, hopefully fixed by c/s 24167.
>
Thanks, sorry about that.

Jean

On Sat, Nov 19, Keir Fraser wrote:
> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > On Wed, Nov 16, Jean Guyader wrote:
> > 
> >> Move the code for the XENMEM_add_to_physmap case into
it''s own
> >> function (xenmem_add_to_physmap).
> > 
> > This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
> > failures.
> > (XEN) Assertion ''!in_atomic()'' failed at
softirq.c:61
> > 
> > preempt_count is like fffffc52 or fffffc00 in my testing.
> 
> Thanks, hopefully fixed by c/s 24167.
Yes, the ASSERT does not trigger anymore.

The remaining issue is this:

Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to read-only
memory page. gfn=0xc0, mfn=0x201979

See
http://www.chiark.greenend.org.uk/~xensrcts/logs/9893/test-amd64-i386-rhel6hvm-amd/serial-potato-beetle.log

Olaf

On 20/11/2011 13:25, "Olaf Hering" <olaf@aepfle.de> wrote:
> On Sat, Nov 19, Keir Fraser wrote:
> 
>> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de>
wrote:
>> 
>>> On Wed, Nov 16, Jean Guyader wrote:
>>> 
>>>> Move the code for the XENMEM_add_to_physmap case into
it''s own
>>>> function (xenmem_add_to_physmap).
>>> 
>>> This changeset 24163:7a9a1261a6b0 seems to cause the current
testsuite
>>> failures.
>>> (XEN) Assertion ''!in_atomic()'' failed at
softirq.c:61
>>> 
>>> preempt_count is like fffffc52 or fffffc00 in my testing.
>> 
>> Thanks, hopefully fixed by c/s 24167.
> 
> Yes, the ASSERT does not trigger anymore.
> 
> The remaining issue is this:
> 
> Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to
read-only
> memory page. gfn=0xc0, mfn=0x201979
Is that new behaviour? It may be unrelated to whatever HVM test failure
we''re seeing, or else be a mere symptom of a guest gone haywire for
other
reasons (we write-protect that memory range because it is supposed to be
ROM).

 -- Keir
> See
>
http://www.chiark.greenend.org.uk/~xensrcts/logs/9893/test-amd64-i386-rhel6hvm
> -amd/serial-potato-beetle.log
> 
> Olaf

On Sun, Nov 20, Keir Fraser wrote:
> > Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to
read-only
> > memory page. gfn=0xc0, mfn=0x201979
> 
> Is that new behaviour? It may be unrelated to whatever HVM test failure
> we''re seeing, or else be a mere symptom of a guest gone haywire
for other
> reasons (we write-protect that memory range because it is supposed to be
> ROM).
The message does not trigger with changeset 24162, but it does with
24167.

Olaf

On Wed, 16 Nov 2011, Jean Guyader wrote:
> 
> XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
> a range of pages. The size of the range is defined in a new field.
> 
> This new field .size is located in the 16 bits padding between .domid
> and .space in struct xen_add_to_physmap to stay compatible with older
> versions.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Hi all,
I was reading more about this commit because this patch breaks the ABI
on ARM, when I realized that on x86 there is no standard that specifies
the alignment of fields in a struct.
As a consequence I don''t think we can really be sure that between
.domid
and .space we always have 16 bits of padding.
I am afraid that if a user compiles Linux or another guest kernel with a
compiler other than gcc, this hypercall might break. In fact it already
happened just switching from x86 to ARM.
Also, considering that the memory.h interface is supposed to be ANSI C,
isn''t it wrong to assume compiler specific artifacts anyway?
Considering that we haven''t made any releases yet with the change in
memory.h, shouldn''t we revert the commit before it is too late?

- Stefano

On 01/08/2012 18:55, "Stefano Stabellini"
<Stefano.Stabellini@eu.citrix.com>
wrote:
> On Wed, 16 Nov 2011, Jean Guyader wrote:
>> 
>> XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
>> a range of pages. The size of the range is defined in a new field.
>> 
>> This new field .size is located in the 16 bits padding between .domid
>> and .space in struct xen_add_to_physmap to stay compatible with older
>> versions.
>> 
>> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> 
> Hi all,
> I was reading more about this commit because this patch breaks the ABI
> on ARM, when I realized that on x86 there is no standard that specifies
> the alignment of fields in a struct.
> As a consequence I don''t think we can really be sure that between
.domid
> and .space we always have 16 bits of padding.
Well, on x86 there *is* 16 bits of padding between the .domid and .space
fields. That''s our ABI. Regardless of whether we rely on
not-really-existent
padding rules in the compiler. If someone compiles in an environment that
aligns stuff differently, we have to rewrite our headers. :)

We don''t have a supported ABI on ARM until 4.2.0 is released at the
earliest.

Should we be changing our rules on public headers, allowing
compiler-specific extensions to precisely lay out our structures? Quite
possibly. We used to do that, but it got shot down by the ppc and ia64
arches who wanted an easier life and just rely on compiler default layout
for a particular platform. Of course those maintainers aren''t actually
voting any more. ;)

 -- Keir
> I am afraid that if a user compiles Linux or another guest kernel with a
> compiler other than gcc, this hypercall might break. In fact it already
> happened just switching from x86 to ARM.
> Also, considering that the memory.h interface is supposed to be ANSI C,
> isn''t it wrong to assume compiler specific artifacts anyway?
> Considering that we haven''t made any releases yet with the change
in
> memory.h, shouldn''t we revert the commit before it is too late?
> 
> - Stefano

At 18:55 +0100 on 01 Aug (1343847341), Stefano Stabellini
wrote:
> I was reading more about this commit because this patch breaks the ABI
> on ARM, when I realized that on x86 there is no standard that specifies
> the alignment of fields in a struct.
> As a consequence I don''t think we can really be sure that between
.domid
> and .space we always have 16 bits of padding.
> I am afraid that if a user compiles Linux or another guest kernel with a
> compiler other than gcc, this hypercall might break. In fact it already
> happened just switching from x86 to ARM.
AIUI, reverting this patch won''t solve that problem - either a compiler
adds
16 bytes of padding (as GCC and clang do), in which case we can use that
area of the new argument, or it doesn''t, in which case it''s
already not
compatible with a GCC-built xen.
> Also, considering that the memory.h interface is supposed to be ANSI C,
> isn''t it wrong to assume compiler specific artifacts anyway?
Yes - people writing Windows drivers have this sort of alignment/padding
issue already in a number of places.  But since, as you say, there''s no
standard describing this, the best we can do is keep any _new_ interfaces
size-aligned and explicitly sized.

Tim.

>>> On 01.08.12 at 19:55, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> I was reading more about this commit because this patch breaks the ABI
> on ARM, when I realized that on x86 there is no standard that specifies
> the alignment of fields in a struct.
There is - the psABI supplements to the SVR4 ABI.
> As a consequence I don''t think we can really be sure that between
.domid
> and .space we always have 16 bits of padding.
It would be very strange for a modern ABI (other than perhaps
ones targeting exclusively embedded environments, where space
matters) to allow structure fields at mis-aligned offsets. Is that
really the case for ARM? This would make the compiled code
accessing such fields pretty ugly, since I seem to recall that loads
and stores are required to be aligned there.
> I am afraid that if a user compiles Linux or another guest kernel with a
> compiler other than gcc, this hypercall might break. In fact it already
> happened just switching from x86 to ARM.
> Also, considering that the memory.h interface is supposed to be ANSI C,
> isn''t it wrong to assume compiler specific artifacts anyway?
This is not compiler specific, but platform defined. Compilers
merely need to conform to that specification; if they don''t they
can''t be used for building Xen interfacing code without manual
tweaking (perhaps re-creation) of the interface headers.

Jan

>>> On 01.08.12 at 20:06, Keir Fraser <keir@xen.org> wrote:
> Should we be changing our rules on public headers, allowing
> compiler-specific extensions to precisely lay out our structures? Quite
> possibly. We used to do that, but it got shot down by the ppc and ia64
> arches who wanted an easier life and just rely on compiler default layout
> for a particular platform. Of course those maintainers aren''t
actually
> voting any more. ;)
In the expectation that other architectures might get ported,
keeping the headers as generic as possible is likely the best
thing to do. After all it was (hopefully!) for a reason that the
PPC and/or IA64 folks wanted the non-standard stuff to be
removed.

Jan

On 02/08/12 10:23, Jan Beulich wrote:
>>>> On 01.08.12 at 19:55, Stefano
Stabellini<stefano.stabellini@eu.citrix.com>  wrote:
>>>>          
>> I was reading more about this commit because this patch breaks the ABI
>> on ARM, when I realized that on x86 there is no standard that specifies
>> the alignment of fields in a struct.
>>      
> There is - the psABI supplements to the SVR4 ABI.
>
>    
This is a completely different issue.
The problem here gcc/whatever compiler padding added to the struct in 
order to have alignment of the members to the word boundry. The 
difference is that this is not enforced in the ARM case (apparently, 
from Stefano''s report) while it happens in the x86 case.

This is why it is a good rule to organize member of a struct from the 
bigger to the smaller when compiling with gcc and this is not the case 
of the struct in question.

In the end it is a compiler decisional thing, not something decided by 
the ABI.

Attilio

>>> On 02.08.12 at 11:45, Attilio Rao <attilio.rao@citrix.com>
wrote:
> On 02/08/12 10:23, Jan Beulich wrote:
>>>>> On 01.08.12 at 19:55, Stefano
Stabellini<stefano.stabellini@eu.citrix.com>
> wrote:
>>>>>          
>>> I was reading more about this commit because this patch breaks the
ABI
>>> on ARM, when I realized that on x86 there is no standard that
specifies
>>> the alignment of fields in a struct.
>>>      
>> There is - the psABI supplements to the SVR4 ABI.
>>
>>    
> 
> This is a completely different issue.
> The problem here gcc/whatever compiler padding added to the struct in 
> order to have alignment of the members to the word boundry. The 
> difference is that this is not enforced in the ARM case (apparently, 
> from Stefano''s report) while it happens in the x86 case.
> 
> This is why it is a good rule to organize member of a struct from the 
> bigger to the smaller when compiling with gcc and this is not the case 
> of the struct in question.
> 
> In the end it is a compiler decisional thing, not something decided by 
> the ABI.
No, definitely not. Otherwise inter-operation between code
compiled with different compilers would be impossible. To
allow this is what the various ABI specifications exist for (and
their absence had, e.g. on DOS, lead to a complete mess).

As to the ARM issue - mind pointing out where mis-aligned
structure fields are specified as being the standard?

Jan

On 02/08/12 11:22, Jan Beulich wrote:
>>>> On 02.08.12 at 11:45, Attilio Rao<attilio.rao@citrix.com>
wrote:
>>>>          
>> On 02/08/12 10:23, Jan Beulich wrote:
>>      
>>>>>> On 01.08.12 at 19:55, Stefano
Stabellini<stefano.stabellini@eu.citrix.com>
>>>>>>              
>> wrote:
>>      
>>>>>>
>>>>>>              
>>>> I was reading more about this commit because this patch breaks
the ABI
>>>> on ARM, when I realized that on x86 there is no standard that
specifies
>>>> the alignment of fields in a struct.
>>>>
>>>>          
>>> There is - the psABI supplements to the SVR4 ABI.
>>>
>>>
>>>        
>> This is a completely different issue.
>> The problem here gcc/whatever compiler padding added to the struct in
>> order to have alignment of the members to the word boundry. The
>> difference is that this is not enforced in the ARM case (apparently,
>> from Stefano''s report) while it happens in the x86 case.
>>
>> This is why it is a good rule to organize member of a struct from the
>> bigger to the smaller when compiling with gcc and this is not the case
>> of the struct in question.
>>
>> In the end it is a compiler decisional thing, not something decided by
>> the ABI.
>>      
> No, definitely not. Otherwise inter-operation between code
> compiled with different compilers would be impossible. To
> allow this is what the various ABI specifications exist for (and
> their absence had, e.g. on DOS, lead to a complete mess).
>
>    
Look, I''m speaking about the problem Stefano is trying to crunch which 
has nothing to do with your discussion on ABI.
> As to the ARM issue - mind pointing out where mis-aligned
> structure fields are specified as being the standard?
>
>    
I think that alignment is important, infact I''m more surprised to the 
ARM side than the x86. Of course, because this is a compiler-dependent 
behaviour (the fact that not only gcc does that doesn''t mean it is 
"standardized", just like it is not standardized anywhere that stack
on
x86 must be word aligned, even if it is so common that it is taken for 
granted now).

I was wondering, maybe ARM is compiled with -fpack-struct (even if I 
would be surprised)?

Attilio

On 02/08/12 11:35, Attilio Rao wrote:
> On 02/08/12 11:22, Jan Beulich wrote:
>    
>>>>> On 02.08.12 at 11:45, Attilio
Rao<attilio.rao@citrix.com>   wrote:
>>>>>
>>>>>            
>>> On 02/08/12 10:23, Jan Beulich wrote:
>>>
>>>        
>>>>>>> On 01.08.12 at 19:55, Stefano
Stabellini<stefano.stabellini@eu.citrix.com>
>>>>>>>
>>>>>>>                
>>> wrote:
>>>
>>>        
>>>>>>>
>>>>>>>                
>>>>> I was reading more about this commit because this patch
breaks the ABI
>>>>> on ARM, when I realized that on x86 there is no standard
that specifies
>>>>> the alignment of fields in a struct.
>>>>>
>>>>>
>>>>>            
>>>> There is - the psABI supplements to the SVR4 ABI.
>>>>
>>>>
>>>>
>>>>          
>>> This is a completely different issue.
>>> The problem here gcc/whatever compiler padding added to the struct
in
>>> order to have alignment of the members to the word boundry. The
>>> difference is that this is not enforced in the ARM case
(apparently,
>>> from Stefano''s report) while it happens in the x86 case.
>>>
>>> This is why it is a good rule to organize member of a struct from
the
>>> bigger to the smaller when compiling with gcc and this is not the
case
>>> of the struct in question.
>>>
>>> In the end it is a compiler decisional thing, not something decided
by
>>> the ABI.
>>>
>>>        
>> No, definitely not. Otherwise inter-operation between code
>> compiled with different compilers would be impossible. To
>> allow this is what the various ABI specifications exist for (and
>> their absence had, e.g. on DOS, lead to a complete mess).
>>
>>
>>      
> Look, I''m speaking about the problem Stefano is trying to crunch
which
> has nothing to do with your discussion on ABI.
>
>    
>> As to the ARM issue - mind pointing out where mis-aligned
>> structure fields are specified as being the standard?
>>
>>
>>      
> I think that alignment is important, infact I''m more surprised to
the
> ARM side than the x86. Of course, because this is a compiler-dependent
> behaviour (the fact that not only gcc does that doesn''t mean it is
> "standardized", just like it is not standardized anywhere that
stack on
> x86 must be word aligned, even if it is so common that it is taken for
> granted now).
>
>    
It seems that I was missing something -- the x86 psABI explicitly 
mention about the structures padding for the internal members of 
structures and unions (Chapter 3, Paragraph 3.1.2, subsection 
"Aggregates and Unions"), so this behaviour really cames from the
SVR4,
as Jan pointed out.

Attilio

On Thu, 2 Aug 2012, Jan Beulich wrote:
> >>> On 01.08.12 at 19:55, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> > I was reading more about this commit because this patch breaks the ABI
> > on ARM, when I realized that on x86 there is no standard that
specifies
> > the alignment of fields in a struct.
> 
> There is - the psABI supplements to the SVR4 ABI.
Thank you very much, that document was exactly what I was looking for.

Also it explains where my confusion was coming from: Jean''s patch
doesn''t
break the ABI on ARM or x86, but I am carrying a patch in my patch queue
that does (unless Jean''s patch is applied):

http://marc.info/?l=xen-devel&m=134305777903771

As you can see this patch splits .space into two shorts, and as a side
effect changes the offset of .space, removing the padding.
Thus it led me to think that Jean''s patch was breaking the ABI when
actually
with "arm: initial XENMAPSPACE_gmfn_foreign" applied, it becomes
required to keep the binary interface compatible.

>>> On 02.08.12 at 15:13, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 2 Aug 2012, Jan Beulich wrote:
>> >>> On 01.08.12 at 19:55, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> wrote:
>> > I was reading more about this commit because this patch breaks the
ABI
>> > on ARM, when I realized that on x86 there is no standard that
specifies
>> > the alignment of fields in a struct.
>> 
>> There is - the psABI supplements to the SVR4 ABI.
> 
> Thank you very much, that document was exactly what I was looking for.
> 
> Also it explains where my confusion was coming from: Jean''s patch
doesn''t
> break the ABI on ARM or x86, but I am carrying a patch in my patch queue
> that does (unless Jean''s patch is applied):
> 
> http://marc.info/?l=xen-devel&m=134305777903771 
> 
> As you can see this patch splits .space into two shorts, and as a side
> effect changes the offset of .space, removing the padding.
> Thus it led me to think that Jean''s patch was breaking the ABI
when actually
> with "arm: initial XENMAPSPACE_gmfn_foreign" applied, it becomes
> required to keep the binary interface compatible.
And then you wouldn''t need to split ''space'' and break
the ABI
at all, you could simply put ''size'' and
''foreign_domid'' into a union.

Jan

On Thu, 2 Aug 2012, Jan Beulich wrote:
> >>> On 02.08.12 at 15:13, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> wrote:
> > On Thu, 2 Aug 2012, Jan Beulich wrote:
> >> >>> On 01.08.12 at 19:55, Stefano Stabellini
<stefano.stabellini@eu.citrix.com>
> > wrote:
> >> > I was reading more about this commit because this patch
breaks the ABI
> >> > on ARM, when I realized that on x86 there is no standard that
specifies
> >> > the alignment of fields in a struct.
> >> 
> >> There is - the psABI supplements to the SVR4 ABI.
> > 
> > Thank you very much, that document was exactly what I was looking for.
> > 
> > Also it explains where my confusion was coming from: Jean''s
patch doesn''t
> > break the ABI on ARM or x86, but I am carrying a patch in my patch
queue
> > that does (unless Jean''s patch is applied):
> > 
> > http://marc.info/?l=xen-devel&m=134305777903771 
> > 
> > As you can see this patch splits .space into two shorts, and as a side
> > effect changes the offset of .space, removing the padding.
> > Thus it led me to think that Jean''s patch was breaking the
ABI when actually
> > with "arm: initial XENMAPSPACE_gmfn_foreign" applied, it
becomes
> > required to keep the binary interface compatible.
> 
> And then you wouldn''t need to split ''space'' and
break the ABI
> at all, you could simply put ''size'' and
''foreign_domid'' into a union.
Yes, that''s a good suggestion.