On 01/24/2017 12:25 PM, Alex Bennée wrote:
> We are talking about doing the necessary annotation to all a givens
> targets loads and stores? I figured this code would morph and be tweaked
> when (if?) we get there.
Fair enough.
r~
Richard Henderson writes:
> On 01/19/2017 09:04 AM, Alex Bennée wrote:
>> +void qemu_tcg_configure(QemuOpts *opts, Error **errp)
>> +{
>> +const char *t = qemu_opt_get(opts, "thread");
>> +if (t) {
>> +if (strcmp(t, "multi") == 0) {
>> +if (TCG_OVERSIZED_GUEST) {
>> +
On 01/19/2017 09:04 AM, Alex Bennée wrote:
> +void qemu_tcg_configure(QemuOpts *opts, Error **errp)
> +{
> +const char *t = qemu_opt_get(opts, "thread");
> +if (t) {
> +if (strcmp(t, "multi") == 0) {
> +if (TCG_OVERSIZED_GUEST) {
> +error_setg(errp, "No M
On Fri, Jan 20, 2017 at 9:50 AM, Alex Bennée wrote:
>
> That's the wrong way round. TCG_DEFAULT_MO is the guest memory order.
> Maybe I should rename them to be explicitly:
>
> TCG_GUEST_DEFAULT_MO
> TCG_HOST_DEFAULT_MO
>
> But that introduces another terminology into the TCG code.
>
Ah, that's n
Pranith Kumar writes:
> Alex Bennée writes:
>
>> From: KONRAD Frederic
>>
>> We know there will be cases where MTTCG won't work until additional work
>> is done in the front/back ends to support. It will however be useful to
>> be able to turn it on.
>>
>> As a result MTTCG will default to off
Alex Bennée writes:
> From: KONRAD Frederic
>
> We know there will be cases where MTTCG won't work until additional work
> is done in the front/back ends to support. It will however be useful to
> be able to turn it on.
>
> As a result MTTCG will default to off unless the combination is
> suppor
From: KONRAD Frederic
We know there will be cases where MTTCG won't work until additional work
is done in the front/back ends to support. It will however be useful to
be able to turn it on.
As a result MTTCG will default to off unless the combination is
supported. However the user can turn it on
