[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/2] debugexit: support for custom exit port (LG
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [PATCH 1/2] debugexit: support for custom exit port (LGPL VGA BIOS port 0x501) |
Date: |
Fri, 5 Oct 2012 16:09:26 +0000 |
On Fri, Oct 5, 2012 at 2:15 PM, Paolo Bonzini <address@hidden> wrote:
> Il 05/10/2012 15:58, Anthony Liguori ha scritto:
>> Paolo Bonzini <address@hidden> writes:
>>
>>> Il 05/10/2012 14:43, Jan Kiszka ha scritto:
>>>>>>>> This "| 1" might be the problem. Anthony, are you relying on it in
>>>>>>>> qemu-test and/or can you work out the changes if we use just
>>>>>>>> "exit(val)"?
>>>>>>
>>>>>> The reason for ' | 1' was to make sure that the guest couldn't trigger
>>>>>> an exit(0).
>>>>>>
>>>>>> If there's a compelling reason to drop '| 1', I can adjust my tests
>>>>>> accordingly.
>>>> assert(val); (or hw_error)
>>>> exit(val);
>>>>
>>>> I would suggest.
>>>
>>> I think what the kvm_unittests want is exactly to trigger an exit(0).
>>> Why did you rule it out?
>>
>> Mainly to differientiate between an open coded exit(0)/exit(1) and
>> something triggered by the unit test.
>>
>> The problem I tried to cope with was:
>>
>> address@hidden:~/git/qemu$ grep 'exit([01])' hw/*.c | wc -l
>> 249
>
> Understood. The right solution is of course to fix hw/*.c.
While fixing, let's also avoid guest triggerable exits and use logging
for unimplemented features.
>
> Let's start with exit(0).
>
> hw/eeprom93xx.c: exit(0); <--- should be hw_error
> hw/pci.c: exit(0); <--- move to qemu_show_nic_models
> hw/spapr.c: exit(0); <--- should be exit(1) !!
>
> For exit(1), many of them should become hw_error, especially those in
> this files:
>
> hw/bonito.c
> hw/ivshmem.c
> hw/lsi53c895a.c
> hw/pci.c
> hw/pl022.c
> hw/pl061.c
> hw/pl110.c
> hw/qxl.c
> hw/smbus.c
> hw/ssd0303.c
> hw/ssi-sd.c
> hw/stellaris_enet.c
> hw/virtio-blk.c
> hw/virtio.c
> hw/virtio-net.c
> hw/virtio-scsi.c
>
> Any takers?
>
> Paolo
>
>