On Tue, 2016-02-02 at 19:10 +0000, Kay, Allen M wrote: > > > -----Original Message----- > > From: Tian, Kevin > > Sent: Monday, February 01, 2016 11:08 PM > > To: Kay, Allen M; Alex Williamson; Gerd Hoffmann; qemu-de...@nongnu.org > > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost; > > Stefano Stabellini; Cao jin; vfio-us...@redhat.com > > Subject: RE: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset > > tweaks > > > > > From: Kay, Allen M > > > Sent: Saturday, January 30, 2016 5:58 AM > > > > > > First of all, I would like to clarify I'm talking about general IGD > > > passthrough case - not specific to KVMGT. In IGD passthrough > > > configuration, one of the following will happen when the driver accesses > > OpRegion: > > > > > > 1) If the hypervisor sets up OpRegion GPA/HPA mapping, either by > > > pre-map it (i.e. Xen) or map it during EPT page fault (i.e. KVM), > > > guest can successfully read the content of the OpRegion and check the ID > > string. In this case, everything works fine. > > > > > > 2) if the hypervisor does not setup OpRegion GPA/HPA mapping at all, > > > then guest driver's attempt to setup GVA/GPA mapping will fail, which > > > causes the driver to fail. In this case, guest driver won't have the > > > opportunity to look into the content of OpRegion memory and check the ID > > string. > > > > > > > Guest mapping of GVA->GPA can always succeed regardless of whether > > GPA->HPA is valid. Failure will happen only when the GVA is actually > > accessed by guest. > >
Hi Allen, > That is the data from team debugged IGD passthrough on a closed source > hypervisor that does not map OpRegion with EPT. The end result is the same > -driver cannot access inside of OpRegion without > failing. Define "failing". > > I don't understand 2). If hypervisor doesn't want to setup mapping, there is > > no chance for guest driver to get opregion content, right? > > That was precisely the point I was trying to make. As a result, guest driver > needs some indication from the hypervisor that the address at 0xFC contains > GPA that can be safely accessed by the > driver without causing unrecoverable failure on hypervisors that does not map > OpRegion - by leaving HPA address at 0xFC. I think the thing that doesn't make sense to everyone here is that it's common practice for x86 systems, especially legacy OSes, to probe memory, get back -1 and move on. A hypervisor should support that. So if there's a bogus address in the ASL Storage register and the driver tries to read from the GPA indicated by that address, the VM should at worst get back -1 or a memory space that doesn't contain the graphics signature. If there's a super strict hypervisor that doesn't handle the VM faulting outside of it's address space, that's very prone to exploit. If a driver wants to avoid it anyway, perhaps they should be doing standard things like checking whether the ASL Storage address falls within a reserved memory region rather than coming up with ad-hoc register content based solutions. Thanks, Alex _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel