[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/18 V2]: PVH xen: add XENMEM_add_to_physmap_range
>>> On 18.03.13 at 21:15, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > On Mon, Mar 18, 2013 at 11:38:35AM +0000, Jan Beulich wrote: >> >>> On 16.03.13 at 01:20, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote: >> > In this patch we add a new function xenmem_add_to_physmap_range(), and >> > change xenmem_add_to_physmap_once parameters so it can be called from >> > xenmem_add_to_physmap_range. There is no PVH specific change here. >> > >> > Changes in V2: >> > - Do not break parameter so xenmem_add_to_physmap_once() but pass in >> > struct xen_add_to_physmap. >> > >> > Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> >> > --- >> > xen/arch/x86/mm.c | 82 > +++++++++++++++++++++++++++++++++++++++++++++++++++-- >> > 1 files changed, 79 insertions(+), 3 deletions(-) >> >> This continued to lack compat mode support (i.e. modification to >> xen/arch/x86/x86_64/compat/mm.c:compat_arch_memory_op()). > > Do we need it? Only 64-bit kernels can use PVH - and that was from the start > the idea. I wasn't really aware of that, but I certainly do mind implementing a hypercall usable by a PV or HVM guest only half way. Or did I overlook code refusing the particular sub-op for plain PV and plain HVM guests? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |