This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in tools

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm)
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Tue, 16 Nov 2010 09:26:26 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "bruce.edge@xxxxxxxxx" <bruce.edge@xxxxxxxxx>, Gianni, Tedesco <gianni.tedesco@xxxxxxxxxx>
Delivery-date: Tue, 16 Nov 2010 01:27:26 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CE1D921.2010703@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4CE18AD6.5070102@xxxxxxxx> <C907413B.A0AD%keir@xxxxxxx> <20101115231133.GA12364@xxxxxxxxxxxx> <4CE1D921.2010703@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2010-11-16 at 01:06 +0000, Jeremy Fitzhardinge wrote:
> > How does that work on the Xen side? Does the hypervisor depend on
> the pages
> > that belong to the DOM_IO domain to have a INVALID_MFN value in the
> mfn_list?
> Xen wouldn't care.  I don't think its necessary to explicitly do a
> cross-domain mapping with DOM_IO as we currently do; that's overkill
> and/or a misunderstanding on my part.
> > We do make the PTE that refer to physical devices to be the DOM_IO
> domain..
> I think Xen will sort that out for itself when presented with a
> hardware/device mfn. 

My main concern would be with save/restore code will canonicalise all
the MFNs in the page tables back into PFNs and then convert back to MFNs
on the other side, which is likely to go pretty wrong on one end of the
other unless the save restore code is aware of which MFNs are device
MFNs and which are actual memory. I'm not sure there is any way it can

** scrobbles around in xc_domain_save.c **

Hrmm... The MFN_IS_IN_PSEUDOPHYS_MAP macro might have some impact on
this issue in some way (depending on what the m2p contains for DOM_IO
owned pages) but I don't think it actually fixes anything. I don't see
anything else which would make this work... Best case as it stands
AFAICT is that MFN_IS_IN_PSEUDOPHYS_MAP causes device mappings to get
zapped requiring the kernel to reinstate them on restore. Which isn't so
bad I guess.

On an unrelated note I think if we do go down the route of having the
guest kernel punch the holes itself and such we should do so iff
XENMEM_memory_map returns either ENOSYS or nr_entries == 1 to leave open
the possibility of cunning tricks on the tools side in the future.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>