[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] privcmd: MMAPBATCH: Fix error handling/reporting
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |