Re: [Xen-devel] [PATCH] privcmd: MMAPBATCH: Fix error handling/reporting

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Ian Campbell wrote:
> > The noise is just for debugging; if failure is expected, then maybe we 
> > can extend it to be quiet about those cases.
> >     
> In this specific instance going directly at the mmu_udpate interface is
> probably better since the propagation of errors from the multicall
> infrastructure is tricky (well, currently non-existent). I don't think
> multicalls would buy us anything here anyhow since mmu_update is batched
> already.
>   
Yeah.  The generic multicall stuff is (should be) tuned for the common 
case of no errors.  I think this is the first instance of something 
where we expect errors back.  The multicall path is fairly hot, and I 
suspect it's going to need some trimming when the real performance work 
starts, so keeping it low-feature is a good idea.
(Though we could make use of maybe-fail to deal with vmap aliases in 
pte-pinning...)
> > This breaks compiling xenfs as a module; neither flush_tlb_all or 
> > arbitrary_virt_to_machine are exported, I think.
> >     
> Rather than exporting those I think moving remap_domain_mfn_range() to
> core code (with xen_ on the front of the name) and exporting that would
> be cleaner. Thoughts?
>   
Yes, seems reasonable to me.  Though if its arch-neutral, drivers/xen 
would be better.
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel