VMX/SVM: a couple questions

[Ethin]

I'm wondering a couple things about SVM/VMX. My primary question is: is it possible to use VMX/SVM to virtualize just applications? Or were VMX/SVM designed to virtualize entire operating systems?
My second question is dependent on the first, but if the answer of the first is that I can indeed virtualize just applications, how would I actually test that in Qemu? (I don't have an AMD processor, unfortunately, so don't have nested virtualization.)
Edit: typos.

[BigBuda]

I think this might be related to your question:

https://github.com/torokernel/torov

[Ethin]

I think this might be related to your question:

https://github.com/torokernel/torov

Yeah, probably is. Just need to figure out how to translate KVM stuff into raw VMX/VMCS stuff (I'm thinking about trying this design in my kernel which iswhy I asked). But the fact that my computer isn't an AMD processor makes actually testing this rather difficult to do.
Edit: okay, so apparently, Intel processors do support this feature.

[linguofreak]

I'm wondering a couple things about SVM/VMX. My primary question is: is it possible to use VMX/SVM to virtualize just applications? Or were VMX/SVM designed to virtualize entire operating systems?
My second question is dependent on the first, but if the answer of the first is that I can indeed virtualize just applications, how would I actually test that in Qemu? (I don't have an AMD processor, unfortunately, so don't have nested virtualization.)
Edit: typos.

So at the very most basic level, you can always write a stand-alone, bootable application that doesn't depend on an operating system at all, and you can boot that application in a VM. In that case, the application has to deal with the hardware all on its own. Of course, if you're going to be writing more than one such application, it might help to write a library that can be loaded with the application that deals with the hardware, but that's basically what the first operating systems were: libraries that took care of the hard work of dealing with the hardware for an application. They didn't do a lot of the stuff that we now consider part of the core job of an operating system, the big one being process isolation: being able to run multiple applications in such a way that they can't interfere with one another. On the earliest computers, they *couldn't* do process isolation (or at least, couldn't do it efficiently), because hardware support for such isolation didn't yet exist. Process isolation became part of the job of the OS when MMUs became a thing. Virtualization extensions like SVM/VMX became a thing because while MMUs provided support for OSes to isolate processes from each other to a degree sufficient for applications in general, they don't provide sufficient support for an OS to be able to run another OS in an isolated environment (or at least, not to do it efficiently. You can always emulate all of the hardware for the system in software, from the CPU on up, but that involves a fair bit of overhead).

Now, on a processor that provides virtualization extensions, it's always possible to use those extensions to provide an environment that provides more isolation than just using the MMU does, but provides an API that calls into the operating system, rather than providing a set of virtualized hardware. This is overkill for most applications, but has its uses, and also can be used to provide "hardware" to virtualized OSes that performs better than a straight-up emulation of the device in question would (for instance, VirtIO disks, network cards, etc. under KVM). Because the use of virtualization extensions tends to be overkill for applications, because virtualization extensions generally allow applications (not just OSes) to act as hypervisors, and because built-in hypervisors in an OS are still managed through userspace applications (such as Qemu), OSes that have a hypervisor component (such as KVM) tend to put more effort into providing paravirtualization APIs for guest OSes than into providing APIs for application environments using virtualization extensions (because not a lot of applications would use such APIs, and for those that do, another application can do the work of providing the API, either by acting as a hypervisor or by managing the OS-native hypervisor).

That, at least, is my impression from what I've seen.