[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: Halil Pasic
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device
Date: Fri, 16 Mar 2018 16:36:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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).

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.


reply via email to

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