[Qemu-devel] qemu cpu-all.h exec.c

[Qemu-devel] qemu cpu-all.h exec.c

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	07/05/26 17:36:03

Modified files:
	.              : cpu-all.h exec.c 

Log message:
	Implement generic sub-page I/O based on earlier work by J. Mayer.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.71&r2=1.72
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.96&r2=1.97

[Qemu-devel] qemu cpu-all.h exec.c

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	08/01/01 16:57:19

Modified files:
	.              : cpu-all.h exec.c 

Log message:
	 Support for registering address space only for some access widths

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.80&r2=1.81
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.120&r2=1.121

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Fabrice Bellard]

Blue Swirl wrote:
> CVSROOT:	/cvsroot/qemu
> Module name:	qemu
> Changes by:	Blue Swirl <blueswir1>	08/01/01 16:57:19
> 
> Modified files:
> 	.              : cpu-all.h exec.c 
> 
> Log message:
> 	 Support for registering address space only for some access widths
> 
> CVSWeb URLs:
> http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.80&r2=1.81
> http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.120&r2=1.121

This patch breaks the behaviour of the memory callbacks if the callbacks
are changed dynamically (see cirrus_update_memory_access() to see what I
mean). You are lucky that no one does that in the subpage case !

Regards,

Fabrice.

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Blue Swirl]

On 1/1/08, Fabrice Bellard <fabrice@bellard.org> wrote:
> This patch breaks the behaviour of the memory callbacks if the callbacks
> are changed dynamically (see cirrus_update_memory_access() to see what I
> mean). You are lucky that no one does that in the subpage case !

I'll change the function pointer to a pointer to function pointer.

Also the opaque parameter may need to be different for each function,
it just didn't matter for the unassigned memory case.

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Paul Brook]

> Also the opaque parameter may need to be different for each function,
> it just didn't matter for the unassigned memory case.

Do you really have systems where independent devices need to respond to 
different sized accesses to the same address?

Paul

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Blue Swirl]

On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
> > Also the opaque parameter may need to be different for each function,
> > it just didn't matter for the unassigned memory case.
>
> Do you really have systems where independent devices need to respond to
> different sized accesses to the same address?

I don't think so. But one day unassigned or even normal RAM memory
access may need an opaque parameter, so passing the device's opaque to
unassigned memory handler is wrong.

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Paul Brook]

On Wednesday 02 January 2008, Blue Swirl wrote:
> On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
> > > Also the opaque parameter may need to be different for each function,
> > > it just didn't matter for the unassigned memory case.
> >
> > Do you really have systems where independent devices need to respond to
> > different sized accesses to the same address?
>
> I don't think so. But one day unassigned or even normal RAM memory
> access may need an opaque parameter, so passing the device's opaque to
> unassigned memory handler is wrong.

I'm not convinced.  Your current implementation seems to introduce an extra 
level of indirection without any plausible benefit.

If you're treating unassigned memory differently it needs to be handled much 
earlier that so you can raise CPU exceptions.

Paul

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Blue Swirl]

On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
> On Wednesday 02 January 2008, Blue Swirl wrote:
> > On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
> > > > Also the opaque parameter may need to be different for each function,
> > > > it just didn't matter for the unassigned memory case.
> > >
> > > Do you really have systems where independent devices need to respond to
> > > different sized accesses to the same address?
> >
> > I don't think so. But one day unassigned or even normal RAM memory
> > access may need an opaque parameter, so passing the device's opaque to
> > unassigned memory handler is wrong.
>
> I'm not convinced.  Your current implementation seems to introduce an extra
> level of indirection without any plausible benefit.
>
> If you're treating unassigned memory differently it needs to be handled much
> earlier that so you can raise CPU exceptions.

Earlier, where's that?

Another approach could be conditional stacked handlers, where a higher
level handler could pass the access request to lower one (possibly
modifying it in flight) or handle completely. Maybe this solves the
longstanding generic DMA issue if taken to the device to memory
direction.

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Paul Brook]

On Thursday 03 January 2008, Blue Swirl wrote:
> On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
> > On Wednesday 02 January 2008, Blue Swirl wrote:
> > > On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
> > > > > Also the opaque parameter may need to be different for each
> > > > > function, it just didn't matter for the unassigned memory case.
> > > >
> > > > Do you really have systems where independent devices need to respond
> > > > to different sized accesses to the same address?
> > >
> > > I don't think so. But one day unassigned or even normal RAM memory
> > > access may need an opaque parameter, so passing the device's opaque to
> > > unassigned memory handler is wrong.
> >
> > I'm not convinced.  Your current implementation seems to introduce an
> > extra level of indirection without any plausible benefit.
> >
> > If you're treating unassigned memory differently it needs to be handled
> > much earlier that so you can raise CPU exceptions.
>
> Earlier, where's that?

