From what you describe, if I understand it correctly, you're doing QoS incorrectly.
To use QoS effectively, you need to control/manage all bandwidth.
As a simple example, if your "sharing" your Interconnect traffic for both DMVPN and "other traffic", although you're LLQing DMVPN outbound, what about inbound? (I.e. not just hub traffic, inbound.)
Doing DMVPN "right" (regarding QoS) is difficult enough managing bandwidth between hub and spokes. I.e. to insure spokes aggregate doesn't overrun hub ingress, offset by being unable to "use" bandwidth, unused, at that moment, by other spokes. Compounding this problem is when you enable spoke-to-spoke traffic, again many to one aggregate is the issue.
One of Cisco's recent DMVPN variants supports dynamic (adaptive) shaping between DMVPN end points. Using that (if available on your platform), allows one location's egress to shape to another location's available ingress bandwidth. However, for real-time traffic, like VoIP, you might run into a situation where dynamic shaping doesn't provide enough bandwidth for such traffic.
If you haven't had any problems so far, as you mention at least one gig interface, perhaps you haven't had enough congestion to cause any issues. I.e. possibly later, if not at the moment, you'll bump into "QoS" problems.
I would suggest a further review of your "QoS" design.
