Hi all,
modularization of TCG is still incomplete in my view: we need to handle the
error case better.
If we configure --enable-modules --enable-tcg --enable-kvm , but for some
reason the .so is not present or is not loaded successfully,
and kvm fails to be enabled (for example, /dev/kvm not av
On 29/07/21 11:14, Gerd Hoffmann wrote:
The common functions could be added TCGCPUOps to allow them being called via
CPUClass->tcg_ops->$name instead of a direct symbol reference. Not sure this
is a good idea though. Experimental patch covering tcg_exec_realizefn +
tcg_exec_unrealizefn below.
Hi,
> > So we need more work to make this actually work right.
>
> Yes. I want have all of tcg in the tcg accel module, not only parts of
> it, but that needs some more refactoring. I'll go start looking at this
> once I managed to wade through my vacation backlog.
So, changed the meson.buil
On Fri, Jul 23, 2021 at 05:27:25PM +0200, Claudio Fontana wrote:
> On 7/23/21 4:36 PM, Jose R. Ziviani wrote:
> > On Fri, Jul 23, 2021 at 04:02:26PM +0200, Claudio Fontana wrote:
> >> On 7/23/21 3:50 PM, Jose R. Ziviani wrote:
> >>> On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote:
>
On 7/23/21 4:36 PM, Jose R. Ziviani wrote:
> On Fri, Jul 23, 2021 at 04:02:26PM +0200, Claudio Fontana wrote:
>> On 7/23/21 3:50 PM, Jose R. Ziviani wrote:
>>> On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote:
On 7/23/21 12:09 AM, Jose R. Ziviani wrote:
> When a module is no
On Fri, Jul 23, 2021 at 04:02:26PM +0200, Claudio Fontana wrote:
> On 7/23/21 3:50 PM, Jose R. Ziviani wrote:
> > On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote:
> >> On 7/23/21 12:09 AM, Jose R. Ziviani wrote:
> >>> When a module is not found, specially accelerators, QEMU displays
On 7/23/21 4:02 PM, Claudio Fontana wrote:
> On 7/23/21 3:50 PM, Jose R. Ziviani wrote:
>> On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote:
>>> On 7/23/21 12:09 AM, Jose R. Ziviani wrote:
When a module is not found, specially accelerators, QEMU displays
a error message tha
On 7/23/21 3:50 PM, Jose R. Ziviani wrote:
> On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote:
>> On 7/23/21 12:09 AM, Jose R. Ziviani wrote:
>>> When a module is not found, specially accelerators, QEMU displays
>>> a error message that not easy to understand[1]. This patch improves
On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote:
> On 7/23/21 12:09 AM, Jose R. Ziviani wrote:
> > When a module is not found, specially accelerators, QEMU displays
> > a error message that not easy to understand[1]. This patch improves
> > the readability by offering a user-friendl
> > bool have_tcg = accel_find("tcg");
> >
> > return true when the code is actually not there, there seems to be a larger
> > issue to solve.
> >
> > I think we need to think more broadly about this.
>
> Overall, building the whole code base to be modular,
> and then _not_ including unwanted m
On 7/23/21 1:20 PM, Claudio Fontana wrote:
> On 7/23/21 11:52 AM, Gerd Hoffmann wrote:
-g_assert(ops != NULL);
+if (ops == NULL) {
+exit(1);
+}
+
>>>
>>>
>>> Ah, again, why?
>>> This change looks wrong to me,
>>>
>>> the ops code should be present when
On 7/23/21 11:52 AM, Gerd Hoffmann wrote:
>>> -g_assert(ops != NULL);
>>> +if (ops == NULL) {
>>> +exit(1);
>>> +}
>>> +
>>
>>
>> Ah, again, why?
>> This change looks wrong to me,
>>
>> the ops code should be present when ops interfaces are initialized:
>> it should be a code l
> > -g_assert(ops != NULL);
> > +if (ops == NULL) {
> > +exit(1);
> > +}
> > +
>
>
> Ah, again, why?
> This change looks wrong to me,
>
> the ops code should be present when ops interfaces are initialized:
> it should be a code level assertion, as it has to do with the prope
On 7/23/21 12:09 AM, Jose R. Ziviani wrote:
> When a module is not found, specially accelerators, QEMU displays
> a error message that not easy to understand[1]. This patch improves
> the readability by offering a user-friendly message[2].
>
> This patch also moves the accelerator ops check to run
Hello Markus
On 7/23/21 10:28 AM, Markus Armbruster wrote:
> "Jose R. Ziviani" writes:
>
>> When a module is not found, specially accelerators, QEMU displays
>> a error message that not easy to understand[1]. This patch improves
>> the readability by offering a user-friendly message[2].
>>
>> Th
"Jose R. Ziviani" writes:
> When a module is not found, specially accelerators, QEMU displays
> a error message that not easy to understand[1]. This patch improves
> the readability by offering a user-friendly message[2].
>
> This patch also moves the accelerator ops check to runtine (instead
> o
On 7/23/21 8:25 AM, Gerd Hoffmann wrote:
> Hi,
>
>> --- a/accel/accel-softmmu.c
>> +++ b/accel/accel-softmmu.c
>> @@ -79,7 +79,10 @@ void accel_init_ops_interfaces(AccelClass *ac)
>> * all accelerators need to define ops, providing at least a mandatory
>> * non-NULL create_vcpu_threa
Hi,
> --- a/accel/accel-softmmu.c
> +++ b/accel/accel-softmmu.c
> @@ -79,7 +79,10 @@ void accel_init_ops_interfaces(AccelClass *ac)
> * all accelerators need to define ops, providing at least a mandatory
> * non-NULL create_vcpu_thread operation.
> */
> -g_assert(ops != NUL
When a module is not found, specially accelerators, QEMU displays
a error message that not easy to understand[1]. This patch improves
the readability by offering a user-friendly message[2].
This patch also moves the accelerator ops check to runtine (instead
of the original g_assert) because it wor
19 matches
Mail list logo
