On 26 January 2018 at 16:00, Wei Xu <xuw...@hisilicon.com> wrote:
> If the user pressed some keys in the console during the guest booting,
> the console will be hanged after entering the shell.
> Because in the above case the pl011_can_receive will return 0 that
> the pl011_receive will not be called. That means no interruption will
> be injected in to the kernel and the pl011 state could not be driven
> further.
>
> This patch fixed that issue by checking the interruption is enabled or
> not before putting into the fifo.
>
> Signed-off-by: Wei Xu <xuw...@hisilicon.com>
> ---
> hw/char/pl011.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/char/pl011.c b/hw/char/pl011.c
> index 2aa277fc4f..6296de9527 100644
> --- a/hw/char/pl011.c
> +++ b/hw/char/pl011.c
> @@ -229,6 +229,8 @@ static int pl011_can_receive(void *opaque)
> PL011State *s = (PL011State *)opaque;
> int r;
>
> + if (!s->int_enabled)
> + return 0;
> if (s->lcr & 0x10) {
> r = s->read_count < 16;
> } else {
> --
This doesn't look right. You should be able to use the PL011
in a strictly polling mode, without ever enabling interrupts.
Returning false in can_receive if interrupts are disabled
would break that.
If the user presses keys before interrupts are enabled,
what ought to happen is:
* we put the key in the FIFO, and update the int_level flags
* when the FIFO is full, can_receive starts returning 0 and
QEMU stops passing us new characters
* when the guest driver for the pl011 initializes the
device and enables interrupts then either:
(a) it does something that clears the FIFO, which will
mean can_receive starts allowing new chars again, or
(b) it leaves the FIFO as it is, and we should thus
immediately raise an interrupt for the characters still
in the FIFO; when the guest handles this interrupt and
gets the characters, can_receive will permit new ones
What is happening in your situation that means this is not
working as expected ?
thanks
-- PMM
