linux-kernel - Re: [RFC PATCH 0/3] generic hypercall support

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]

Message-ID: <4A08663D.1010703@codemonkey.ws>
Date:	Mon, 11 May 2009 12:54:05 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Hollis Blanchard <hollisb@...ibm.com>
CC:	Gregory Haskins <ghaskins@...ell.com>, Avi Kivity <avi@...hat.com>,
	Chris Wright <chrisw@...s-sol.org>,
	Gregory Haskins <gregory.haskins@...il.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] generic hypercall support

Hollis Blanchard wrote:
> On Sun, 2009-05-10 at 13:38 -0500, Anthony Liguori wrote:
>   
>> Gregory Haskins wrote:
>>     
>>> Can you back up your claim that PPC has no difference in performance
>>> with an MMIO exit and a "hypercall" (yes, I understand PPC has no "VT"
>>> like instructions, but clearly there are ways to cause a trap, so
>>> presumably we can measure the difference between a PF exit and something
>>> more explicit).
>>>       
>> First, the PPC that KVM supports performs very poorly relatively 
>> speaking because it receives no hardware assistance  this is not the 
>> right place to focus wrt optimizations.
>>
>> And because there's no hardware assistance, there simply isn't a 
>> hypercall instruction.  Are PFs the fastest type of exits?  Probably not 
>> but I honestly have no idea.  I'm sure Hollis does though.
>>     
>
> Memory load from the guest context (for instruction decoding) is a
> *very* poorly performing path on most PowerPC, even considering server
> PowerPC with hardware virtualization support. No, I don't have any data
> for you, but switching the hardware MMU contexts requires some
> heavyweight synchronization instructions.
>   

For current ppcemb, you would have to do a memory load no matter what, 
right?  I guess you could have a dedicated interrupt vector or something...

For future ppcemb's, do you know if there is an equivalent of a PF exit 
type?  Does the hardware squirrel away the faulting address somewhere 
and set PC to the start of the instruction?  If so, no guest memory load 
should be required.

Regards,

Anthony Liguori
--
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/