Chris Wright wrote: > * Gregory Haskins (ghaskins@xxxxxxxxxx) 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() > Right. > <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)? > I had a test-harness/numbers for this kind of thing, but its a bit crufty since its from ~1.5 years ago. I will dig it up, update it, and generate/post new numbers. Thanks Chris, -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
