[Qemu-devel] qemu softmmu_template.h

[Qemu-devel] qemu softmmu_template.h

[Fabrice Bellard]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <fabrice.bellard@free.fr>	03/11/09 11:58:13

Modified files:
	.              : softmmu_template.h 

Log message:
	soft mmu fix (aka debian random seg fault fix)

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/softmmu_template.h.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

[Qemu-devel] qemu softmmu_template.h

[Fabrice Bellard]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <bellard@savannah.gnu.org>	05/11/26 10:28:44

Modified files:
	.              : softmmu_template.h 

Log message:
	use TARGET_PAGE_SIZE (Paul Brook)

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/softmmu_template.h.diff?tr1=1.12&tr2=1.13&r1=text&r2=text

[Qemu-devel] qemu softmmu_template.h

[Fabrice Bellard]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <bellard@savannah.gnu.org>	05/12/05 19:57:57

Modified files:
	.              : softmmu_template.h 

Log message:
	MIPS unaligned accesses exceptions (Daniel Jacobowitz)

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/softmmu_template.h.diff?tr1=1.14&tr2=1.15&r1=text&r2=text

[Qemu-devel] qemu softmmu_template.h

[Fabrice Bellard]

CVSROOT:	/sources/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <bellard@savannah.gnu.org>	06/02/08 22:41:53

Modified files:
	.              : softmmu_template.h 

Log message:
	added last_io_time field

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/softmmu_template.h.diff?tr1=1.15&tr2=1.16&r1=text&r2=text

[Qemu-devel] qemu softmmu_template.h

[Andrzej Zaborowski]

CVSROOT:	/sources/qemu
Module name:	qemu
Changes by:	Andrzej Zaborowski <balrog>	07/11/17 09:53:42

Modified files:
	.              : softmmu_template.h 

Log message:
	Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20

Re: [Qemu-devel] qemu softmmu_template.h

[J. Mayer]

On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> CVSROOT:	/sources/qemu
> Module name:	qemu
> Changes by:	Andrzej Zaborowski <balrog>	07/11/17 09:53:42
> 
> Modified files:
> 	.              : softmmu_template.h 
> 
> Log message:
> 	Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> 
> CVSWeb URLs:
> http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> 

Has it been checked that it's legal for all architectures and cannot
have any nasty side effect to do accesses in the reverse order ? Real
hardware do not ever seem to do this...

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] qemu softmmu_template.h

[andrzej zaborowski]

On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
>
> On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> > CVSROOT:      /sources/qemu
> > Module name:  qemu
> > Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
> >
> > Modified files:
> >       .              : softmmu_template.h
> >
> > Log message:
> >       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> >
> > CVSWeb URLs:
> > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> >
>
> Has it been checked that it's legal for all architectures and cannot
> have any nasty side effect to do accesses in the reverse order ? Real
> hardware do not ever seem to do this...

For real hardware the store is a single operation.

Logically it shouldn't have any side effects, but if it does then it
would rather mean that other code for that architecture is (also)
broken, I believe.

I've only tested ARM, mips, x86 and x86_64 before committing, so
please test. I figured that the patch won't get any comments on the
mailing list if it isn't merged.
Regards

Re: [Qemu-devel] qemu softmmu_template.h

[J. Mayer]

On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> >
> > On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> > > CVSROOT:      /sources/qemu
> > > Module name:  qemu
> > > Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
> > >
> > > Modified files:
> > >       .              : softmmu_template.h
> > >
> > > Log message:
> > >       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> > >
> > > CVSWeb URLs:
> > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> > >
> >
> > Has it been checked that it's legal for all architectures and cannot
> > have any nasty side effect to do accesses in the reverse order ? Real
> > hardware do not ever seem to do this...
> 
> For real hardware the store is a single operation.

For PowerPC, at least, only aligned stores are defined as atomic. It's
absolutely legal for an implementation to split all non-atomic accesses
into smaller aligned accesses. And I guess it is the same for all
architecture that can do unaligned accesses.

> Logically it shouldn't have any side effects, but if it does then it
> would rather mean that other code for that architecture is (also)
> broken, I believe.
> 
> I've only tested ARM, mips, x86 and x86_64 before committing, so
> please test. I figured that the patch won't get any comments on the
> mailing list if it isn't merged.

I don't think it's so easy to test because it may be very  hard to
trigger the cases that would have side effects, which are target
dependent. I then am very curious to know how you did check that there
is no problem with this patch....
I have to admit I did not notice this patch, or I would have commented
it before (my fault).

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] qemu softmmu_template.h

