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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 09 Sep 2012 15:52:24 +0200
From:	Jan Kiszka <>
To:	Avi Kivity <>
CC:	Xiao Guangrong <>,
	Marcelo Tosatti <>,
	LKML <>, KVM <>
Subject: Re: [PATCH v6 11/12] KVM: introduce readonly memslot

On 2012-09-09 15:42, Avi Kivity wrote:
> On 09/07/2012 02:14 PM, Jan Kiszka wrote:
>>> $ grep __KVM_HAVE include/linux/kvm.h | wc -l
>>> 20
>> Yes, mistakes of the past.
>>> As your suggestion, userspace will always use the CAP even if the CAP
>>> is not really supported. We do not need care the overload on other arches?
>> Generally, userspace can only find out if a CAP is supported by testing
>> during runtime. Sometimes, the CAP may also be used to switch features
>> that are only available on certain archs. But this particular feature
>> should surely become a generic one soon, and the code you could skip in
>> userspace is truly minimal.
> You also need them for build time, to see if the ioctl names and
> structures are defined.  qemu chose not to do this ifdeffery but we must
> not make that choice for other userspace.

I disagree. We switched QEMU to the pattern the kernel officially
recommends: carry your own headers if you cannot rely on a recent
distribution. The only valid use case for #ifdef KVM_CAP is to allow
disabling of generic code that only some archs can make use of.

I'm not arguing for cleaning up legacy CAPs but for applying this rule
on newly introduced ones.


Download attachment "signature.asc" of type "application/pgp-signature" (260 bytes)

Powered by blists - more mailing lists