On Mon, Nov 23, 2020 at 04:02:24PM +0100, Claudio Fontana wrote:
> On 11/23/20 2:18 PM, Paolo Bonzini wrote:
> > On 23/11/20 10:55, Claudio Fontana wrote:
> >> One idea that came to mind is, why not extend accel.h to user mode?
> >>
> >> It already contains
> >>
> >> #ifndef CONFIG_USER_ONLY
> >>
On 23/11/20 16:02, Claudio Fontana wrote:
Thanks, I'll work on this option.
Btw considering that CpusAccel for tcg is actually three different interfaces
(for mttcg, for icount, and plain RR),
it will be tough to, in the stated objective, "remove all conditionals", even
after removing the
On 11/23/20 2:18 PM, Paolo Bonzini wrote:
> On 23/11/20 10:55, Claudio Fontana wrote:
>> One idea that came to mind is, why not extend accel.h to user mode?
>>
>> It already contains
>>
>> #ifndef CONFIG_USER_ONLY
>>
>> parts, so maybe it was meant to be used by both, and just happened to
>> end
On 23/11/20 10:55, Claudio Fontana wrote:
One idea that came to mind is, why not extend accel.h to user mode?
It already contains
#ifndef CONFIG_USER_ONLY
parts, so maybe it was meant to be used by both, and just happened to
end up confined to include/softmmu ?
Basically I was thinking, we
On 11/23/20 10:29 AM, Claudio Fontana wrote:
> On 11/20/20 7:09 PM, Eduardo Habkost wrote:
>> On Fri, Nov 20, 2020 at 06:41:35PM +0100, Claudio Fontana wrote:
>>> On 11/20/20 6:19 PM, Eduardo Habkost wrote:
On Fri, Nov 20, 2020 at 01:13:33PM +0100, Claudio Fontana wrote:
> On 11/18/20
On 11/20/20 7:09 PM, Eduardo Habkost wrote:
> On Fri, Nov 20, 2020 at 06:41:35PM +0100, Claudio Fontana wrote:
>> On 11/20/20 6:19 PM, Eduardo Habkost wrote:
>>> On Fri, Nov 20, 2020 at 01:13:33PM +0100, Claudio Fontana wrote:
On 11/18/20 11:07 PM, Eduardo Habkost wrote:
> On Wed, Nov 18,
On Fri, Nov 20, 2020 at 06:41:35PM +0100, Claudio Fontana wrote:
> On 11/20/20 6:19 PM, Eduardo Habkost wrote:
> > On Fri, Nov 20, 2020 at 01:13:33PM +0100, Claudio Fontana wrote:
> >> On 11/18/20 11:07 PM, Eduardo Habkost wrote:
> >>> On Wed, Nov 18, 2020 at 08:13:18PM +0100, Paolo Bonzini wrote:
On 11/20/20 6:19 PM, Eduardo Habkost wrote:
> On Fri, Nov 20, 2020 at 01:13:33PM +0100, Claudio Fontana wrote:
>> On 11/18/20 11:07 PM, Eduardo Habkost wrote:
>>> On Wed, Nov 18, 2020 at 08:13:18PM +0100, Paolo Bonzini wrote:
On 18/11/20 18:30, Eduardo Habkost wrote:
>> Adding a layer of
On Fri, Nov 20, 2020 at 01:13:33PM +0100, Claudio Fontana wrote:
> On 11/18/20 11:07 PM, Eduardo Habkost wrote:
> > On Wed, Nov 18, 2020 at 08:13:18PM +0100, Paolo Bonzini wrote:
> >> On 18/11/20 18:30, Eduardo Habkost wrote:
> Adding a layer of indirect calls is not very different from
On 11/18/20 11:07 PM, Eduardo Habkost wrote:
> On Wed, Nov 18, 2020 at 08:13:18PM +0100, Paolo Bonzini wrote:
>> On 18/11/20 18:30, Eduardo Habkost wrote:
Adding a layer of indirect calls is not very different from monkey patching
though.
>>>
>>> I'm a little bothered by monkey patching,
On Wed, Nov 18, 2020 at 08:13:18PM +0100, Paolo Bonzini wrote:
> On 18/11/20 18:30, Eduardo Habkost wrote:
> > > Adding a layer of indirect calls is not very different from monkey
> > > patching
> > > though.
> >
> > I'm a little bothered by monkey patching, but I'm more
> > bothered by having
On 18/11/20 18:30, Eduardo Habkost wrote:
Adding a layer of indirect calls is not very different from monkey patching
though.
I'm a little bothered by monkey patching, but I'm more
bothered by having to:
(1) register (module_init()) a function (kvm_cpu_accel_register()) that
(2) register
On Wed, Nov 18, 2020 at 05:22:46PM +0100, Paolo Bonzini wrote:
> Il mer 18 nov 2020, 17:11 Eduardo Habkost ha scritto:
>
> > On Wed, Nov 18, 2020 at 04:43:19PM +0100, Paolo Bonzini wrote:
> > > Il mer 18 nov 2020, 16:26 Eduardo Habkost ha
> > scritto:
> > >
> > > >
> > > > > The alternative is
Il mer 18 nov 2020, 17:11 Eduardo Habkost ha scritto:
> On Wed, Nov 18, 2020 at 04:43:19PM +0100, Paolo Bonzini wrote:
> > Il mer 18 nov 2020, 16:26 Eduardo Habkost ha
> scritto:
> >
> > >
> > > > The alternative is to store the (type, function) tuple directly,
> with the
> > > > type as a
On Wed, Nov 18, 2020 at 04:43:19PM +0100, Paolo Bonzini wrote:
> Il mer 18 nov 2020, 16:26 Eduardo Habkost ha scritto:
>
> >
> > > The alternative is to store the (type, function) tuple directly, with the
> > > type as a string. Then you can just use type_init.
> >
> > Right. Let's build on
Il mer 18 nov 2020, 16:26 Eduardo Habkost ha scritto:
>
> > The alternative is to store the (type, function) tuple directly, with the
> > type as a string. Then you can just use type_init.
>
> Right. Let's build on top of that:
>
> Another alternative would be to store a (type, X86CPUAccel)
On Wed, Nov 18, 2020 at 03:51:44PM +0100, Paolo Bonzini wrote:
> On 18/11/20 15:36, Eduardo Habkost wrote:
> > On Wed, Nov 18, 2020 at 03:05:42PM +0100, Paolo Bonzini wrote:
> > > On 18/11/20 14:48, Claudio Fontana wrote:
> > > > On 11/18/20 1:48 PM, Eduardo Habkost wrote:
> > > > > I don't get
On 18/11/20 15:36, Eduardo Habkost wrote:
On Wed, Nov 18, 2020 at 03:05:42PM +0100, Paolo Bonzini wrote:
On 18/11/20 14:48, Claudio Fontana wrote:
On 11/18/20 1:48 PM, Eduardo Habkost wrote:
I don't get why we would use a new module initialization level
To have a clear point in time after
On Wed, Nov 18, 2020 at 03:05:42PM +0100, Paolo Bonzini wrote:
> On 18/11/20 14:48, Claudio Fontana wrote:
> > On 11/18/20 1:48 PM, Eduardo Habkost wrote:
> > > On Wed, Nov 18, 2020 at 11:29:35AM +0100, Claudio Fontana wrote:
> > > > apply this to the registration of the cpus accel interfaces,
> >
On 18/11/20 14:48, Claudio Fontana wrote:
On 11/18/20 1:48 PM, Eduardo Habkost wrote:
On Wed, Nov 18, 2020 at 11:29:35AM +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
On 11/18/20 1:48 PM, Eduardo Habkost wrote:
> On Wed, Nov 18, 2020 at 11:29:35AM +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 defer the registration of
On Wed, Nov 18, 2020 at 11:29:35AM +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 defer the registration of the cpu models,
> in order to make them
On 11/18/20 11:29 AM, 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 defer the registration of the cpu models,
this is not true anymore, so my commit message
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 defer the registration of the cpu models,
in order to make them subclasses of a per-accel cpu type.
Signed-off-by: Claudio Fontana
---
24 matches
Mail list logo
