Re: [PATCH v5 01/11] xen/arm: xc_domain_ioport_permission(..) not supported on ARM.

[Ian Jackson <iwj@xenproject.org>]

Roger Pau Monné writes ("Re: [PATCH v5 01/11] xen/arm: xc_domain_ioport_permission(..) not supported on ARM."):
> On Tue, Oct 12, 2021 at 01:42:22PM -0700, Stefano Stabellini wrote:
> > I don't think it is about performance. From a performance point of view,
> > we could make as many (unneeded) hypercalls as required. It is mostly
> > about minimizing unwanted changes to common libxl code. Let me explain.

Thanks.  This summary is helpful  And, pleasingly, it matches what I
had thought I had gleaned from the thread.

> > All options above achieve the goal of a successful domain creation with
> > PCI device assigned on ARM. You might be able to think of other options
> > as well. I think noone here is really set on using one option over the
> > other -- as long as xc_domain_ioport_permission failures don't turn into
> > domain creation failures on ARM we are good.
> 
> I think having a libxl_arch_io_ports_supported helper could be the
> cleaner way to do this. For x86 it will unconditionally return true,
> while for Arm you could consider poking at
> XEN_DOMCTL_ioport_permission and see if it returns ENOSYS or
> otherwise.

> I guess it's possible that in the future we allow IO ports access on
> Arm guests using some kind of emulated mechanism if the need arises,
> at which point the hypercall will be implemented.

I agree with Roger.

So I think I would like to see a version of this patch which

  * Introduces libxl_arch_io_ports_supported.  (I am fine with it just
    returning false, unconditionally on Arm, ie in libxl_arm.c.)

  * Has a commit message explaining what is actually going on.
    Cutting and pasting liberally from your email seems like it would
    be a very good starting point.  Even discussion of rejected
    alternatives is fine, if it seems like it fits.  I'm quite
    unlikely to object to a commit message on grounds that it's too
    long.

Thanks,
Ian.