Re: Design session PVH dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

> And those might
> want to be supported in a generic way. Additionally: what if such a SG-list
> would exceed the size of a page? The dirty bitmap of a guest with 64 GB of
> RAM would already need 512 pages, so the SG-list for that bitmap would already
> fill a complete page assuming only 8 byte for one SG-entry (which would limit
> the general usability already).
> 
> My favorite solution would be some kind of buffer address qualifier for each
> buffer (e.g. virtual, physical, SG-list, maybe nested SG-list). So the new
> hypercalls would not mean "physical buffer addresses", but "qualified buffer
> addresses". By requiring a minimum of 4-byte alignment for each buffer (can we
> do that, at least for the new hypercalls?) this would leave the 2 lowest bits
> of a buffer address for the new qualifier. If by any means an unaligned buffer
> is needed sometimes, it could still be achieved via a single-entry SG-list.

While this might be an option, I'm not sure I'd be really happy with such
re-use of the low address bits, nor with the implied further restriction
on buffer alignment (most struct-s we use are 4-byte aligned at least,
but I don't think it's all of them, plus we also have guest handles to
e.g. arrays of char).

Jan