[Top][All Lists]

[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

From: Tony Krowiak
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device
Date: Fri, 16 Mar 2018 11:53:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

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 "we
need to separate the CPU feature defining 'if AP instructions are available'
from the QEMU property defining 'How we provide the instructions'. I agree and
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.

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]