I see two possible approaches here. Either your driver loads after Hyper-V or it loads before Hyper-V. If it loads after Hyper-V, then you need a way to escape the container that Hyper-V has put you in. That approach seems like a non-starter. No hypervisor should allow virtualization escapes.
So that leaves you with a driver that loads before Hyper-V. I don't know if Windows has such a thing, but you could always intercede at the boot loader if Windows doesn't provide the necessary facilities. (I assume that disk drivers, at least, have to load before Hyper-V, but maybe that's not the case). With this approach, you need some way of staying outside of the Hyper-V virtualization container once Hyper-V starts up. Since Hyper-V captures the processor, the only solution that comes to mind is to virtualize the processor that Hyper-V captures, so that Hyper-V doesn't gain control of the physical CPU. That means running the host as a nested guest.
Maybe I'm missing a more clever solution. Can you go into more detail about the solution that you envision?