[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: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
- From: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
- Date: Fri, 14 Mar 2014 17:25:21 +0100
- 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:25:45 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On ven, 2014-03-14 at 16:19 +0000, Ian Campbell wrote:
> On Fri, 2014-03-14 at 16:45 +0100, Dario Faggioli wrote:
> > > 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.
>
Don't want to speak for someone else, of course. For what I've seen, no,
they're not going to hack Xen, they're going to stick to a specific
version as long as possible.
For different reasons, that's not much different from what happens in
way less embedded contexts, I think. :-)
> They do control the hypervisor version so I
> suppose they control in that sense.
>
Indeed that was the control I meant.
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
Description: This is a digitally signed message part
_______________________________________________
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
- Re: [Xen-devel] [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall
|