Probably when populating the TLB entry. IIRC by the time we get to the IO 
callbacks we don't have enough information to generate a CPU exception.

> Another approach could be conditional stacked handlers, where a higher
> level handler could pass the access request to lower one (possibly
> modifying it in flight) or handle completely. Maybe this solves the
> longstanding generic DMA issue if taken to the device to memory
> direction.

I'm not so sure. RAM is special because it's direct mapped by the TLB rather 
than going through the (much slower) MMIO handling routines.

Paul

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Fabrice Bellard]

Blue Swirl wrote:
> On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
>> On Wednesday 02 January 2008, Blue Swirl wrote:
>>> On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
>>>>> Also the opaque parameter may need to be different for each function,
>>>>> it just didn't matter for the unassigned memory case.
>>>> Do you really have systems where independent devices need to respond to
>>>> different sized accesses to the same address?
>>> I don't think so. But one day unassigned or even normal RAM memory
>>> access may need an opaque parameter, so passing the device's opaque to
>>> unassigned memory handler is wrong.
>> I'm not convinced.  Your current implementation seems to introduce an extra
>> level of indirection without any plausible benefit.
>>
>> If you're treating unassigned memory differently it needs to be handled much
>> earlier that so you can raise CPU exceptions.
> 
> Earlier, where's that?
> 
> Another approach could be conditional stacked handlers, where a higher
> level handler could pass the access request to lower one (possibly
> modifying it in flight) or handle completely. Maybe this solves the
> longstanding generic DMA issue if taken to the device to memory
> direction.

As I said earlier, the only correct way to handle memory accesses is to 
be able to consider a memory range and its associated I/O callbacks as 
an object which can be installed _and_ removed. It implies that there is 
a priority system close to what you described. It is essential to 
correct long standing PCI bugs for example.

Regards,

Fabrice.

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Blue Swirl]

On 1/3/08, Fabrice Bellard <fabrice@bellard.org> wrote:
> Blue Swirl wrote:
> > On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
> >> On Wednesday 02 January 2008, Blue Swirl wrote:
> >>> On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
> >>>>> Also the opaque parameter may need to be different for each function,
> >>>>> it just didn't matter for the unassigned memory case.
> >>>> Do you really have systems where independent devices need to respond to
> >>>> different sized accesses to the same address?
> >>> I don't think so. But one day unassigned or even normal RAM memory
> >>> access may need an opaque parameter, so passing the device's opaque to
> >>> unassigned memory handler is wrong.
> >> I'm not convinced.  Your current implementation seems to introduce an extra
> >> level of indirection without any plausible benefit.
> >>
> >> If you're treating unassigned memory differently it needs to be handled much
> >> earlier that so you can raise CPU exceptions.
> >
> > Earlier, where's that?
> >
> > Another approach could be conditional stacked handlers, where a higher
> > level handler could pass the access request to lower one (possibly
> > modifying it in flight) or handle completely. Maybe this solves the
> > longstanding generic DMA issue if taken to the device to memory
> > direction.
>
> As I said earlier, the only correct way to handle memory accesses is to
> be able to consider a memory range and its associated I/O callbacks as
> an object which can be installed _and_ removed. It implies that there is
> a priority system close to what you described. It is essential to
> correct long standing PCI bugs for example.

This should be feasible, though raises a few questions. Does this mean
another API for stacked registration, or should stacking happen
automatically with current API? A new function is needed for removal.

What could be the API for setting priorities? How would multiple
layers be enabled for multiple devices at same location? How can a
higher level handler pass the request to lower one? Do we need a
status return for access handler?

A few use cases:
Partial width device > unassigned
ROM > RAM > unassigned
SBus controller > EBus controller > Device > unassigned

Other direction (for future expansion):
Device > DMA controller > SBus controller > IOMMU > RAM > unassigned

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Paul Brook]

> > As I said earlier, the only correct way to handle memory accesses is to
> > be able to consider a memory range and its associated I/O callbacks as
> > an object which can be installed _and_ removed. It implies that there is
> > a priority system close to what you described. It is essential to
> > correct long standing PCI bugs for example.
>
> This should be feasible, though raises a few questions. Does this mean
> another API for stacked registration, or should stacking happen
> automatically with current API? A new function is needed for removal.
>
> What could be the API for setting priorities? How would multiple
> layers be enabled for multiple devices at same location? How can a
> higher level handler pass the request to lower one? Do we need a
> status return for access handler?

I don't think "passing through" requests to the next handler is an interesting 
use case.  Just consider a device to handle all accesses within its defined 
region.

If an overlapping region is accessed then at best you're into highly machine 
dependent behavior. The only interesting case I can think of is x86 where a 
PCI region may be overlayed on top of RAM. A single level of priority 
(ram/rom vs. everything else) is probably sufficient for practical purposes.

The most important thing is that when one of the mappings is removed, 
subsequent accesses to the previously overlapped region hit the remaining 
device.

