Re: [Xen-devel] vm_event regression in 4.7

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Tue, Feb 2, 2016 at 6:00 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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. 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.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel