The memory system doesn't do any segmentation. It will choke if you try and do a single access that spans cache blocks in cached memory. For uncached physical accesses, I don't know if there are any hard limits or not, but performance would get unrealistic if you tie up a bus while a full page of data traverses it.
There are ports that provide readBlob/writeBlob calls, though they're really only intended for functional accesses (like program loading, syscall emulation, etc.). I don't know enough detail about the APIC accesses to comment on the atomicity issues. I'd expect that it's designed so that you just do atomic accesses. Steve On Thu, Sep 4, 2008 at 9:23 AM, Gabe Black <[EMAIL PROTECTED]> wrote: > I'm close to the point of sending messages between APICs, and I was > thinking about the semantics of how I actually want to send the message. > I need to know the specifics of a few properties of the memory system in > order to be sure it will work. First, if I send a bigger message, is it > possible it'll be split up before getting to it's destination? Second, > if it is split up, is there any guarantee of ordering? Third, is there > any easy socket style mechanism to send a bunch of bytes to one location > (a bunch of small, sequential writes seems fairly clunky), or would I > want to write into a buffer and then somehow signal it was all in there? > I've allocated a page of memory space for each APIC so they have a space > to send each other messages. I suppose a fourth concern if the buffer > approach is used is that multiple APICs could compete to write into the > same portion of the APICs page unless it was further divided into > regions for each sender. > > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
