[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce V
Re: [qemu-s390x] [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device
Fri, 16 Mar 2018 17:26:36 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
On 03/16/2018 04:53 PM, Tony Krowiak wrote:
> On 03/16/2018 11:36 AM, Halil Pasic wrote:
>> On 03/16/2018 04:29 PM, Tony Krowiak wrote:
>>>>> However it is a general switch for the VM.
>>>>> It looks strange to have this inside the realize callback
>>>> I kind of semi agree.
>>>> The previous solution (having this transparent for QEMU) had
>>>> benefits. Why did we move away from that again?
>>> This was done to address the multitude of objections and opinions related to
>>> how/when/where ECA_APIE is set. Pierre summed it up best with his comment
>>> need to separate the CPU feature defining 'if AP instructions are available'
>>> from the QEMU property defining 'How we provide the instructions'. I agree
>>> this is how I chose to implement that.
>> It's even more separated if the one is controlled via a
>> userspace facing interface (cpu models) and the other
>> is controlled via an in-kernel interface (e.g. like
>> done previously in vfio open AFAIR).
> There were objections to that.
AFAIR we agreed that keeping that interface is OK, but I may be wrong.
You being more specific that 'there were objections' and 'multitude
of objections and opinions' would have been appreciated. But never
AFAIU Pierre is nagging you about this in the corresponding kernel
thread. I will let Pierre drive this discussion.
>> I can not accept this answer. I don't recall the multitude
>> and I think I've showed that the 'need to separate' argument
>> does not work.
> I suppose it depends upon how you define multitude. I counted at
> at least 11 - actually more - review comments related to the
> CPU model feature and setting ECA_APIE. I suggest you go back
> and look at the thread.
> Where did you show that the 'need to separate' argument does
> not work?
You answered to that part with 'There were objections to that'.
As I've said before never mind.
[qemu-s390x] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device, Tony Krowiak, 2018/03/15
Re: [qemu-s390x] [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device, Cornelia Huck, 2018/03/27
Re: [qemu-s390x] [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device, Tony Krowiak, 2018/03/16
[qemu-s390x] [PATCH v3 2/7] s390x/ap: base Adjunct Processor (AP) object, Tony Krowiak, 2018/03/15
[qemu-s390x] [PATCH v3 7/7] s390: doc: detailed specifications for AP virtualization, Tony Krowiak, 2018/03/15
[qemu-s390x] [PATCH v3 1/7] linux-headers: linux header updates for AP support, Tony Krowiak, 2018/03/15
- Re: [qemu-s390x] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception, (continued)