I don't think there should be any problem with these working. Ali
On Sep 5, 2008, at 2:48 AM, Gabe Black wrote: > More concretely, if you look in appendix F of the third Intel > manual, it > shows the formats of the messages the APICs would send each other over > the special purpose APIC bus. I'm not intending to implement one > since > they've used the system bus instead for quite a while, but that at > least > shows the quantity of information going back and forth. There's also > an > arbitration ID which goes away when you use the system bus, so these > messages can probably be simpler than what's in the appendix. I'd > guess > around 64 to 128 bits per message. > > Gabe > > [EMAIL PROTECTED] wrote: >> The accesses are supposed to be atomic, I'm pretty sure. I think >> they're >> basically just special messages passed around on the bus which I'm >> approximating with reads and writes. I set aside a page for those >> accesses >> because it was a convenient size and I already needed a second page >> for access >> to the local APICs configuration space, but I don't expect anywhere >> near that >> much data to actually go into these messages. It should just be a >> handful of >> bytes. What might be best would be to create some new type/command >> for packets >> that represent interrupt messages, but I initially shied away from >> that because >> it might be hard to implement properly, could make all the devices >> more complex >> since they have to handle or at least ignore those messages, and >> adds clutter >> and complexity to the way the memory system works. I'm pretty open to >> suggestions if there's some way to implement things that seems >> obviously best. >> >> Gabe >> >> Quoting Steve Reinhardt <[EMAIL PROTECTED]>: >> >> >>> 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 >>>> m5-dev@m5sim.org >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>>> >> >> >> >> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-de >> > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
