summaryrefslogtreecommitdiff
path: root/OvmfPkg/Csm
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2015-10-16 19:52:18 +0000
committerlersek <lersek@Edk2>2015-10-16 19:52:18 +0000
commitfbc80813eeb0cff1c102666046a4483bf44b7414 (patch)
tree7c49bf84fc53e5261f2520b453d068cb64a5665f /OvmfPkg/Csm
parentf3e34b9d8ceca130a14905df9a6a3eaad17f3674 (diff)
downloadedk2-platforms-fbc80813eeb0cff1c102666046a4483bf44b7414.tar.xz
OvmfPkg: VirtioScsiDxe: reset device at ExitBootServices()
(1) VirtioLib allocates the virtio ring in EfiBootServicesData memory. (This is intentional.) Code that executes after ExitBootServices() is permitted to reuse such memory. (2) The hypervisor is allowed to look at, and act upon, a live virtio ring at any time, even without explicit virtio kicks from the guest. Should boot loader code or kernel code, running between ExitBootServices() and the kernel's own virtio drivers resetting the device, overwrite the pages that used to contain the virtio ring before ExitBootServices(), QEMU could theoretically interpret that unrelated data as garbage ring contents, and abort the guest. Although we have seen no such reports, better be prudent and reset the device in an ExitBootServices() event handler. Among other things, this causes QEMU to forget about the device's virtio ring. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18623 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'OvmfPkg/Csm')
0 files changed, 0 insertions, 0 deletions