[andrzej zaborowski]

On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
>
> On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> > On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > >
> > > On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> > > > CVSROOT:      /sources/qemu
> > > > Module name:  qemu
> > > > Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
> > > >
> > > > Modified files:
> > > >       .              : softmmu_template.h
> > > >
> > > > Log message:
> > > >       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> > > >
> > > > CVSWeb URLs:
> > > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> > > >
> > >
> > > Has it been checked that it's legal for all architectures and cannot
> > > have any nasty side effect to do accesses in the reverse order ? Real
> > > hardware do not ever seem to do this...
> >
> > For real hardware the store is a single operation.
>
> For PowerPC, at least, only aligned stores are defined as atomic. It's
> absolutely legal for an implementation to split all non-atomic accesses
> into smaller aligned accesses. And I guess it is the same for all
> architecture that can do unaligned accesses.
>
> > Logically it shouldn't have any side effects, but if it does then it
> > would rather mean that other code for that architecture is (also)
> > broken, I believe.
> >
> > I've only tested ARM, mips, x86 and x86_64 before committing, so
> > please test. I figured that the patch won't get any comments on the
> > mailing list if it isn't merged.
>
> I don't think it's so easy to test because it may be very  hard to
> trigger the cases that would have side effects, which are target
> dependent. I then am very curious to know how you did check that there
> is no problem with this patch....

Well, for ARM, x86 and x86_64 I only checked that unaligned accesses
still work, i.e. that I haven't made an obvious typo. I haven't tested
cross-page accesses with the access to the second page being invalid,
I also don't know how the specifications for other architectures
define the effect of such accesses, so maybe I shouldn't have
committed this, but I assumed a common sense in the design of cpu
archs, meaning that in the example given by TeLeMan the addition is
not performed two times on some bytes.
Regards

Re: [Qemu-devel] qemu softmmu_template.h

[J. Mayer]

On Sat, 2007-11-17 at 11:44 +0100, andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> >
> > On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> > > On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > > >
> > > > On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> > > > > CVSROOT:      /sources/qemu
> > > > > Module name:  qemu
> > > > > Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
> > > > >
> > > > > Modified files:
> > > > >       .              : softmmu_template.h
> > > > >
> > > > > Log message:
> > > > >       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> > > > >
> > > > > CVSWeb URLs:
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> > > > >
> > > >
> > > > Has it been checked that it's legal for all architectures and cannot
> > > > have any nasty side effect to do accesses in the reverse order ? Real
> > > > hardware do not ever seem to do this...
> > >
> > > For real hardware the store is a single operation.
> >
> > For PowerPC, at least, only aligned stores are defined as atomic. It's
> > absolutely legal for an implementation to split all non-atomic accesses
> > into smaller aligned accesses. And I guess it is the same for all
> > architecture that can do unaligned accesses.
> >
> > > Logically it shouldn't have any side effects, but if it does then it
> > > would rather mean that other code for that architecture is (also)
> > > broken, I believe.
> > >
> > > I've only tested ARM, mips, x86 and x86_64 before committing, so
> > > please test. I figured that the patch won't get any comments on the
> > > mailing list if it isn't merged.
> >
> > I don't think it's so easy to test because it may be very  hard to
> > trigger the cases that would have side effects, which are target
> > dependent. I then am very curious to know how you did check that there
> > is no problem with this patch....
> 
> Well, for ARM, x86 and x86_64 I only checked that unaligned accesses
> still work, i.e. that I haven't made an obvious typo. I haven't tested
> cross-page accesses with the access to the second page being invalid,
> I also don't know how the specifications for other architectures
> define the effect of such accesses, so maybe I shouldn't have
> committed this, but I assumed a common sense in the design of cpu
> archs, meaning that in the example given by TeLeMan the addition is
> not performed two times on some bytes.

One case that obviously can have nasty side effects is if doing
unaligned IO accesses. Doing accesses from first byte to the last is
very different than doing the access from the last to the first.
What also can be very different is what is to happen when the
instruction is to be restarted because of a page fault.
I checked the PowerPC specification, and it appears that it allows
splitted memory accesses to be done in any order. It also specifies that
load and stores are restartable even if they have been partially
executed (ie some registers or memory locations have already been
changed), then this patch is likely not to break this target (but I did
not check all specific implementations to see if some have specific
requirements).
This is to be checked for all other targets before such a patch can be
applied, imho. Or you may break some cases that may be very hard to
check and could lead to very strange bugs.

