[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A01B4CF.3080706@novell.com>
Date: Wed, 06 May 2009 12:03:27 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Anthony Liguori <anthony@...emonkey.ws>
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
Anthony Liguori wrote:
> Gregory Haskins wrote:
>>
>> 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.
>>
>
> PCI already provide a hypervisor agnostic interface (via IO regions).
> You have a mechanism for devices to discover which regions they have
> allocated and to request remappings. It's supported by Linux and
> Windows. It works on the vast majority of architectures out there today.
>
> Why reinvent the wheel?
I suspect the current wheel is square. And the air is out. Plus its
pulling to the left when I accelerate, but to be fair that may be my
alignment....
:) But I digress. See: http://patchwork.kernel.org/patch/21865/
To give PCI proper respect, I think its greatest value add here is the
inherent IRQ routing (which is a huge/difficult component, as I
experienced with dynirq in vbus v1). Beyond that, however, I think we
can do better.
HTH
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)
Powered by blists - more mailing lists