Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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
tell.

** 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.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel