[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [qemu-s390x] [RFC 14/15] s390-bios: Support booting fro
Re: [Qemu-devel] [qemu-s390x] [RFC 14/15] s390-bios: Support booting from real dasd device
Wed, 18 Jul 2018 09:51:58 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
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
>>> +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
>>> +memory before it starts executing it. This means that any channel commands
>>> +read additional channel commands will not work as expected because the
>>> +read commands will only exist in guest memory and NOT within Qemu's channel
>>> +subsystem memory. Qemu's channel subsystem's implementation currently
>>> +this bit to be on for all channel programs. This is a problem because the
>>> +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
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!
David / dhildenb
Re: [Qemu-devel] [RFC 14/15] s390-bios: Support booting from real dasd device, Halil Pasic, 2018/07/18
Re: [Qemu-devel] [RFC 00/15] s390: vfio-ccw dasd ipl support, no-reply, 2018/07/05
Re: [Qemu-devel] [RFC 00/15] s390: vfio-ccw dasd ipl support, Cornelia Huck, 2018/07/06
- [Qemu-devel] [RFC 02/15] s390-bios: decouple cio setup from virtio, (continued)
- [Qemu-devel] [RFC 02/15] s390-bios: decouple cio setup from virtio, Jason J. Herne, 2018/07/05
- [Qemu-devel] [RFC 11/15] s390-bios: Refactor virtio to run channel programs via cio, Jason J. Herne, 2018/07/05
- [Qemu-devel] [RFC 03/15] s390-bios: decouple common boot logic from virtio, Jason J. Herne, 2018/07/05
- [Qemu-devel] [RFC 07/15] s390-bios: Decouple channel i/o logic from virtio, Jason J. Herne, 2018/07/05
- [Qemu-devel] [RFC 14/15] s390-bios: Support booting from real dasd device, Jason J. Herne, 2018/07/05