This MR is untested and is for discussion only. With this MR, a VkImage is external only when the guest guest makes it external. That happens when the guest app explicitly uses external memory extensions, or when the guest driver allocates swapchain images. Most VkImage becomes non-external as a result.
In other words, before this MR, vkr forces all VkImage and VkDeviceMemory to be external. That is a spec violation because vkr does not call vkGetPhysicalDeviceImageFormatProperties2 to check if an VkImage can be external. In fact, for most drivers, most images cannot be external. That is a major spec violation.
After this MR, most VkImage are non-external while most VkDeviceMemory are external. We still violate the spec by binding an external memory to a non-external image. But I think that is much more minor. In fact, I think it is possible to come up with a Vulkan extension such that what vkr does after this MR is legal.
I expect significant GPU performance improvement after this MR in many workloads, because non-external VkImage can be "compressed" (e.g., have aux surfaces on ANV). I also plan to update https://docs.mesa3d.org/drivers/venus.html#vk-memory-property-host-visible-bit to clearly spell out the expectations on the host drivers.