On 02/04/2013 09:02 AM, Borislav Petkov wrote:
On Mon, Feb 04, 2013 at 08:50:33AM -0500, Rik van Riel wrote:
We need to know whether we are actually running on top of a
hypervisor, not whether we have the code compiled in to do so.
Oh ok, I see.
The thing is, if CONFIG_PARAVIRT_GUEST is disab
On Mon, Feb 04, 2013 at 08:50:33AM -0500, Rik van Riel wrote:
> We need to know whether we are actually running on top of a
> hypervisor, not whether we have the code compiled in to do so.
Oh ok, I see.
The thing is, if CONFIG_PARAVIRT_GUEST is disabled, x86_hyper won't
exist, see: http://marc.in
On 01/26/2013 07:47 AM, Borislav Petkov wrote:
On Sat, Jan 26, 2013 at 01:00:43PM +0100, Ingo Molnar wrote:
+void __init init_spinlock_delay(void)
+{
+ if (x86_hyper)
+ max_spinlock_delay = MAX_SPINLOCK_DELAY_GUEST;
I realize that you took existing code and extended it, but
On Fri, 25 Jan 2013, Rik van Riel wrote:
> Modern Intel and AMD CPUs will trap to the host when the guest
> is spinning on a spinlock, allowing the host to schedule in
> something else.
>
> This effectively means the host is taking care of spinlock
> backoff for virtual machines. It also means tha
On Sat, Jan 26, 2013 at 01:00:43PM +0100, Ingo Molnar wrote:
> > +void __init init_spinlock_delay(void)
> > +{
> > + if (x86_hyper)
> > + max_spinlock_delay = MAX_SPINLOCK_DELAY_GUEST;
>
> I realize that you took existing code and extended it, but that
> chunk of code looks pretty dis
* Rik van Riel wrote:
> static bool smp_no_nmi_ipi = false;
>
> /*
> + * Modern Intel and AMD CPUs tell the hypervisor when a guest is
> + * spinning excessively on a spinlock. The hypervisor will then
> + * schedule something else, effectively taking care of the backoff
> + * for us. Doing
6 matches
Mail list logo
