Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
T On Jan 29, 2011 3:24 PM, Gabe Black gbl...@eecs.umich.edu wrote: This, plus the patches I fixed up for Joel and Brad, plus the reviews I just sent out (and some new stats and a new disk image) get X86 FS regressions going. It didn't sound like we had really reached consensus on whether what I was doing here was a good idea, though, or if there was a better idea. Any comments? Basically the unique issue here is that messages need to be able to pass back up from the IO subsystem to the CPUs for MSI-esque interrupts, so there needs to be a path for those through the bridge/small cache thing attaching the IO bus to the memory bus. If all that was needed is a comment then that's easy, but it sounded like you weren't in favor of the general approach, Steve. Gabe Gabe Black wrote: A number of prefixes can be stuck into the top nibble of a physical address to put it into a partition set aside for a certain purpose. This is something I'm doing in M5 that isn't directly analogous to a real system, but I suppose it would be similar to extra signals on the bus for the same purpose. The CPU can only generate so many physical address lines (less than 64) so there shouldn't be any collision. The partition with prefix 0 is normal memory, devices, etc. so they don't have to be treated specially, and one of the others is for the APICs to talk to each other. And yes, a comment would be a good idea. I didn't want to put on all the trimmings if this was a dead end. Gabe Steve Reinhardt wrote: My initial reaction is even if this works, this can't possibly be the best way to do it... where do APIC messages live in the address space? How does 'Addr.max 4' let them through? Did you really think this change didn't need a comment? ;-) On Tue, Nov 23, 2010 at 3:39 AM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto: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 ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
7 On 02/01/11 13:30, Steve Reinhardt wrote: T On Jan 29, 2011 3:24 PM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This, plus the patches I fixed up for Joel and Brad, plus the reviews I just sent out (and some new stats and a new disk image) get X86 FS regressions going. It didn't sound like we had really reached consensus on whether what I was doing here was a good idea, though, or if there was a better idea. Any comments? Basically the unique issue here is that messages need to be able to pass back up from the IO subsystem to the CPUs for MSI-esque interrupts, so there needs to be a path for those through the bridge/small cache thing attaching the IO bus to the memory bus. If all that was needed is a comment then that's easy, but it sounded like you weren't in favor of the general approach, Steve. Gabe Gabe Black wrote: A number of prefixes can be stuck into the top nibble of a physical address to put it into a partition set aside for a certain purpose. This is something I'm doing in M5 that isn't directly analogous to a real system, but I suppose it would be similar to extra signals on the bus for the same purpose. The CPU can only generate so many physical address lines (less than 64) so there shouldn't be any collision. The partition with prefix 0 is normal memory, devices, etc. so they don't have to be treated specially, and one of the others is for the APICs to talk to each other. And yes, a comment would be a good idea. I didn't want to put on all the trimmings if this was a dead end. Gabe Steve Reinhardt wrote: My initial reaction is even if this works, this can't possibly be the best way to do it... where do APIC messages live in the address space? How does 'Addr.max 4' let them through? Did you really think this change didn't need a comment? ;-) On Tue, Nov 23, 2010 at 3:39 AM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org mailto:m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org mailto:m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto: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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
This, plus the patches I fixed up for Joel and Brad, plus the reviews I just sent out (and some new stats and a new disk image) get X86 FS regressions going. It didn't sound like we had really reached consensus on whether what I was doing here was a good idea, though, or if there was a better idea. Any comments? Basically the unique issue here is that messages need to be able to pass back up from the IO subsystem to the CPUs for MSI-esque interrupts, so there needs to be a path for those through the bridge/small cache thing attaching the IO bus to the memory bus. If all that was needed is a comment then that's easy, but it sounded like you weren't in favor of the general approach, Steve. Gabe Gabe Black wrote: A number of prefixes can be stuck into the top nibble of a physical address to put it into a partition set aside for a certain purpose. This is something I'm doing in M5 that isn't directly analogous to a real system, but I suppose it would be similar to extra signals on the bus for the same purpose. The CPU can only generate so many physical address lines (less than 64) so there shouldn't be any collision. The partition with prefix 0 is normal memory, devices, etc. so they don't have to be treated specially, and one of the others is for the APICs to talk to each other. And yes, a comment would be a good idea. I didn't want to put on all the trimmings if this was a dead end. Gabe Steve Reinhardt wrote: My initial reaction is even if this works, this can't possibly be the best way to do it... where do APIC messages live in the address space? How does 'Addr.max 4' let them through? Did you really think this change didn't need a comment? ;-) On Tue, Nov 23, 2010 at 3:39 AM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto: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 ___ 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
Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
Oh, also, Joel and Brad's patches should make -t and --script work, and my patches should make --caches and --l2cache work. Gabe Gabe Black wrote: This, plus the patches I fixed up for Joel and Brad, plus the reviews I just sent out (and some new stats and a new disk image) get X86 FS regressions going. It didn't sound like we had really reached consensus on whether what I was doing here was a good idea, though, or if there was a better idea. Any comments? Basically the unique issue here is that messages need to be able to pass back up from the IO subsystem to the CPUs for MSI-esque interrupts, so there needs to be a path for those through the bridge/small cache thing attaching the IO bus to the memory bus. If all that was needed is a comment then that's easy, but it sounded like you weren't in favor of the general approach, Steve. Gabe Gabe Black wrote: A number of prefixes can be stuck into the top nibble of a physical address to put it into a partition set aside for a certain purpose. This is something I'm doing in M5 that isn't directly analogous to a real system, but I suppose it would be similar to extra signals on the bus for the same purpose. The CPU can only generate so many physical address lines (less than 64) so there shouldn't be any collision. The partition with prefix 0 is normal memory, devices, etc. so they don't have to be treated specially, and one of the others is for the APICs to talk to each other. And yes, a comment would be a good idea. I didn't want to put on all the trimmings if this was a dead end. Gabe Steve Reinhardt wrote: My initial reaction is even if this works, this can't possibly be the best way to do it... where do APIC messages live in the address space? How does 'Addr.max 4' let them through? Did you really think this change didn't need a comment? ;-) On Tue, Nov 23, 2010 at 3:39 AM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto: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 ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
Oh, and one more thing. I modified the splash2 config script to use my adjusted cache hookup function, but I don't know how to actually use it to test it. Could somebody give me a quick command line to try it out? I think there was one on the mailing list at some point, so I could try to find that. Gabe Gabe Black wrote: Oh, also, Joel and Brad's patches should make -t and --script work, and my patches should make --caches and --l2cache work. Gabe Gabe Black wrote: This, plus the patches I fixed up for Joel and Brad, plus the reviews I just sent out (and some new stats and a new disk image) get X86 FS regressions going. It didn't sound like we had really reached consensus on whether what I was doing here was a good idea, though, or if there was a better idea. Any comments? Basically the unique issue here is that messages need to be able to pass back up from the IO subsystem to the CPUs for MSI-esque interrupts, so there needs to be a path for those through the bridge/small cache thing attaching the IO bus to the memory bus. If all that was needed is a comment then that's easy, but it sounded like you weren't in favor of the general approach, Steve. Gabe Gabe Black wrote: A number of prefixes can be stuck into the top nibble of a physical address to put it into a partition set aside for a certain purpose. This is something I'm doing in M5 that isn't directly analogous to a real system, but I suppose it would be similar to extra signals on the bus for the same purpose. The CPU can only generate so many physical address lines (less than 64) so there shouldn't be any collision. The partition with prefix 0 is normal memory, devices, etc. so they don't have to be treated specially, and one of the others is for the APICs to talk to each other. And yes, a comment would be a good idea. I didn't want to put on all the trimmings if this was a dead end. Gabe Steve Reinhardt wrote: My initial reaction is even if this works, this can't possibly be the best way to do it... where do APIC messages live in the address space? How does 'Addr.max 4' let them through? Did you really think this change didn't need a comment? ;-) On Tue, Nov 23, 2010 at 3:39 AM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto: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 ___ 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 ___ 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
[m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ --- Review request for Default. Summary --- Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs - configs/example/fs.py 865e37d507c7 Diff: http://reviews.m5sim.org/r/323/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ 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
Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
My initial reaction is even if this works, this can't possibly be the best way to do it... where do APIC messages live in the address space? How does 'Addr.max 4' let them through? Did you really think this change didn't need a comment? ;-) On Tue, Nov 23, 2010 at 3:39 AM, Gabe Black gbl...@eecs.umich.edu wrote: This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Mem, X86: Make the IO bridge pass APIC messages back towards the CPU.
A number of prefixes can be stuck into the top nibble of a physical address to put it into a partition set aside for a certain purpose. This is something I'm doing in M5 that isn't directly analogous to a real system, but I suppose it would be similar to extra signals on the bus for the same purpose. The CPU can only generate so many physical address lines (less than 64) so there shouldn't be any collision. The partition with prefix 0 is normal memory, devices, etc. so they don't have to be treated specially, and one of the others is for the APICs to talk to each other. And yes, a comment would be a good idea. I didn't want to put on all the trimmings if this was a dead end. Gabe Steve Reinhardt wrote: My initial reaction is even if this works, this can't possibly be the best way to do it... where do APIC messages live in the address space? How does 'Addr.max 4' let them through? Did you really think this change didn't need a comment? ;-) On Tue, Nov 23, 2010 at 3:39 AM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: This seems to get APIC messages back to the CPU, but I really don't know if it's the right way to do this. I have the feeling there are forces at work in this code I don't fully appreciate. Gabe Gabe Black wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/323/ Review request for Default. By Gabe Black. Description Mem,X86: Make the IO bridge pass APIC messages back towards the CPU. Diffs * configs/example/fs.py (865e37d507c7) View Diff http://reviews.m5sim.org/r/323/diff/ ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto: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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
