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: <20090506072212.GV3036@sequoia.sous-sol.org>
Date:	Wed, 6 May 2009 00:22:12 -0700
From:	Chris Wright <chrisw@...s-sol.org>
To:	Gregory Haskins <ghaskins@...ell.com>
Cc:	Chris Wright <chrisw@...s-sol.org>,
	Gregory Haskins <gregory.haskins@...il.com>,
	Avi Kivity <avi@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] generic hypercall support

* Gregory Haskins (ghaskins@...ell.com) wrote:
> Chris Wright wrote:
> > But a free-form hypercall(unsigned long nr, unsigned long *args, size_t count)
> > means hypercall number and arg list must be the same in order for code
> > to call hypercall() in a hypervisor agnostic way.
> 
> Yes, and that is exactly the intention.  I think its perhaps the point
> you are missing.

Yes, I was reading this as purely any hypercall, but it seems a bit
more like:
 pv_io_ops->iomap()
 pv_io_ops->ioread()
 pv_io_ops->iowrite()

<snip>
> Today, there is no equivelent of a platform agnostic "iowrite32()" for
> hypercalls so the driver would look like the pseudocode above except
> substitute with kvm_hypercall(), lguest_hypercall(), etc.  The proposal
> is to allow the hypervisor to assign a dynamic vector to resources in
> the backend and convey this vector to the guest (such as in PCI
> config-space as mentioned in my example use-case).  The provides the
> "address negotiation" function that would normally be done for something
> like a pio port-address.   The hypervisor agnostic driver can then use
> this globally recognized address-token coupled with other device-private
> ABI parameters to communicate with the device.  This can all occur
> without the core hypervisor needing to understand the details beyond the
> addressing.

VF drivers can also have this issue (and typically use mmio).
I at least have a better idea what your proposal is, thanks for
explanation.  Are you able to demonstrate concrete benefit with it yet
(improved latency numbers for example)?

thanks,
-chris
--
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/