linux-kernel - Re: Does CONFIG_PARAVIRT imply usage of byte locks?

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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 Jan 2009 23:52:53 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Jeremy Fitzhardinge <jeremy@...p.org>, Avi Kivity <avi@...hat.com>
cc:	Jeremy Fitzhardinge <jeremy@...source.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Does CONFIG_PARAVIRT imply usage of byte locks?

On Sun, 11 Jan 2009, Jeremy Fitzhardinge wrote:

> > Looking at the code, I wonder whether are we in fact really using byte 
> > locks in CONFIG_PARAVIRT situation? Where are we actually setting 
> > pv_lock_ops.spin_lock pointer to point to __byte_spin_lock?
> > 
> > Such initialization seems to happen only in paravirt_use_bytelocks()
> > function, but my blind eyes prevent me from finding a callsite from which
> > this function would eventually get called.
> > 
> > It seems to me that paravirt_use_bytelocks() is a dead code that gets never
> > called, and the same applies to the implementations of write locks. What did
> > I miss?
> 
> Probably nothing.  Xen has its own optimised spinlock implementation, and so
> doesn't use the plain byte locks.  But ticket locks are awesomely bad for any
> virtual environment which doesn't gang schedule VCPUs, so the kvm folks would
> do well to at least consider using them.

Avi, are there any plans to make KVM use byte locks implementation for 
spinlocks in the near future?

If not, we should remove them completely, as it's completely dead code.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/