From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: vm_event regression in 4.7 Date: Wed, 3 Feb 2016 01:00:10 +0000 Message-ID: <56B1511A.6010505@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1981170530018910340==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel , Xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============1981170530018910340== Content-Type: multipart/alternative; boundary="------------070002090406090302090800" This is a multi-part message in MIME format. --------------070002090406090302090800 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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? That error specifically means that the gfn chosen for the ring was not present when prepare_ring_for_helper() was called. A first gut feeling would point to the changed in HVM domain construction stemming from the DMLite work, but if event listening works for the first time and then fails, the magic page was suitably present the first time around. ~Andrew --------------070002090406090302090800 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
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?

That error specifically means that the gfn chosen for the ring was not present when prepare_ring_for_helper() was called.

A first gut feeling would point to the changed in HVM domain construction stemming from the DMLite work, but if event listening works for the first time and then fails, the magic page was suitably present the first time around.

~Andrew
--------------070002090406090302090800-- --===============1981170530018910340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1981170530018910340==--