Re: [Xen-devel] [PATCH v3 3/5] x86/hyperv: provide percpu hypercall input page

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.01.2020 18:27, Wei Liu wrote:
> On Tue, Jan 07, 2020 at 06:08:19PM +0100, Jan Beulich wrote:
>> On 07.01.2020 17:33, Wei Liu wrote:
>>> On Mon, Jan 06, 2020 at 11:27:18AM +0100, Jan Beulich wrote:
>>>> On 05.01.2020 17:47, Wei Liu wrote:
>>>>> Hyper-V's input / output argument must be 8 bytes aligned an not cross
>>>>> page boundary. The easiest way to satisfy those requirements is to use
>>>>> percpu page.
>>>>
>>>> I'm not sure "easiest" is really true here. Others could consider adding
>>>> __aligned() attributes as easy or even easier (by being even more
>>>> transparent to use sites). Could we settle on "One way ..."?
>>>
>>> Do you mean something like
>>>
>>>    struct foo __aligned(8);
>>
>> If this is in a header and ...
>>
>>>    hv_do_hypercall(OP, virt_to_maddr(&foo), ...);
>>
>> ... this in actual code, then yes.
>>
>>> ?
>>>
>>> I don't think this is transparent to user sites. Plus, foo is on stack
>>> which is 1) difficult to get its maddr,
>>
>> It being on the stack may indeed complicate getting its machine address
>> (if not now, then down the road) - valid point.
>>
>>> 2) may cross page boundary.
>>
>> The __aligned() of course needs to be large enough to avoid this
>> happening.
> 
> For this alignment to be large enough, it will need to be of PAGE_SIZE,
> right? Wouldn't that blow up Xen's stack easily?  Given we only have two
> pages for that.

Why PAGE_SIZE? For example, a 24-byte structure won't cross a page
boundary if aligned to 32 bytes.

> In light of these restrictions, the approach I take in the original
> patch should be okay.
> 
> I'm fine with changing the wording to "One way ..." -- if that's the
> only objection you have after this mail.

Well, the goal was to (a) check whether alternatives have been considered
(and if not, to consider them) and then (b) if we stick to your approach,
slightly change the wording as suggested.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel