On Fri, Feb 5, 2016 at 1:34 PM, Tamas K Lengyel <tamas.k.leng...@gmail.com> wrote:
> > > > On Wed, Feb 3, 2016 at 3:35 AM, Andrew Cooper <andrew.coop...@citrix.com> > wrote: > >> On 03/02/16 01:32, Tamas K Lengyel wrote: >> >> >> >> On Tue, Feb 2, 2016 at 6:00 PM, Andrew Cooper <andrew.coop...@citrix.com> >> wrote: >> >>> On 03/02/2016 00:51, Tamas K Lengyel wrote: >>> >>> Hello all, >>> with the latest master branch of Xen there is a regression enabling >>> vm_event on a domain. If an event listener was previously active on the >>> domain it is now not possible to reenable events as the domctl returns >>> -EINVAL. The problem seems to stem from activating the magic page for >>> vm_event using prepare_ring_for_helper as it returns NULL. Further looking >>> into where things go wrong within that function it seems the page type >>> returned by __get_gfn_type_access is p2m_ram_logdirty with an invalid mfn >>> (0xffffffffffffffff) and then it hits "Error path: not a suitable GFN at >>> all". >>> >>> Can anyone point me to which change or what may be causing this? >>> >>> >>> Did the previous event listener replace the page it stole from guest >>> physmap for ring purposes when it exited? >>> >> >> Ah, here is what seems to be the problem. Previously it was not required >> to do this during teardown. What we had was libxc would check if it can map >> the ring page with xc_map_foreign_pages, and it would repopulate the page >> if it failed before running xc_vm_event_enable. However, now it seems >> xc_map_foreign_pages return non-NULL the second time around as well, either >> though the page is not in the physmap. >> >> >> This is the bug then. If there isn't a page in the physmap, >> xc_map_foreign_pages() should indicate an error. >> >> If I enforce libxc to run populate_physmap then I can get vm_event to >> initialize properly again. So the change seems to relate somehow the >> behavior of xc_map_foreign_pages. >> >> >> This seems likely due to the splitting out of libxenforeignmem from >> libxc, which included the the merging of 4? almost identical >> map_foreign_$FOO() functions into one. It is likely that there is a subtle >> change in behaviour on an error path. >> > > I've added a bunch of debug messages and it gets all the way down to > IOCTL_PRIVCMD_MMAPBATCH_V2 without an error in > tools/libs/foreignmemory/linux.c. That ioctl returns 0 too, so I'm not sure > where the error comes from. Compared to the flow in Xen 4.6 I don't really > see what changed.. > > Never mind, found it. The commit "b701ccc8 tools: Remove xc_map_foreign_batch" caused the regression. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
