[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v2] spapr: add splpar hcalls H_JOIN, H_PROD, H_CON
From: |
Nicholas Piggin |
Subject: |
Re: [Qemu-ppc] [PATCH v2] spapr: add splpar hcalls H_JOIN, H_PROD, H_CONFER |
Date: |
Wed, 17 Apr 2019 21:22:36 +1000 |
User-agent: |
astroid/0.14.0 (https://github.com/astroidmail/astroid) |
David Gibson's on April 17, 2019 10:47 am:
> On Mon, Apr 15, 2019 at 03:06:43PM +1000, Nicholas Piggin wrote:
>> It needs to be cleared at all vCPU dispatch points to SPEC, not just
>> when calling H_CEDE as Ben's patch had. I think complexity would be
>> significant for questionable benefit. Like the dispatch sequence, it
>> seems like the test is trying to cover some race condition for the
>> client but does not really do it well (and for Linux not necessary).
>>
>> prod bit is cleared after vCPU returns from preemption, so it can
>> clear at any time and you can't rely on it, unless you look at
>> dispatch sequence numbers to decipher if it was reset or not.
>>
>> KVM does implement something like the prodded flag as Ben's patch did
>> but that's not to spec AFAIKS.
>
> Hm, ok. Maybe include this rationale in the comment here.
Done (hopefully)
>> > I don't see any sign that H_JOIN is implemented in KVM, although
>> > H_CONFER and H_PROD certainly are.
>>
>> H_JOIN is not.
>
> Right, so we shouldn't be trying to enable it. What will happen if we
> use a KVM H_CONFGER and H_PROD along with a userspace H_JOIN?
Yeah good question I'll have to test before sending the H_JOIN
part again.
May have to modify KVM to make that work properly.
Thanks,
Nick