[...]

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] qemu softmmu_template.h

[Blue Swirl]

On 11/17/07, andrzej zaborowski <balrogg@gmail.com> wrote:
> On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> >
> > On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> > > On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > > >
> > > > On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> > > > > CVSROOT:      /sources/qemu
> > > > > Module name:  qemu
> > > > > Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
> > > > >
> > > > > Modified files:
> > > > >       .              : softmmu_template.h
> > > > >
> > > > > Log message:
> > > > >       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> > > > >
> > > > > CVSWeb URLs:
> > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> > > > >
> > > >
> > > > Has it been checked that it's legal for all architectures and cannot
> > > > have any nasty side effect to do accesses in the reverse order ? Real
> > > > hardware do not ever seem to do this...
> > >
> > > For real hardware the store is a single operation.
> >
> > For PowerPC, at least, only aligned stores are defined as atomic. It's
> > absolutely legal for an implementation to split all non-atomic accesses
> > into smaller aligned accesses. And I guess it is the same for all
> > architecture that can do unaligned accesses.
> >
> > > Logically it shouldn't have any side effects, but if it does then it
> > > would rather mean that other code for that architecture is (also)
> > > broken, I believe.
> > >
> > > I've only tested ARM, mips, x86 and x86_64 before committing, so
> > > please test. I figured that the patch won't get any comments on the
> > > mailing list if it isn't merged.
> >
> > I don't think it's so easy to test because it may be very  hard to
> > trigger the cases that would have side effects, which are target
> > dependent. I then am very curious to know how you did check that there
> > is no problem with this patch....
>
> Well, for ARM, x86 and x86_64 I only checked that unaligned accesses
> still work, i.e. that I haven't made an obvious typo. I haven't tested
> cross-page accesses with the access to the second page being invalid,
> I also don't know how the specifications for other architectures
> define the effect of such accesses, so maybe I shouldn't have
> committed this, but I assumed a common sense in the design of cpu
> archs, meaning that in the example given by TeLeMan the addition is
> not performed two times on some bytes.

Sparc is unaffected, unaligned accesses are forbidden.

Re: [Qemu-devel] qemu softmmu_template.h

[Fabrice Bellard]

andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
>> On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
>>> On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
>>>> On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
>>>>> CVSROOT:      /sources/qemu
>>>>> Module name:  qemu
>>>>> Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
>>>>>
>>>>> Modified files:
>>>>>       .              : softmmu_template.h
>>>>>
>>>>> Log message:
>>>>>       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
>>>>>
>>>>> CVSWeb URLs:
>>>>> http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
>>>>>
>>>> Has it been checked that it's legal for all architectures and cannot
>>>> have any nasty side effect to do accesses in the reverse order ? Real
>>>> hardware do not ever seem to do this...
>>> For real hardware the store is a single operation.
>> For PowerPC, at least, only aligned stores are defined as atomic. It's
>> absolutely legal for an implementation to split all non-atomic accesses
>> into smaller aligned accesses. And I guess it is the same for all
>> architecture that can do unaligned accesses.
>>
>>> Logically it shouldn't have any side effects, but if it does then it
>>> would rather mean that other code for that architecture is (also)
>>> broken, I believe.
>>>
>>> I've only tested ARM, mips, x86 and x86_64 before committing, so
>>> please test. I figured that the patch won't get any comments on the
>>> mailing list if it isn't merged.
>> I don't think it's so easy to test because it may be very  hard to
>> trigger the cases that would have side effects, which are target
>> dependent. I then am very curious to know how you did check that there
>> is no problem with this patch....
> 
> Well, for ARM, x86 and x86_64 I only checked that unaligned accesses
> still work, i.e. that I haven't made an obvious typo. I haven't tested
> cross-page accesses with the access to the second page being invalid,
> I also don't know how the specifications for other architectures
> define the effect of such accesses, so maybe I shouldn't have
> committed this, but I assumed a common sense in the design of cpu
> archs, meaning that in the example given by TeLeMan the addition is
> not performed two times on some bytes.
> Regards

I agree with this patch is the sense that the previous behaviour was
clearly incorrect.

Now this patch relies on the fact that tlb_fill() does not remove the
previous page from the TLB cache which is an important "hidden" constraint.

Fabrice.

Re: [Qemu-devel] qemu softmmu_template.h

[andrzej zaborowski]

On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
>
> On Sat, 2007-11-17 at 11:44 +0100, andrzej zaborowski wrote:
> > On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > >
> > > On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> > > > On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > > > >
> > > > > On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> > > > > > CVSROOT:      /sources/qemu
> > > > > > Module name:  qemu
> > > > > > Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
> > > > > >
> > > > > > Modified files:
> > > > > >       .              : softmmu_template.h
> > > > > >
> > > > > > Log message:
> > > > > >       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> > > > > >
> > > > > > CVSWeb URLs:
> > > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> > > > > >
> > > > >
> > > > > Has it been checked that it's legal for all architectures and cannot
> > > > > have any nasty side effect to do accesses in the reverse order ? Real
> > > > > hardware do not ever seem to do this...
> > > >
> > > > For real hardware the store is a single operation.
> > >
> > > For PowerPC, at least, only aligned stores are defined as atomic. It's
> > > absolutely legal for an implementation to split all non-atomic accesses
> > > into smaller aligned accesses. And I guess it is the same for all
> > > architecture that can do unaligned accesses.
> > >
> > > > Logically it shouldn't have any side effects, but if it does then it
> > > > would rather mean that other code for that architecture is (also)
> > > > broken, I believe.
> > > >
> > > > I've only tested ARM, mips, x86 and x86_64 before committing, so
> > > > please test. I figured that the patch won't get any comments on the
> > > > mailing list if it isn't merged.
> > >
> > > I don't think it's so easy to test because it may be very  hard to
> > > trigger the cases that would have side effects, which are target
> > > dependent. I then am very curious to know how you did check that there
> > > is no problem with this patch....
> >
> > Well, for ARM, x86 and x86_64 I only checked that unaligned accesses
> > still work, i.e. that I haven't made an obvious typo. I haven't tested
> > cross-page accesses with the access to the second page being invalid,
> > I also don't know how the specifications for other architectures
> > define the effect of such accesses, so maybe I shouldn't have
> > committed this, but I assumed a common sense in the design of cpu
> > archs, meaning that in the example given by TeLeMan the addition is
> > not performed two times on some bytes.
>
> One case that obviously can have nasty side effects is if doing
> unaligned IO accesses. Doing accesses from first byte to the last is
> very different than doing the access from the last to the first.

Hmm, right, I had not thought about IO accesses. I will watch for
reports of any breakage that may have any connection with this and
revert if there's any such report.

> What also can be very different is what is to happen when the
> instruction is to be restarted because of a page fault.
> I checked the PowerPC specification, and it appears that it allows
> splitted memory accesses to be done in any order. It also specifies that
> load and stores are restartable even if they have been partially
> executed (ie some registers or memory locations have already been
> changed), then this patch is likely not to break this target (but I did
> not check all specific implementations to see if some have specific
> requirements).
> This is to be checked for all other targets before such a patch can be
> applied, imho.

Yes, although in practice that means the workaround (not a proper
bugfix) would never be in qemu CVS and would be maintained in other
trees endlessly.

Re: [Qemu-devel] qemu softmmu_template.h

[J. Mayer]

