Re: [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Sep 09, 2015 at 08:33:52AM -0600, Jan Beulich wrote:
> >>> On 09.09.15 at 16:20, <konrad.wilk@oracle.com> wrote:
> > Perhaps the solution is remove the first printk(s) and just have them
> > once the operation has completed? That may fix the outstanding tasklet
> > problem?
> 
> Considering that this is a tool stack based retry, how would the
> hypervisor know when the _whole_ operation is done?

I was merely thinking of moving the printk _after_ the map_mmio_regions
so there wouldn't be any outstanding preemption points in map_mmio_regions
(so it can at least do the 64 PFNs).

But going forward a couple of ideas:

 - The 64 limit was arbitrary. It could have been 42 or PFNs / num_online_cpus(),
   or actually finding out the size of the BAR and figuring the optimal
   case so that it will be done under 1ms. Or perhaps just provide an
   boot time parameter for those that really are struggling with this.

 - Perhaps add a new API to the P2M code so it can do the operations
   in batches. Our map_mmio_region iterates over every PFN which is
   surely not efficient. Some batching could help? Maybe? What other
   code could benefit from this? Would the boot-time creation of IOMMU
   page-tables also help with this (which takes 10 minutes on a 1TB box
   BTW)

 - This printk can be altogether removed in the hypervisor and moved
   in the toolstack. That is the libxl xc_domain_add_to_physmap
   could itself use the logging facility (xc_report?) the action.
   
> 
> Jan
>