Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 14 Mar 2014, Ian Campbell wrote:
> > Of course, that may be an issue, when putting Xen underneath, as Xen's
> > mangling with the such address space can cause troubles.
> > 
> > Arianna, can you confirm that this is pretty much the case of Erika, or
> > amend what I did get wrong?
> > 
> > I certainly don't claim to have the right answer but, in the described
> > scenario, either:
> >  1) the combination of iomem=[ MFN,NR@PFN ]", defaulting to 1:1 if  
> >     "@PFN is missing, and e820_host
> >  2) calling (the equivalent of) XEN_DOMCTL_memory_map from the guest 
> >     kernel
> > 
> > would be good solutions, to the point that I think we could even support
> > both. The main point being that, I think, even in the worst case, any
> > erroneous usage of either, would "just" destroy the guest, and that's
> > acceptable.
> 
> I don't think we want both and I'm leaning towards #1 right now, but
> with the e820_host thing being unnecessary in the first instance.

1) looks like the better option to me


> > Actually, if going for 1), I think (when both the pieces are there)
> > things should be pretty safe. Furthermore, implementing 1) seems to me
> > the only way of having the "iomem=[]" parameter causing both permissions
> > granting and mapping. Downside is (libxl side of) the implementation
> > indeed looks cumbersome.
> > 
> > If going for _only_ 2), then "iomem=[]" would just be there to ensure
> > the future mapping operation to be successful, i.e., for granting
> > mapping rights, as it's doing right now. It would be up to the guest
> > kernel to make sure the MFN it is trying to map are consistent with what
> > was specified in "iomem=[]". Given the use case we're talking about, I
> > don't think this is an unreasonable request, as far as we make the iomem
> > man entry more clearly stating this.
> 
> My worry with this one is that it makes might make it harder to DTRT in
> the future, e.g. by adding device tree nodes to represent things mapped
> with iomem=[], by committing us to a world where the guest makes these
> mappings and not the tools.

Yeah, also it requires more guest kernel modifications that might not
always be possible.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel