[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
On gio, 2014-03-13 at 17:32 +0000, Ian Campbell wrote: > On Thu, 2014-03-13 at 16:47 +0000, Julien Grall wrote: > > > Sure, but I don't think I see any conflict between this and the approach > > > Ian proposed above. What am I missing? > > > > I believe, Ian was assuming that the user know the layout because this > > solution will be used to a very specific case (I think mostly when the > > device tree won't describe the hardware). > > Right, my assumption was that the kernel was also compiled for the exact > hardware layout as part of some sort of embedded/appliance situation... > Exactly, that may very well be the case. It may not, in Arianna's case, but it well can be true for others, or even for her, in future. Therefore, I keep failing to see why to prevent this to be the case. > > I'm wondering, if we can let the kernel calling the hypercall. He knows > > what is the memory layout of the VM. > > This would be somewhat analogous to what happens with an x86 PV guest. > It would have to be an physmap call or something since this domctl > wouldn't be accessible by the guest. > > That makes a lot of sense actually since this domctl seems to have been > intended for use by the x86 HVM device model (qemu). > I thought about that too. The reason why this was the taken approach is this xen-devel discussion: http://lists.xen.org/archives/html/xen-devel/2013-06/msg00870.html in particular, this Julien's message: http://lists.xen.org/archives/html/xen-devel/2013-06/msg00902.html Also, Eric and Viktor where asking for/working on something similar, so there perhaps would be some good in having this... Eric, Viktor, can you comment why you need this call and how you use, or want to use it for? Would it be the same for you to have it in the form of a physmap call, and invoke it from within the guest kernel? In Arianna's case, it think it would be more than fine to implement it that way, and call it from within the OS, isn't this the case, Arianna? One thing I don't see right now is, in the in-kernel case, what we should do when finding the "iomem=[]" option in a config file. Also, just trying to recap, for Arianna's sake, moving the implementation of the DOMCTL in common code (and implementing the missing bits to make it works properly, of course) is still something we want, right? Regards, dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |