Re: [qemu-s390x] [RFC 14/15] s390-bios: Support booting from real dasd device

[David Hildenbrand]

On 18.07.2018 09:40, Cornelia Huck wrote:
> On Tue, 17 Jul 2018 22:43:27 +0200
> David Hildenbrand <address@hidden> wrote:
> 
>> On 05.07.2018 19:25, Jason J. Herne wrote:
> 
>>> +*****************************************
>>> +***** How this all pertains to Qemu *****
>>> +*****************************************
>>> +
>>> +In theory we should merely have to do the following to IPL/boot a guest
>>> +operating system from a DASD device:
>>> +
>>> +1. Place a "Read IPL" ccw into memory location 0x0 with chaining bit on.
>>> +2. Execute channel program at 0x0.
>>> +3. LPSW 0x0.
>>> +
>>> +However, our emulation of the machine's channel program logic is missing 
>>> one key
>>> +feature that is required for this process to work: non-prefetch of ccw 
>>> data.
>>> +
>>> +When we start a channel program we pass the channel subsystem parameters 
>>> via an
>>> +ORB (Operation Request Block). One of those parameters is a prefetch bit. 
>>> If the
>>> +bit is on then Qemu is allowed to read the entire channel program from 
>>> guest
>>> +memory before it starts executing it. This means that any channel commands 
>>> that
>>> +read additional channel commands will not work as expected because the 
>>> newly
>>> +read commands will only exist in guest memory and NOT within Qemu's channel
>>> +subsystem memory. Qemu's channel subsystem's implementation currently 
>>> requires
>>> +this bit to be on for all channel programs. This is a problem because the 
>>> IPL
>>> +process consists of transferring control from the "Read IPL" ccw 
>>> immediately to
>>> +the IPL1 channel program that was read by "Read IPL".
>>> ++  
>>
>> I have way too little insight into channel devices and how QEMU
>> implements them, however I wonder what hinders us from implementing
>> support for !prefetch in QEMU?
>>
>> What you tailored here seems impressive :) Just want to know what the
>> technical background of this prefetch thingy in QEMU is.
> 
> This has to do with how vfio-ccw processes and translates channel
> programs.
> 

Ah, okay, I thought this was *QEMUs* fault, but it actually is
vfio-ccw's fault, and QEMU can't do anything about it.

> Currently, we hand over the chain of channel commands to the kernel to
> be translated (guest->host addresses) and to execute ssch on the real
> subchannel. However, this requires sending the channel program over in
> one go, which makes it impossible for the guest to modify an in-flight
> channel program (there are tricks like putting a suspend marker on a
> channel command and moving that marker forward as you go which make it
> possible to know that a channel command has not yet been processed;
> IIRC the lcs driver in Linux does that, or at least used to do that).
> Our implementation currently does not accommodate that (the Linux dasd
> driver does not use that feature). It's not impossible to implement it,
> but it would require some effort (and I don't think anybody currently
> has spare time for that...)

Spare time, what's that? :)

Thanks for the background info!


-- 

Thanks,

David / dhildenb