lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 24 May 2017 18:39:50 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