Re: [Qemu-devel] [qemu-s390x] [PATCH v4 09/10] s390-ccw: read user input for boot index via the SCLP console

[David Hildenbrand]

On 29.01.2018 15:38, Collin L. Walling wrote:
> On 01/29/2018 08:08 AM, David Hildenbrand wrote:
>> On 23.01.2018 19:26, Collin L. Walling wrote:
>>> Implements an sclp_read function to capture input from the
>>> console and a wrapper function that handles parsing certain
>>> characters and adding input to a buffer. The input is checked
>>> for any erroneous values and is handled appropriately.
>>>
>>> A prompt will persist until input is entered or the timeout
>>> expires (if one was set). Example:
>>>
>>>      Please choose (default will boot in 10 seconds):
>>>
>>> Correct input will boot the respective boot index. If the
>>> user's input is empty, 0, or if the timeout expires, then
>>> the default zipl entry will be chosen. If the input is
>>> within the range of available boot entries, then the
>>> selection will be booted. Any erroneous input will cancel
>>> the timeout and re-prompt the user.
>>>
>>> Signed-off-by: Collin L. Walling <address@hidden>
>>> ---
>> Also, a very nasty thing to take care of is the following:
>>
>> SCLP and ckc interrupt at the same time pending.
>>
>> -> We only dequeue one, the other remains pending and is presented to
>> the guest
>>
> 
> If I understand the assembler correctly, consume_sclp_int() takes care 
> of enabling /
> disabling the service interrupts for us.
> 
> However, I /do/like the refactoring suggestion you made in a previous 
> reply.  It makes
> things easier to read.
> 
> If it makes sense to do so (such that the refactoring doesn't end up 
> taking me down a
> rabbit hole) I'll spin up another patch that refactors the enabling / 
> disabling of
> the service interrupt.
> 

The problem I am mentioning is unrelated to the current code / refactoring.

If we have
- 1 service IRQ
- 1 ckc IRQ

pending at the same time (which is now possible), consume_sclp_int()
will only dequeue exactly __one__ of them.

And as the CKC IRQ have higher priority, they will get dequeued, leaving
the (bad) service IRQ queued.

This is something you will have to take care of - unrelated to the the
requested refactoring.

-- 

Thanks,

David / dhildenb