Re: [Xen-devel] [PATCH 2/18 V2]: PVH xen: add XENMEM_add_to_physmap_range

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Mar 19, 2013 at 08:40:06AM +0000, Jan Beulich wrote:
> >>> 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?

There were some patches in the series (I can't recall the names of them
thought) that had some of the PV hypercalls return -EINVAL (or -ENOSYS
as I suggested).

I think it might be better to introduce one patch that would neuter
the PV/HVM hypercalls that we don't want to support or can't yet
(for example b/c we haven't fixed the bugs).

Are you OK if those paths are done in the common code? Meaning say
for the PHYSDEV_op hypercalls some return -ENOSYS?

Or would doing it via the grand hypercall[0->X] table that was in
one of the patches and filtering the unsafe hypercalls? That seems
a much easier way and won't mess with the generic code paths?


> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel