[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <260e7bc9-8cba-bc57-9fe8-0e437562229a@oracle.com>
Date: Wed, 24 May 2017 11:40:12 -0400
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
xen-devel@...ts.xenproject.org, x86@...nel.org,
virtualization@...ts.linux-foundation.org
Cc: jeremy@...p.org, chrisw@...s-sol.org, akataria@...are.com,
rusty@...tcorp.com.au, hpa@...or.com, tglx@...utronix.de,
mingo@...hat.com
Subject: Re: [PATCH 05/10] paravirt: add new PARAVIRT_FULL config item
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?
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).
-boris
Powered by blists - more mailing lists