[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
- To: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
- From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
- Date: Fri, 14 Mar 2014 16:19:59 +0000
- Cc: paolo.valente@xxxxxxxxxx, Keir Fraser <keir@xxxxxxx>, stefano.stabellini@xxxxxxxxxxxxx, Ian.Jackson@xxxxxxxxxxxxx, Julien Grall <julien.grall@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, xen-devel@xxxxxxxxxxxxx, julien.grall@xxxxxxxxxx, etrudeau@xxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxx>, Arianna Avanzini <avanzini.arianna@xxxxxxxxx>, viktor.kleinik@xxxxxxxxxxxxxxx
- Delivery-date: Fri, 14 Mar 2014 16:20:06 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On Fri, 2014-03-14 at 16:45 +0100, Dario Faggioli wrote:
> > > To me, a legitimate use case is this: I want to run version X of my non
> > > DT capable OS on version Z of Xen, on release K of board B. In such
> > > configuration, the GPIO controller is at MFN 0x000abcd, and I want only
> > > VM V to have direct access to it (board B dos not have an IOMMU).
> > >
> > > I would also assume that one is in full control of the guest address
> >
> > If "one" here is the user then I don't think so.
> >
> Well, fact is "user", in this context, is who puts the embedded system
> together into a product, rather than folks actually using such product,
> so, I don't see that much unlikely.
I don't imagine even those folks are going to want to hack the
hypervisor to change the guest address space layout, so I don't think
you can assume they have full control, they will get whatever the layout
for that version of Xen is. They do control the hypervisor version so I
suppose they control in that sense.
If they *are* hacking the hypervisor to fiddle with the guest addres
space then they have no need for this toolstack integration feature,
they can (and likely will) just bodge it in the same place.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
- References:
- [Xen-devel] [RFC PATCH v2 0/3] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM
- [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
|