Is it safe to use a loop device to circumvent EBUSY on a block device underlying device-mapper?

I’m trying to include the beginning of a disk block device (the GPT area) read-only in a device-mapper linear mapping. This block device also contains my root filesystem, as such the partition housing it would be in use concurrently with the mapping’s existence. This is so I can pass through parts (but not all of) the same disk to Windows 10 running under QEMU, for use in there. I don’t intend to ever have any sections of the disk read-write in parallel across kernels, but Windows’ partition as well as the ESP (not mounted in Linux) would be. To visualize (partition numbers given): So, the beginning of the disk as well as the partitions one and three I want passed through, maybe I’ll need the end of the disk as well. Write access should only be allowed to the partitions, not to the outer disk parts. I’ve learnt about device-mapper some years ago on another occassion and revisited its docs. Encouraged, I’ve gone on my merry way and constructed the mapping, starting from the beginning, whereby I’ve eventually hit the current roadblock: When attempting to create the mapper device, dmsetup passed on an EBUSY error. I suspect this to have happened because one of the disk block device’s sub-devices, the partition block device with my Linux installation, currently being in use. For troubleshooting purposes, I’ve recreated the situation on a RAM disk (Does brd count as a Linux Arcanum by now?), which (from what I recall) made operations fail in the same manner in which they had failed on the true disk:

#!/bin/sh #This will obviously need root, or maybe CAPs.
[ -b /dev/ram0 ] && exit 1
   #In this script, I rely on brd not being in use and /dev/ram0 being created.
modprobe brd rd_nr=1 rd_size=261120 max_part=2 && [ -b /dev/ram0 ] || exit 2
sgdisk -a=8 -n=0:0:+100M -t=0:ef00 -n=0 -t=0:8304 /dev/ram0
#There’s no filesystem necessary on p1 for demonstration purposes.
mkfs.ext4 -i 6144 -O ext_attr,flex_bg,inline_data,metadata_csum,sparse_super2 /dev/ram0p2
   #Just some example filesystem, taken from my shell history grab-bag.
mkdir /tmp/ExampleMountpoint || exit 3
mount /dev/ram0p2 /tmp/ExampleMountpoint || exit 4
dmsetup create --readonly Example1 --table '0 33 linear /dev/ram0 0' #Output:
#device-mapper: reload ioctl on Example1 (253:0) failed: Device or resource busy
#Command failed.
   #The exit code is 1, but the error message matches EBUSY.
   #To no surprise, adding -f doesn’t help.
umount /tmp/ExampleMountpoint
dmsetup create --readonly Example2 --table '0 33 linear /dev/ram0 0'
   #This one works, but I need it to work with the partition mounted.
ls -l /dev/mapper/Example2
dmsetup remove Example2
#rm /tmp/ExampleMountpoint

On another StackExchange question I’ve found when I started out—I’ve searched for it twenty days ago when I’ve asked on some Linux forum about this (in vain), then I’ve searched for it today again, I really haven’t been able to dig it up a second time—there was an answer that revealed that I could get around the EBUSY status by employing a loop device as an intermediary before the real disk device:

mount /dev/ram0p2 /tmp/ExampleMountpoint #Remount.
LoopDev=$(losetup --show -f /dev/ram0)
dmsetup create --readonly Example2 --table '0 68 linear /dev/loop0 0'
   #Side note: Less than 68s makes sgdisk err out instead of printing the table.
   #This might be a bug, it should, by my reckoning, go down do 1+32+32+1 or even just 33s.
sgdisk -Pp "$LoopDev" #This should print some warnings, then the partition table created above.
losetup -d "$LoopDev"
umount /tmp/ExampleMountpoint
rm /tmp/ExampleMountpoint

So, when redirecting the disk block device through a loop device, dmsetup will comply instead of erring out. Caring much about my data (though I do have pulled an image onto a separate disk) I now wonder, whether this is actually safe to do and give the expected results in the greater scheme of things. (Among them, preventing corruption of partition 4 and the GPI, as well as allowing write access to the partitions 1 and 3 through the VM.) Are there any, I don’t know, additional I/O alignment gotchas to watch out for?