On 11/25/20 10:30 AM, Paolo Bonzini wrote:
> On 25/11/20 10:21, Claudio Fontana wrote:
>> Hi Paolo,
>>
>> in RFC v5 , module init for ACCEL_CPU is not conditional anymore, right?
>> But the fact that its behavior depends on current_accel() still disqualifies
>> it?
>> It is called right after the
On 11/26/20 12:25 PM, Philippe Mathieu-Daudé wrote:
> On 11/24/20 5:22 PM, Claudio Fontana wrote:
>> apply this to the registration of the cpus accel interfaces,
>>
>> but this will be also in preparation for later use of this
>> new module init step to also register per-accel x86 cpu type
>> inter
On 11/24/20 5:22 PM, Claudio Fontana wrote:
> apply this to the registration of the cpus accel interfaces,
>
> but this will be also in preparation for later use of this
> new module init step to also register per-accel x86 cpu type
> interfaces.
>
> Signed-off-by: Claudio Fontana
> ---
> accel
On 11/25/20 10:30 AM, Paolo Bonzini wrote:
> On 25/11/20 10:21, Claudio Fontana wrote:
>> Hi Paolo,
>>
>> in RFC v5 , module init for ACCEL_CPU is not conditional anymore, right?
>> But the fact that its behavior depends on current_accel() still disqualifies
>> it?
>> It is called right after the
On 25/11/20 10:21, Claudio Fontana wrote:
Hi Paolo,
in RFC v5 , module init for ACCEL_CPU is not conditional anymore, right?
But the fact that its behavior depends on current_accel() still disqualifies it?
It is called right after the accelerator is chosen and initialized
in RFC v5, this still i
On 11/24/20 9:01 PM, Paolo Bonzini wrote:
> On 24/11/20 20:08, Eduardo Habkost wrote:
>>> Not a big advantage I agree,
>>> I think however there is one, in using the existing framework that exists,
>>> for the purposes that it was built for.
>>>
>>> As I understand it, the global module init frame
On 24/11/20 20:08, Eduardo Habkost wrote:
Not a big advantage I agree,
I think however there is one, in using the existing framework that exists, for
the purposes that it was built for.
As I understand it, the global module init framework is supposed to mark the
major initialization steps,
and
On Tue, Nov 24, 2020 at 07:29:50PM +0100, Claudio Fontana wrote:
> On 11/24/20 6:08 PM, Eduardo Habkost wrote:
> > On Tue, Nov 24, 2020 at 05:22:07PM +0100, Claudio Fontana wrote:
> >> apply this to the registration of the cpus accel interfaces,
> >>
> >> but this will be also in preparation for la
On 11/24/20 6:08 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 05:22:07PM +0100, Claudio Fontana wrote:
>> apply this to the registration of the cpus accel interfaces,
>>
>> but this will be also in preparation for later use of this
>> new module init step to also register per-accel x86 cpu
On Tue, Nov 24, 2020 at 05:22:07PM +0100, Claudio Fontana wrote:
> apply this to the registration of the cpus accel interfaces,
>
> but this will be also in preparation for later use of this
> new module init step to also register per-accel x86 cpu type
> interfaces.
>
> Signed-off-by: Claudio Fo
apply this to the registration of the cpus accel interfaces,
but this will be also in preparation for later use of this
new module init step to also register per-accel x86 cpu type
interfaces.
Signed-off-by: Claudio Fontana
---
accel/kvm/kvm-all.c | 11 +--
accel/qtest/qtest.c
11 matches
Mail list logo
