[lkml]   [2009]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

:) But I digress. See:

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.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2009-05-06 18:07    [W:0.152 / U:0.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site