Thanks for all the discussion on this. I'll send an updated version of the patch by tomorrow. Thanks, Marc On Wed, May 2, 2018 at 7:53 AM David Hildenbrand <david@xxxxxxxxxx> wrote: > On 02.05.2018 10:03, Janosch Frank wrote: > > On 02.05.2018 09:48, Cornelia Huck wrote: > >> On Wed, 2 May 2018 09:16:50 +0200 > >> Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > >> > >>> On 05/01/2018 12:01 AM, Marc Orr wrote: > >>>> Actually, I don't follow. Radim said: > >>>> "I'd prefer to have one patch that switches all architectures to vzalloc > >>>> (this patch + hunk for x86)..." > >>>> > >>>> But Christian said vzalloc doesn't work for s390. > >>> > >>> I said > >>> --- > >>> I dont think this is necessarily safe. This contains kvm_arch and you > >>> would need to verify that no architecture has data in struct kvm_arch > >>> that must be allocated with kmalloc. Fo example on s390 kernel virtual > >>> == kernel real for kmalloc so some driver might rely on that. > >>> FWIW, it looks like the s390 struct kvm_arch is fine, but this requires > >>> more review I guess. > >>> --- > >>> > >>> so my statement was more on the "it could break" side. > >>> Right now it looks like that most critical data structure (crypto control > >>> block, stfle and others) are already pointers and being allocated > >>> separately but this needs some review. > >>> > >>> David, Conny, Janosch, can you please also check struct kvm_arch on z for > >>> data structures that are passed directly to the hardware? Those will break > >>> if we switch to vzalloc. > >> > >> From what I can see, the structures sensitive to kzalloc vs. vzalloc > >> are all in separately allocated blocks. > > > > Yes, that's also what I can see. > > > Agreed, everything seems to be manually allocated (SCA, cbrlo, vsie > pages), lies in kvm_run (sdnx, riccb) or lies on the sie_page > (sie_block, itdb, crycb, gisa, fac_list). > -- > Thanks, > David / dhildenb
