Re: [Xen-devel] [PATCH 05/10] paravirt: add new PARAVIRT_FULL config item

[Juergen Gross <jgross@xxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel