You got it in one, the CPU cannot access the data bus whilst DMA is going on. It CAN continue however to execute any code that's in the CPU cache (or even back on the 8088 the 4 byte buffer in the Bus Interface Unit) so long as said code does not write to or read from data RAM.
It might seem inefficient to have the CPU sit there with its thumb up it's backside waiting for DMA to finish, but usually it's faster to have the device write direct to memory (one bus operation) than it is to have the CPU have to read from the device and write to memory (two bus operations). You cut out the middle-man.
Well crafted code planning of triggering a DMA action though can get the CPU to do at least a few things whilst the DMA is going on. So long as any instructions being executed are in the code buffer cache and only operate on registers and not RAM.
When you get down to that level of assembly programming -- like doing digital audio output on the soundblaster on a 8mhz or slower 8088 -- squeezing every last instruction cycle out of things is a must-have. I actually did that with a 4 voice software synth back in the PC/XT days where I'd start the DMA and then perform a few shifts, register adjustments, and so forth since even back then we had 4 (8088) to 6 (8086) bytes of code cache on the BIU which COULD run during DMA so long as it didn't read/write to RAM. That tiny cache being all the more important when it took FOUR CLOCK CYCLES to read/write one BYTE to the bus on the 8088. Thankfully most opcodes took 2 to 8 clock cycles to execute, but some like MUL and DIV could take a couple HUNDRED clocks.
These days though it is significantly less of an issue just because clock speeds, parallel processing, and larger cache sizes play a very significant role. There's also a few more blocks in place since if DMA gets involved in self-modifying code, things can go bits-up face-down REALLY quickly should there become a cache mis-match. GENERALLY that's why you don't use DMA to write to executing code areas.