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

Gregory Haskins
2009-05-06T16:03:49Z

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]