On 11/10/20 4:23 PM, Eduardo Habkost wrote:
> On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
>> On 10/11/20 11:04, Daniel P. Berrangé wrote:
>>>
>>> ie, we should have one class hierarchy for CPU model definitions, and
>>> one class hierarchy for accelerator CPU implementations.
>>
On 11/10/20 7:14 PM, Eduardo Habkost wrote:
> On Tue, Nov 10, 2020 at 06:38:49PM +0100, Claudio Fontana wrote:
>> On 11/10/20 4:23 PM, Eduardo Habkost wrote:
>>> On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
On 10/11/20 11:04, Daniel P. Berrangé wrote:
>
> ie, we shoul
On Tue, Nov 10, 2020 at 09:39:37PM +0100, Paolo Bonzini wrote:
> On 10/11/20 18:55, Eduardo Habkost wrote:
> > > I think we should not try yo implement interfaces conditionally (i.e. have
> > > TYPE_X86_ACCEL implemented only on qemu-system-{i386,x86_64} and not
> > > qemu-system-arm), even if tech
On 10/11/20 18:55, Eduardo Habkost wrote:
I think we should not try yo implement interfaces conditionally (i.e. have
TYPE_X86_ACCEL implemented only on qemu-system-{i386,x86_64} and not
qemu-system-arm), even if technically the accel/ objects are per-target
(specific_ss) rather than common.
If t
On Tue, Nov 10, 2020 at 06:38:49PM +0100, Claudio Fontana wrote:
> On 11/10/20 4:23 PM, Eduardo Habkost wrote:
> > On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
> >> On 10/11/20 11:04, Daniel P. Berrangé wrote:
> >>>
> >>> ie, we should have one class hierarchy for CPU model defini
On Tue, Nov 10, 2020 at 05:05:27PM +0100, Paolo Bonzini wrote:
> On 10/11/20 16:23, Eduardo Habkost wrote:
> > On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
> > > On 10/11/20 11:04, Daniel P. Berrangé wrote:
> > > >
> > > > ie, we should have one class hierarchy for CPU model defi
On 11/10/20 4:23 PM, Eduardo Habkost wrote:
> On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
>> On 10/11/20 11:04, Daniel P. Berrangé wrote:
>>>
>>> ie, we should have one class hierarchy for CPU model definitions, and
>>> one class hierarchy for accelerator CPU implementations.
>>
On 10/11/20 16:23, Eduardo Habkost wrote:
On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
On 10/11/20 11:04, Daniel P. Berrangé wrote:
ie, we should have one class hierarchy for CPU model definitions, and
one class hierarchy for accelerator CPU implementations.
So at runtime w
On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
> On 10/11/20 11:04, Daniel P. Berrangé wrote:
> >
> > ie, we should have one class hierarchy for CPU model definitions, and
> > one class hierarchy for accelerator CPU implementations.
> >
> > So at runtime we then get two object in
On 10/11/20 11:04, Daniel P. Berrangé wrote:
ie, we should have one class hierarchy for CPU model definitions, and
one class hierarchy for accelerator CPU implementations.
So at runtime we then get two object instances - a CPU implementation
and a CPU definition. The CPU implementation object
On 11/10/20 11:04 AM, Daniel P. Berrangé wrote:
> On Tue, Nov 10, 2020 at 10:40:04AM +0100, Claudio Fontana wrote:
>> On 11/9/20 7:03 PM, Daniel P. Berrangé wrote:
>>> On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote:
split cpu.c into:
cpu.ccpuid and common
On Tue, Nov 10, 2020 at 10:40:04AM +0100, Claudio Fontana wrote:
> On 11/9/20 7:03 PM, Daniel P. Berrangé wrote:
> > On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote:
> >> split cpu.c into:
> >>
> >> cpu.ccpuid and common x86 cpu functionality
> >> host-cpu.c host x
Hello Eduardo,
thank you for your answer,
On 11/9/20 8:04 PM, Eduardo Habkost wrote:
> On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote:
>> split cpu.c into:
>>
>> cpu.ccpuid and common x86 cpu functionality
>> host-cpu.c host x86 cpu functions and "host" cpu type
On 11/9/20 7:03 PM, Daniel P. Berrangé wrote:
> On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote:
>> split cpu.c into:
>>
>> cpu.ccpuid and common x86 cpu functionality
>> host-cpu.c host x86 cpu functions and "host" cpu type
>> kvm-cpu-type.c KVM x86 cpu type
>>
On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote:
> split cpu.c into:
>
> cpu.ccpuid and common x86 cpu functionality
> host-cpu.c host x86 cpu functions and "host" cpu type
> kvm-cpu-type.c KVM x86 cpu type
> hvf-cpu-type.c HVF x86 cpu type
> tcg-cpu-type.c
On Mon, Nov 09, 2020 at 06:27:54PM +0100, Claudio Fontana wrote:
> split cpu.c into:
>
> cpu.ccpuid and common x86 cpu functionality
> host-cpu.c host x86 cpu functions and "host" cpu type
> kvm-cpu-type.c KVM x86 cpu type
> hvf-cpu-type.c HVF x86 cpu type
> tcg-cpu-type.c
On 09/11/20 18:27, Claudio Fontana wrote:
Defer the x86 models registration to MODULE_INIT_ACCEL_CPU, so that
accel-specific types can be used as parent types for all cpu models. Use
the generic TYPE_X86_CPU only if no accel-specific specialization is
enabled.
Can we use an accel-specific ops
On 09/11/20 18:27, Claudio Fontana wrote:
|softmmu/vl.c | 2 +- target/i386/accel/hvf/hvf-cpu-type.c | 78 +
target/i386/accel/hvf/meson.build | 1 +
target/i386/accel/kvm/kvm-cpu-type.c | 161 ++
target/i386/accel/kvm/kvm-cpu-type.h | 41 +++
target/i386/accel/kvm/kvm.c | 3 +- target/i
split cpu.c into:
cpu.ccpuid and common x86 cpu functionality
host-cpu.c host x86 cpu functions and "host" cpu type
kvm-cpu-type.c KVM x86 cpu type
hvf-cpu-type.c HVF x86 cpu type
tcg-cpu-type.c TCG x86 cpu type
Defer the x86 models registration to MODULE_INIT_ACCEL_CPU,
s
19 matches
Mail list logo