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]

Date:	Thu, 07 May 2009 15:29:09 -0400
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Chris Wright <chrisw@...s-sol.org>
CC:	Gregory Haskins <ghaskins@...ell.com>, Avi Kivity <avi@...hat.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Anthony Liguori <anthony@...emonkey.ws>
Subject: Re: [RFC PATCH 0/3] generic hypercall support

Chris Wright wrote:
> * Gregory Haskins (ghaskins@...ell.com) wrote:
>   
>> Chris Wright wrote:
>>     
>>> * Avi Kivity (avi@...hat.com) wrote:
>>>       
>>>> Gregory Haskins wrote:
>>>>         
>>>>> Cool,  I will code this up and submit it.  While Im at it, Ill run it
>>>>> through the "nullio" ringer, too. ;)  It would be cool to see the
>>>>> pv-mmio hit that 2.07us number.  I can't think of any reason why this
>>>>> will not be the case.
>>>>>       
>>>>>           
>>>> Don't - it's broken.  It will also catch device assignment mmio and  
>>>> hypercall them.
>>>>         
>>> Not necessarily.  It just needs to be creative w/ IO_COND
>>>       
>> Hi Chris,
>>    Could you elaborate?  How would you know which pages to hypercall and
>> which to let PF?
>>     
>
> Was just thinking of some ugly mangling of the addr (I'm not entirely
> sure what would work best).
>   
Right, I get the part about flagging the address and then keying off
that flag in IO_COND (like we do for PIO vs MMIO).

What I am not clear on is how you would know to flag the address to
begin with.

Here's a thought: "PV" drivers can flag the IO (e.g. virtio-pci knows it
would never be a real device).  This means we route any io requests from
virtio-pci though pv_io_ops->mmio(), but not unflagged addresses.  This
is not as slick as boosting *everyones* mmio speed as Avi's original
idea would have, but it is perhaps a good tradeoff between the entirely
new namespace created by my original dynhc() proposal and leaving them
all PF based.

This way, its just like using my dynhc() proposal except the mmio-addr
is the substitute address-token (instead of the dynhc-vector). 
Additionally, if you do not PV the kernel the IO_COND/pv_io_op is
ignored and it just slow-paths through the PF as it does today.  Dynhc()
would be dependent  on pv_ops.

Thoughts?

-Greg

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