[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 07/10] vm_event: Add vm_event_ng interface


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>
  • Date: Thu, 18 Jul 2019 14:55:41 +0000
  • Accept-language: ro-RO, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=bitdefender.com;dmarc=pass action=none header.from=bitdefender.com;dkim=pass header.d=bitdefender.com;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zF+D2qjGfP/3jdWQI4N2hgLaKkwGcXhi+rST8zAXoDo=; b=IDyNo0KgcjC8Z7ob8082232sGkhGWkv4vwXIb8hAkq5k+ANHjtSZ7KMQHwaVvqtVJ9zrd1Ces1d1baWKjFrYmzCyZXY36ZW3lrPCiLPL4FrBaX7GDhx9rWRzrRZ7Y0EsPFGxaqwdTIOnNHLcsUMmcHNbBZBGIaW1MYvFetGfvvyu8JPG/KV7Q32n2qeOQHx/+1psOFpEJ6l6IFvlcI+srxFWLUT1RdErj2ry1NMmmCRGRKIdMFSD+/DaUs1s/29Cf8yl3DJTeWhSVTXkQ378WxEbBytaz+5dflHHdNW+klaaZ4RPD+evITOg7yW+hlBxBVc3r6b0fyufiJ1utF1n/Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wqf3GNwcr+EX2kjpOuKG1UHyEdjuRPETW8DBVbNLNXIeZI2jfj5Py6ZlA7rAmbH1OfLeqEoG8lCB+ggA+TU4k4OgzjyFxIFMQ40U+ApfZDe0jT2t5XWPwmdwVwcWJmDzT4M72/I87Py3LMIYkrTvuYJ6DL8aF55C5GHTTev3iiFNxCSzoiR4X3mnHDJh02BJA1mPDalqQeQZ0SIyw76kiYEMg8sSUm60DBJBIbgXy7ww0MFpL97JGenwxLC5Nkj5fLrepudWiAYK2jcAqR55wBTBEsGkX9swB/WF+1ONpeRZFqh2jcinb13WvZLMiCvMO8qGiEh1zb+DMSMHVZUNvQ==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=ppircalabu@xxxxxxxxxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, JulienGrall <julien.grall@xxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 18 Jul 2019 14:55:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVO/ji+ep3hd1WrES1BL2P0bM6cabOlq4AgABMy4CAAB8oAIABZ1KAgAAMwoCAAAMRAA==
  • Thread-topic: [PATCH v2 07/10] vm_event: Add vm_event_ng interface

On Thu, 2019-07-18 at 14:44 +0000, Jan Beulich wrote:
> On 18.07.2019 15:59, Petre Ovidiu PIRCALABU wrote:
> > Before using xenforeignmemory_map_resource I investigated several
> > different approaches:
> > - Allocate the memory in hypervisor and xc_map_foreign_pages
> > (doesn't
> > work because you cannot "foreignmap" pages of your own domain.
> > - Allocate the memory in guest, and map the allocated pages in XEN.
> > To
> > my knowledge there is no such API in linux to do this and the
> > monitor
> > application, as an userspace program, is not aware of the actual
> > gfns
> > for an allocated memory area.
> > 
> > So, at this point the most promising solution is allocating the
> > memory
> > in XEN, sharing it with ID using share_xen_page_with_guest, and
> > mapping
> > it with xenforeignmemory_map_resource (with the flag
> > XENMEM_rsrc_acq_caller_owned set)
> 
> Which is fine - that's why Paul had introduced the generic interface.
> 
> > To my understanding the cleanup sequence from
> > gnttab_unpopulate_status_frames basically boils down to:
> > 1. guest_physmap_remove_page
> > 2. if ( test_and_clear_bit(_PGC_allocated, &pg->count_info) )
> >         put_page(pg);
> > 3. free_xenheap_page
> 
> You're missing the crucial part of undoing step 2 if you find
> that there are still references left to the page.
> 
> And then, because of your use of vzalloc(), you can't use
> free_xenheap_pages(), as that takes a (direct map) linear address
> as input. It has to be free_domheap_pages() in your case.
> 
> > My current implementation uses vzalloc instead of
> > alloc_xenheap_pages
> > and that's why I assumed vunmap and free_domheap_pages will suffice
> > (I
> > would have called vfree directly, but the temporary linked list
> > that is
> > used to hold the page references causes free_domheap_pages to
> > crash)
> > 
> > Do I also have to call guest_physmap_remove_page and put_page?
> > (steps
> > 1. and 2.)
> 
> guest_physmap_remove_page() needs to be called for translated page-
> owning domains if the page was ever added to their physmap. As long
> as you avoid adding, you also don't need to remove. I don't recall
> though whether a translated domain can access a resource without it
> having a representation in its GFN space.
> 
> You definitely need to do step 2 (which is to undo the respective
> part of share_xen_page_with_guest(), and you _also_ need to clear
> the page owner (undoing the other part of what that function has
> done). And then, as said above, you need to check that the page
> has no references left on it, and correctly deal with the case when
> it still has some.
> 
> On the whole gnttab_unpopulate_status_frames() is very unfortunate
> to have the way it is, including the various domain_crash()-es. It
> was merely the only way we could see when dealing with XSA-255. I
> would strongly recommend against new code trying to go this same
> route, unless we introduce a generic and clean/safe function
> inverting share_xen_page_with_guest() (which I've tried in the past
> and failed).
> 
> Jan

Thank-you very much for explaining this to me. I will update the
cleanup procedure and let you know the outcome.

Best regards,
Petre

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.