Blob resources areas of memory where various chunks of memory containing data are used for graphics rendering. This data can include frame buffers, textures, vertex data and other ancillary data needed to render a graphics scene. You can find an overview of the types of blobs here.
For accelerated 3D graphics to work the final hardware must be able to access these resources. As there are sometimes restrictions on where these allocations should be (e.g. physical address, alignment) the allocations need to be made by the host. These host visible memory regions make use of shared memory regions that are continuously shared between the guest and the host. This is different from the memory sharing of buffers that are passed back and forth as VirtQueue elements. Shared regions are allocated by the device and presented to the driver. They should not be used to control the device or stream data.
Type 1 vs Type 2 Hypervisor Considerations
A type-2 hypervisor (like KVM) controls the whole physical address space of the machine. Therefor the host kernel is able to control where in the physical address space mappings are made and then shared it with the guests.
A type-1 hypervisor (like Xen) is separated from the “host” kernel (Dom0 in Xen terminology) which is now treated like any other guest on the system. It is the hypervisor itself that controls the physical address map through the stage 2 mappingshttps://developer.arm.com/documentation/102142/0100/Stage-2-translation that map the guest physical address (called IPA in Arm speak) to the final PA.