[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.