Am 23.01.2012 17:42, schrieb Gleb Natapov: > On Mon, Jan 23, 2012 at 05:32:59PM +0100, Kevin Wolf wrote: >> Am 23.01.2012 17:22, schrieb Gleb Natapov: >>> On Mon, Jan 23, 2012 at 05:20:22PM +0100, Kevin Wolf wrote: >>>> Am 23.01.2012 17:10, schrieb Gleb Natapov: >>>>> On Mon, Jan 23, 2012 at 05:07:13PM +0100, Kevin Wolf wrote: >>>>>> This adds a test case that jumps into VM86 by iret-ing to a TSS and back >>>>>> to Protected Mode using a task gate in the IDT. >>>>>> >>>>> Can you add the test case to taskswitch2.c? >>>> >>> Running one test to check all aspects of taskswitch emulation. >> >> (We all know that top-posting is disliked, but middle-posting looks even >> crazier!) >> > Inserting replies Very true! > at random places is a new cool thing! > >> Does having one test provide any value in and of itself? It's just an >> implementation detail of the test suite. When testing the KVM patches I >> ran all three test cases with './run_tests.sh -g task', which is >> hopefully easy enough. >> > I think it does. I do not have to use external script to combine tests > on the same topic or even remember that such script exists. We do not > create separate tests to test each instruction emulation either. And I > usually run qemu not on the same machine I compile it on, so I need > special tricks to make those test script work. Of course if putting this > code into existing test file is hard separate test is OK, but is this > really the case here? I haven't really checked whether they interfere. I guess I would have to move the GDT indexes for my manually created TSSes and I would have to hope that nobody else needs the memory I'm overwriting with the real mode code (there doesn't seem to be memory management for < 1 MB). Should taskswitch.c and taskswitch2.c be merged as well then? Or is there a reason why they must stay separate? One file or three files makes sense to me for three tests, but two not so much. Kevin -- 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
