On Tue, 5 Dec 2017 08:52:57 +0100 Harald Freudenberger <freude@xxxxxxxxxxxxxxxxxx> wrote: > On 12/02/2017 02:30 AM, Tony Krowiak wrote: > > I agree with your suggestion that defining a new CPU model feature is probably > > the best way to resolve this issue. The question is, should we define a single > > feature indicating whether AP instructions are installed and set features bits > > for the guest based on whether or not they are set in the linux host, or should > > we define additional CPU model features for turning features bits on and off? > > I guess it boils down to what behavior is expected for the AP bus running on > > the linux guest. Here is a rundown of the facilities bits associated with AP > > and how they affect the behavior of the AP bus: > > > > * STFLE.12 indicates whether the AP query function is available. If this bit > > is not set, then the AP bus scan will only test domains 0-15. For example, > > if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are installed, then AP > > queues 04.0047, 05.0047 and 06.0047 will not be made available. > STFLE 12 is the indication for Query AP Configuration Information (QCI) available. > > * STFLE.15 indicates whether the AP facilities test function is available. If > > this bit is not set, then the CEX4, CEX5 and CEX6 device drivers discovered > > by the AP bus scan will not get bound to any AP device drivers. Since the > > AP matrix model supports only CEX4 and greater, no devices will be bound > > to any driver for a guest. > This T-Bit extension to the TAPQ subfunction is a must have. When kvm only > supports CEX4 and upper then this bit could also act as the indicator for > AP instructions available. Of course if you want to implement pure virtual > full simulated AP without any real AP hardware on the host this bit can't > be the indicator. It would probably make sense to group these two together. Or is there any advantage in supporting only a part of it? > > * STFLE.65 indicates whether AP interrupts are available. If this bit is not > > set, then the AP bus will use polling instead of using interrupt handlers > > to process AP events. So, does this indicate "adapter interrupts for AP" only? If so, we should keep this separate and only enable it when we have the gisa etc. ready. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
