On 26.09.2022 10:33, Juergen Gross wrote: > On 26.09.22 09:53, Jan Beulich wrote: >> On 23.09.2022 10:20, Juergen Gross wrote: >>> On 21.09.22 17:53, Marek Marczykowski-Górecki wrote: >>>> Session description (by Jan): >>>> In the course of working on an XSA I had to finally get PVH Dom0 work on >>>> at least one of my systems, in a minimal fashion. This had turned up a >>>> number of issues, some of which have since remained pending. Therefore I’d >>>> like to gain understanding on whether there is any future to this mode of >>>> Dom0 operation, and if so when it can be expected to be better than tech >>>> preview or even just experimental. >>> >>> ... >>> >>>> Jürgen: PVH dom0 performance? >>>> >>>> Roger: it's bad; mostly relevant is qemu interfaces >>>> >>>> George: only for safety certifications? performance penalty may be okay >>>> >>>> Jürgen: hypercalls can be improved (virtual buffers?) >>> >>> Some more thoughts on this topic: Having hypercall variants with physically >>> addressed buffers will help, but there is an additional complexity: what >>> about hypercalls with really large buffers (e.g. the bitmap for modified >>> pages for guest migration). In order to avoid having to allocate huge >>> physically contiguous buffers for those purposes we'd probably need >>> something like scatter/gather lists for hypercall buffers. >> >> Not sure. I'd rather see us add new (sub)hypercalls for such non-standard >> cases. E.g. the bitmap example you give would be amended by a new flavor >> having the caller pass in an array of GFNs (perhaps, as you say, with >> further indirection to deal with that array also growing large). I'd >> really like to keep the common case simple. > > The question is how many hypercalls would be hit by the not common case. > > Taking a quick glance I spotted: > > - grant_table_op (subops setup_table and get_status_frames) > - memory_op (several sub-ops) > - multicall (main list of calls) > - console_io (console data) > - mmuext_op (some ops allow lists) > - xsm_op (not sure a buffer can span pages, but interface would allow it) > - physdev_op (subop set_iobitmap) > - hvm_op (altp2m handling) > - sysctl (multiple sub-ops) > - domctl (multiple sub-ops) > - hypfs (node data can exceed page size) > > Do we really want to special case all of those?
Looking at the Linux uses of several of the ones covered by the top three entries in your list I find they all use contiguous buffers already, to a fair part because of limiting maximum number of entries. Therefore I don't really think all of these would need special casing, until a reasonable use case is demonstrated where such large lists are actually needed. Jan
