Change Details

This register is a bit confusing. Intel itself maps it into the guest memory by EPT [1]. On the other hand, the Intel Open Source HD Graphics Programmers' Reference Manual says that this register is only GPU accessible. The CPU can't access this memory region. So, it makes no sense to create an EPT mapping for this region. After some testing it turns out that we just have to provide any address in this register. Nevertheless, we're protecting the register. If the guest modifies it, the GPU may corrupt some host memory which would be a security issue. If this approach doesn't work on some systems, we can easily implement a better emulation because the address and size of the host graphics stolen memory is already exposed by sysctl. We just need to read them, allocate some guest memory and pass that address to the guest. [1] https://github.com/projectacrn/acrn-hypervisor/blob/e28d6fbfdfd556ff1bc3ff330e41d4ddbaa0f897/devicemodel/hw/pci/passthrough.c#L558-L664

This is the first step to emulate the graphics stolen memory register. Note that the graphics stolen memory is somehow confusing. On the one hand the Intel Open Source HD Graphics Programmers' Reference Manual states that it's only GPU accessible. As the CPU can't access the area, the guest shouldn't need it. On the other hand, the Intel GOP driver refuses to work properly, if it's not set to a proper address. Intel itself maps it into the guest by EPT [1]. At the moment, we're not aware of any situation where this EPT mapping is required, so we don't do it yet. Intel also states that the Windows driver for Tiger Lake reads the address of the graphics stolen memory [2]. As the GVT-d code doesn't support Tiger Lake in it's first implementation, we can't check how it behaves. We should keep an eye on it. [1] https://github.com/projectacrn/acrn-hypervisor/blob/e28d6fbfdfd556ff1bc3ff330e41d4ddbaa0f897/devicemodel/hw/pci/passthrough.c#L655-L657 [2] https://github.com/projectacrn/acrn-hypervisor/blob/e28d6fbfdfd556ff1bc3ff330e41d4ddbaa0f897/devicemodel/hw/pci/passthrough.c#L626-L629

This register This is a bit confusing. Intel itself maps it into the guestthe first step to emulate the graphics stolen memory register. memory by EPT [1]. On the other hand, Note that the graphics stolen memory is somehow confusing. the Intel Open Source HD GraphicsOn the one Programmers' Reference Manual says that this register is only GPU hand the Intel Open Source HD Graphics Programmers' Reference Manual accessible. The CPU can't access this memory region. So, states that it's only GPU accessible. it makes noAs the CPU can't access the area, sense to create an EPT mapping for this region. After some testing it turns out that we just have to provide any address the guest shouldn't need it. On the other hand, the Intel GOP driver in this register. Nevertheless, we're refuses to work protecting the register.perly, If theif it's not set to a proper address. guest modifies it Intel itself maps it into the guest by EPT [1]. At the moment, the GPU may corrupt some host memory which would be awe're not security issue. If this approach doesn't work on some systems aware of any situation where this EPT mapping is required, we can easily implement aso we don't better emulation because the address and size of the host graphics do it yet. stolen memory is already exposed by sysctl. We just need to Intel also states that the Windows driver for Tiger Lake reads them, allocate some guest memory and pass that address to the guest. [1] address of the graphics stolen memory [2]. As the GVT-d code doesn't support Tiger Lake in it's first implementation, we can't check how it behaves. We should keep an eye on it. [1] https://github.com/projectacrn/acrn-hypervisor/blob/e28d6fbfdfd556ff1bc3ff330e41d4ddbaa0f897/devicemodel/hw/pci/passthrough.c#L655-L657 [2] https://github.com/projectacrn/acrn-hypervisor/blob/e28d6fbfdfd556ff1bc3ff330e41d4ddbaa0f897/devicemodel/hw/pci/passthrough.c#L558-L664c#L626-L629