On 26 September 2018 at 11:35, Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
> Hi Peter,
>
> On 9/25/18 4:41 PM, Peter Maydell wrote:
>> In commit c79c0a314c43b78 we enabled emulation of external aborts
>> when the guest attempts to access a physical address with no
>> mapped device. In commit 4672cbd7bed88dc6 we suppress this for
>> most legacy boards to prevent breakage of previously working
>> guests, but we didn't suppress it in the 'virt' board, with
>> the rationale "we know that guests won't try to prod devices
>> that we don't describe in the device tree or ACPI tables". This
>> is mostly true, but we've had a report of a Linux guest image
>> that this did break. The problem seems to be that the guest
>> is (incorrectly) configured with a DEBUG_UART_PHYS value that
>> tells it there is a uart at 0x10009000 (which is true for
>> vexpress but not for virt), so in early bootup the kernel
>> probes this bogus address.
>>
>> This is a misconfigured guest, so we don't need to worry
>> about it too much, but we can arrange that guests that ran
>> on QEMU v2.10 (before c79c0a314c43b78) will still run on
>> the "virt-2.10" board model, by suppressing external aborts
>> only for that version and earlier. This seems a reasonable
>> compromise.
>
> I tried another approach to keep MEMTX_DECODE_ERROR delivered (out of
> 0x10009000) for 2.10, using the UNIMP device, but the code looks uglier
> (create too much generic code for a single issue):

I definitely don't want to do that...

> I prefer your compromise.
>
>>
>> Cc: qemu-sta...@nongnu.org
>> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
>> ---
>>  hw/arm/virt.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 0b57f87abcb..3ba310a37b6 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -1926,6 +1926,7 @@ static void virt_machine_2_10_options(MachineClass *mc)
>>  {
>>      virt_machine_2_11_options(mc);
>>      SET_MACHINE_COMPAT(mc, VIRT_COMPAT_2_10);
>
> Can you add a short comment here?
>
>        /* See https://bugs.launchpad.net/qemu/+bug/???:
>         * Some misconfigured Linux guest poke for vexpress uart
>         * at 0x10009000 */

I view it as more "virt-2.10 is supposed to behave like
the 2.10 release virt" rather than a specific fix for
this guest, I think.

thanks
-- PMM

Reply via email to