On Tue, May 24, 2016 at 01:58:19PM +0200, Christoffer Dall wrote: > On Mon, May 23, 2016 at 05:24:23PM +0200, Andrew Jones wrote: > > On Wed, May 18, 2016 at 11:07:14AM +0200, Christoffer Dall wrote: > > > Hi Drew, > > > > > > Thanks for doing this. I'm happy to see some tests for the GIC. > > > > > > I've been pondering with how to write unit tests for all the MMIO > > > implementations. If you have some thoughts on how that could be easily > > > fitted into this framework, that would probably be a good place to do it > > > ;) > > > > Hi Christoffer, > > > > Sorry for my slow response, I've been on vacation. For MMIO > > implementations, are you referring to the emulation done for > > gicv2 accesses and for gicv3 legacy accesses? And, if so, is > > your question how we might be able to use the same test > > framework for both? And, if that's so, then I think this series > > gets us pretty close already. If I'm completely off-base, then > > please give me a quick high-level description of what you'd like > > to be able to do. > > > What I meant was testing all the MMIO accesses to the various > distributor MMIO regions. > > For example, writing full words to all registers (some value) reading > back the value, correcting for RAZ/WI semantics, and testing that byte > accesses to those registers where that's allowed also works. OK, understood. We can build a table that describes each distributor offset's allowed access types and expected read-back results for the "default enablement" of the gic. Then, we'd run through that table doing a refresh of the gic enabling before each offset test. This series provides everything needed for that, except the offset table. It should be pretty easy to add. Now, configuring the gic differently will result in some offsets producing different values, so we'll eventually want to extend the table to check the same offsets using different gic enable functions as well, but that would be pretty easy to do too. > > If adding that on top of this series sounds like a good idea, someone > should add it to the bottom of their (presumably already long) todo > list, myself included. They do sound like good tests to have. I've added it to the middle of my long TODO. If somebody beats me to it, I won't complain :-) Thanks, drew -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
