Am 02.10.2014 10:22, schrieb Heiko Carstens: > On Wed, Oct 01, 2014 at 08:27:38PM +0200, Christian Borntraeger wrote: >> On 10/01/2014 04:17 PM, Alexander Graf wrote: >>> >>> >>> On 01.10.14 16:02, Christian Borntraeger wrote: >>>> There is nothing to do for KVM to support TOD-CLOCK steering. >>>> >>>> Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> >>>> Reviewed-by: David Hildenbrand <dahi@xxxxxxxxxxxxxxxxxx> >>>> --- >>>> arch/s390/kvm/kvm-s390.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c >>>> index 56a411c..0d5aa88 100644 >>>> --- a/arch/s390/kvm/kvm-s390.c >>>> +++ b/arch/s390/kvm/kvm-s390.c >>>> @@ -1786,7 +1786,7 @@ static int __init kvm_s390_init(void) >>>> return -ENOMEM; >>>> } >>>> memcpy(vfacilities, S390_lowcore.stfle_fac_list, 16); >>>> - vfacilities[0] &= 0xff82fff3f4fc2000UL; >>>> + vfacilities[0] &= 0xff82fffbf47c2000UL; >>> >>> Can we please convert this into something readable soon? :) >> >> It will be sooner when you send patches ;-) >> The facility numbers are documented in the POP (chapter 4 last page) in >> IBM notation (bit0 is the MSB) >> It probably makes sense to do this for the non-KVM part as well. When you grep >> for test_facility under arch/s390 there are lots of numerical value. > > These numbers _are_ a wart and were the source of a couple of bugs e.g. > in our ALS code already. > However converting these bitfields to something readable doesn't seem > to be easy, since I'd like to have variable size array initializers which > set the bits depening on the symbolic name (e.g. set bits 19, 20 and 139 > and automatically choose the correct size of the array): > ..something like INIT_FACILITY_ARRAY(FAC19, FAC20, FAC139) > > And of course this should work for asm code as well. > >> Hmm, maybe we can find somebody that wants to increase the patch counter? > > If you think this is trivial, please send a patch which does this. > Unfortunately its not. Well a simple #define KVM_FAC0 = FAC_N3 | FAC_ZARCH | ..... would probably trivial (but error prone). Doing it for the whole tree (including head.S) will be harder. Especially the initial design approach is not trivial (where to put macros, how they look like...). I think we would have to come up with a skeleton and then the replacements itself might be trivial. For KVM we probably want to defer that until we have Michaels CPU model support ready, though. Christian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