> A few use cases:
> Partial width device > unassigned
> ROM > RAM > unassigned
> SBus controller > EBus controller > Device > unassigned
>
> Other direction (for future expansion):
> Device > DMA controller > SBus controller > IOMMU > RAM > unassigned

I think these are different things:

- Registering multiple devices within the same address space.
- Mapping access from one address sapce to annother.

Currently qemu does neither.

The former is what Fabrice is talking about.

The latter depends how general you want the solution to be. One possibility is 
for the device DMA+registration routines map everything onto CPU address 
space.

Paul

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Blue Swirl]

On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
> > > As I said earlier, the only correct way to handle memory accesses is to
> > > be able to consider a memory range and its associated I/O callbacks as
> > > an object which can be installed _and_ removed. It implies that there is
> > > a priority system close to what you described. It is essential to
> > > correct long standing PCI bugs for example.
> >
> > This should be feasible, though raises a few questions. Does this mean
> > another API for stacked registration, or should stacking happen
> > automatically with current API? A new function is needed for removal.
> >
> > What could be the API for setting priorities? How would multiple
> > layers be enabled for multiple devices at same location? How can a
> > higher level handler pass the request to lower one? Do we need a
> > status return for access handler?
>
> I don't think "passing through" requests to the next handler is an interesting
> use case.  Just consider a device to handle all accesses within its defined
> region.
>
> If an overlapping region is accessed then at best you're into highly machine
> dependent behavior. The only interesting case I can think of is x86 where a
> PCI region may be overlayed on top of RAM. A single level of priority
> (ram/rom vs. everything else) is probably sufficient for practical purposes.
>
> The most important thing is that when one of the mappings is removed,
> subsequent accesses to the previously overlapped region hit the remaining
> device.

The difference between "passive" stacking and "active" should be
minimal and not visible to the devices.

> > A few use cases:
> > Partial width device > unassigned
> > ROM > RAM > unassigned
> > SBus controller > EBus controller > Device > unassigned
> >
> > Other direction (for future expansion):
> > Device > DMA controller > SBus controller > IOMMU > RAM > unassigned
>
> I think these are different things:
>
> - Registering multiple devices within the same address space.
> - Mapping access from one address sapce to annother.
>
> Currently qemu does neither.
>
> The former is what Fabrice is talking about.

Right, but if we have this "active" stacking, address translation
could be a possible future extension of this mode.

> The latter depends how general you want the solution to be. One possibility is
> for the device DMA+registration routines map everything onto CPU address
> space.

Interesting idea, do you mean that all individual bus address spaces
could exist in system view in the same large address space outside the
target CPU address space? Then some of the translations could become
simple offset operations.

Re: [Qemu-devel] qemu cpu-all.h exec.c

[Paul Brook]

> > The latter depends how general you want the solution to be. One
> > possibility is for the device DMA+registration routines map everything
> > onto CPU address space.
>
> Interesting idea, do you mean that all individual bus address spaces
> could exist in system view in the same large address space outside the
> target CPU address space? Then some of the translations could become
> simple offset operations.

No, I was basically assuming that all cpu->device mappings are linear offsets. 
This means you need almost no changes to the current CPU access code. You can 
also arrange for all device DMA requests to be translated into CPU physical 
addresses (VIA IOMMU, or whatever), then treat them the same as if they were 
CPU accesses.

However on second thoughts this probably isn't such a clever idea.  There are 
some potentially interesting cases it can't handle.

I'll see if I can come up with an actual proposal. My current theory is that 
we should be able to combine the bus mappings with the TLB fill, which should 
help mitigate the overhead.

Paul

[Qemu-devel] qemu cpu-all.h exec.c

[Jocelyn Mayer]

CVSROOT:	/sources/qemu
Module name:	qemu
Changes by:	Jocelyn Mayer <j_mayer>	07/04/04 07:55:12

Modified files:
	.              : cpu-all.h exec.c 

Log message:
	Add missing 64 bits memory accessors.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.64&r2=1.65
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.89&r2=1.90

[Qemu-devel] qemu cpu-all.h exec.c

[Fabrice Bellard]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <bellard@savannah.gnu.org>	05/10/30 20:48:42

Modified files:
	.              : cpu-all.h exec.c 

Log message:
	more physical memory access functions

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/cpu-all.h.diff?tr1=1.45&tr2=1.46&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/exec.c.diff?tr1=1.65&tr2=1.66&r1=text&r2=text

[Qemu-devel] qemu cpu-all.h exec.c

[Fabrice Bellard]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <bellard@savannah.gnu.org>	05/02/10 21:56:59

Modified files:
	.              : cpu-all.h exec.c 

Log message:
	dirty flag changes

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/cpu-all.h.diff?tr1=1.40&tr2=1.41&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/exec.c.diff?tr1=1.56&tr2=1.57&r1=text&r2=text