Re: [libvirt] [PATCH] vl: allow "cont" from panicked state
On 08/22/13 11:19, Paolo Bonzini wrote:
Il 22/08/2013 10:38, Laszlo Ersek ha scritto:
>>> To support 1.5, libvirt should simply be ready to react to unanticipated
>>> GUEST_PANICKED events. reboot-on-panic will simply be broken for 1.5
>>> and Linux 3.10+ guests. :(
> I'm probably misunderstanding the discussion, but it might be possible
> to disable pvpanic even in 1.5 from the host side, with the following hack:
>
> -global pvpanic.ioport=0
>
> In qemu, this will either configure a working pvpanic device on ioport
> 0, or the pvpanic device will be genuinely broken. At least it doesn't
> (obviously) break other stuff (in v1.5.2):
>
> (qemu) info mtree
> I/O
> 0000000000000000-000000000000ffff (prio 0, RW): io
> 0000000000000000-0000000000000000 (prio 0, RW): pvpanic
> 0000000000000000-0000000000000007 (prio 0, RW): dma-chan
No, you're not misunderstanding the discussion.
Depending on the priorities of the pvpanic and legacy-DMA regions, it
would break DMA channel 0.
<academic>
I think before priority comes into the picture, the access size would
matter first, no?
(I think I'm recalling this from the 0xCF9 reset control register, which
falls into the [0xCF8..0xCFA] range.)
Unless ioport 0 is accessed with width 1 for dma-chan purposes, I think
such an access would be unique to pvpanic, and always dispatched to pvpanic.
Channel 0 is (was) used for DRAM refresh, so
it should not have any visible effect. However, it may not be entirely
disabling pvpanic, just making it mostly invisible.
That's good enough for the guest to reach kexec :)
</academic>
Laszlo