Re: Design session PVH dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

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:
>>> 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).
> 
> The unaligned cases could be handled dynamically via the single-entry
> SG-list.

Can they? The first example you gave, the bitmap passed to collect the
output of XEN_DOMCTL_SHADOW_OP_{CLEAN,PEEK}, comes as a handle-of-uint8,
i.e. generally large but not necessarily aligned (even if in practice
the caller likely will pass a page aligned buffer of multiple pages in
size). If we introduced physical-address bases replacement sub-ops, I
think we would make the buffer described by an array of GFNs, not even
allowing sub-page alignment or size.

Jan