From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fabio Fantoni Subject: Re: gross qemu behavior Date: Mon, 05 May 2014 12:04:56 +0200 Message-ID: <53676248.2020102@m2r.biz> References: <5335376102000078000033DA@nat28.tlf.novell.com> <53394C620200007800003AE8@nat28.tlf.novell.com> <533E712D02000078000057CE@nat28.tlf.novell.com> <533EE4C10200007800005BE6@nat28.tlf.novell.com> <533EF3480200007800005CD6@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WhFlH-00070s-A3 for xen-devel@lists.xenproject.org; Mon, 05 May 2014 10:04:39 +0000 Received: by mail-ee0-f54.google.com with SMTP id b57so3332794eek.27 for ; Mon, 05 May 2014 03:04:37 -0700 (PDT) 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: Stefano Stabellini , Jan Beulich Cc: anthony.perard@citrix.com, xen-devel , Paolo Bonzini List-Id: xen-devel@lists.xenproject.org Il 04/04/2014 18:54, Stefano Stabellini ha scritto: > On Fri, 4 Apr 2014, Jan Beulich wrote: >>>>> On 04.04.14 at 17:32, wrote: >>> On Fri, 4 Apr 2014, Jan Beulich wrote: >>>>>>> On 04.04.14 at 15:53, wrote: >>>>> On Fri, 4 Apr 2014, Jan Beulich wrote: >>>>>> No, it should just never appear at the wrong address. As I said above, >>>>>> I'd consider it halfway acceptable if it remained mapped despite an >>>>>> unmap, but I do think that a proper solution (properly unmapping >>>>>> without de-allocating) can and should be found. >>>>> There is no way to do it today AFAICT. >>>>> Would you care of proposing an hypercall that would support this >>>>> scenario? >>>> Hypercall? Everything you need is there afaict. >>> Maybe I am missing something. >>> >>> Moving the PCI ROM to the right place in the guest physmap is easy. >>> However how do you think we could unmap the memory (remove it from the >>> guest physmap) without deallocating it? >>> The only hypercall we have is xc_domain_add_to_physmap at the moment. >> XENMEM_remove_from_physmap should be quite suitable here, but >> that is not your problem. The problem is that XENMEM_add_to_physmap >> requires a GFN to be passed in, i.e. assumes that a page to be mapped >> is already mapped somewhere in the guest. (The term "add" in this >> context is rather confusing, as in the GMFN map space case the page >> isn't being added, but moved.) So indeed there is functionality missing >> in the hypervisor. > Right. > > After we call XENMEM_remove_from_physmap, there is no way of adding back > the pages to the physmap without knowing the corresponding mfns. Even > if we knew the mfns of the original allocation, relying on them is > probably not a good idea because the pages could theoretically be > offlined or shared. > > This is the reason why I was asking for the hypercall you had in mind to > solve this problem. Any news about this discussion? Thanks for any reply.