On Sat, 2007-11-17 at 12:57 +0100, andrzej zaborowski wrote:
> On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> >
> > On Sat, 2007-11-17 at 11:44 +0100, andrzej zaborowski wrote:
> > > On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > > >
> > > > On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote:
> > > > > On 17/11/2007, J. Mayer <l_indien@magic.fr> wrote:
> > > > > >
> > > > > > On Sat, 2007-11-17 at 09:53 +0000, Andrzej Zaborowski wrote:
> > > > > > > CVSROOT:      /sources/qemu
> > > > > > > Module name:  qemu
> > > > > > > Changes by:   Andrzej Zaborowski <balrog>     07/11/17 09:53:42
> > > > > > >
> > > > > > > Modified files:
> > > > > > >       .              : softmmu_template.h
> > > > > > >
> > > > > > > Log message:
> > > > > > >       Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan).
> > > > > > >
> > > > > > > CVSWeb URLs:
> > > > > > > http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.19&r2=1.20
> > > > > > >
> > > > > >
> > > > > > Has it been checked that it's legal for all architectures and cannot
> > > > > > have any nasty side effect to do accesses in the reverse order ? Real
> > > > > > hardware do not ever seem to do this...
> > > > >
> > > > > For real hardware the store is a single operation.
> > > >
> > > > For PowerPC, at least, only aligned stores are defined as atomic. It's
> > > > absolutely legal for an implementation to split all non-atomic accesses
> > > > into smaller aligned accesses. And I guess it is the same for all
> > > > architecture that can do unaligned accesses.
> > > >
> > > > > Logically it shouldn't have any side effects, but if it does then it
> > > > > would rather mean that other code for that architecture is (also)
> > > > > broken, I believe.
> > > > >
> > > > > I've only tested ARM, mips, x86 and x86_64 before committing, so
> > > > > please test. I figured that the patch won't get any comments on the
> > > > > mailing list if it isn't merged.
> > > >
> > > > I don't think it's so easy to test because it may be very  hard to
> > > > trigger the cases that would have side effects, which are target
> > > > dependent. I then am very curious to know how you did check that there
> > > > is no problem with this patch....
> > >
> > > Well, for ARM, x86 and x86_64 I only checked that unaligned accesses
> > > still work, i.e. that I haven't made an obvious typo. I haven't tested
> > > cross-page accesses with the access to the second page being invalid,
> > > I also don't know how the specifications for other architectures
> > > define the effect of such accesses, so maybe I shouldn't have
> > > committed this, but I assumed a common sense in the design of cpu
> > > archs, meaning that in the example given by TeLeMan the addition is
> > > not performed two times on some bytes.
> >
> > One case that obviously can have nasty side effects is if doing
> > unaligned IO accesses. Doing accesses from first byte to the last is
> > very different than doing the access from the last to the first.
> 
> Hmm, right, I had not thought about IO accesses. I will watch for
> reports of any breakage that may have any connection with this and
> revert if there's any such report.
> 
> > What also can be very different is what is to happen when the
> > instruction is to be restarted because of a page fault.
> > I checked the PowerPC specification, and it appears that it allows
> > splitted memory accesses to be done in any order. It also specifies that
> > load and stores are restartable even if they have been partially
> > executed (ie some registers or memory locations have already been
> > changed), then this patch is likely not to break this target (but I did
> > not check all specific implementations to see if some have specific
> > requirements).
> > This is to be checked for all other targets before such a patch can be
> > applied, imho.
> 
> Yes, although in practice that means the workaround (not a proper
> bugfix) would never be in qemu CVS and would be maintained in other
> trees endlessly.

Hopefully not ! Just means one have to check the targets specifications.
If specifications say it's valid to do access in random order, then it's
up to the emulation code to take care of that case and make it work
properly and the patch would not be to blame if it triggers some bugs.
In the meantime, I checked the Alpha spec which seems, if I understood
well, to allow such a behavior.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] qemu softmmu_template.h

[TeLeMan]

Here is one sample to reproduce the previous bug on guest windows.

Usage:

rundll32 qemu-test.dll test

The correct running result is to display a message box. 
If no patch, the exception will occur.

I tested this sample on windows xp sp2.

http://www.nabble.com/file/p13808936/qemu-test.rar qemu-test.rar 
-- 
View this message in context: http://www.nabble.com/qemu-softmmu_template.h-tf4825948.html#a13808936
Sent from the QEMU - Dev mailing list archive at Nabble.com.

Re: [Qemu-devel] qemu softmmu_template.h

[Paul Brook]

> > > >       Check permissions for the last byte first in unaligned slow_st
> > > > accesses (patch from TeLeMan).
> > >
> > > Has it been checked that it's legal for all architectures and cannot
> > > have any nasty side effect to do accesses in the reverse order ? Real
> > > hardware do not ever seem to do this...
> >
> > For real hardware the store is a single operation.
>
> For PowerPC, at least, only aligned stores are defined as atomic. It's
> absolutely legal for an implementation to split all non-atomic accesses
> into smaller aligned accesses. And I guess it is the same for all

Depends how you're measuring atomicity. It's possible for an architecture 
could have non-atomic stores (w.r.t. other CPUs in an SMP system), but 
require that MMU faults restore state as it was before the faulting 
instruction executed. By my reading this is that case for x86.

For ARM these checks are unnecessary and the previous code was acceptable. 
Quoting from the ARM architecture manual:
"
If a Data Abort occurs [...] the value of each memory location that the 
instruction stores to is:
* unchanged if the memory system does not permit write access to the memory 
location
* UNPREDICTABLE otherwise
"
There is also wording that explicitly allows the CPU to split an unaligned 
access into multiple smaller accesses.

> One case that obviously can have nasty side effects is if doing
> unaligned IO accesses

ARM does not allow unaligned accesses to IO regions, so this should not be a 
problem there.

Paul