On 24/05/17 17:40, Boris Ostrovsky wrote: > On 05/19/2017 11:47 AM, Juergen Gross wrote: >> Add a new config item PARAVIRT_FULL. It will be used to guard the >> pv_*_ops functions used by fully paravirtualized guests (Xen pv-guests >> and lguest) only. >> >> Kernels not meant to support those guest types will be able to use many >> operations without paravirt abstraction while still supporting all the >> other paravirt features. >> >> For now just add the new Kconfig option and select it for XEN_PV and >> LGUEST_GUEST. Add paravirt_full.c, paravirt_full.h and >> paravirt_types_full.h which will contain the necessary implementation >> parts of the pv guest specific paravirt functions. > > Is it not possible to just 'ifdef CONFIG_PARAVIT_FULL' the (ir)relevant > parts of paravirt.[ch] and paravirt_types.c? Sure it is possible. The question is whether we want it. This would be a lot of ifdeffery. The main reason I did it this way was to have a clear split between the two levels of paravirtualization. A kernel built without pv-full would not need to include paravirt[_types]_full.h saving some compilation time (there are lots of source files which are including the paravirt header now). > Separating structures and files into pv and pvfull seems somewhat > arbitrary (.flush_tlb_others in patch 8 being a good example of one type > of guest deciding to use something that normally would be considered > part of a pvfull-type structure). I was thinking of using that for Xen HVM-guests, too. This should speed up multi-vcpu guests quite a bit. In case others think doing it via idefs only would be better I'm ready to change the patches accordingly. Juergen _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
