Gregory Haskins wrote:
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....
No, your wheel is slightly faster on the highway, but doesn't work at
all off-road.
Consider nested virtualization where the host (H) runs a guest (G1)
which is itself a hypervisor, running a guest (G2). The host exposes a
set of virtio (V1..Vn) devices for guest G1. Guest G1, rather than
creating a new virtio devices and bridging it to one of V1..Vn, assigns
virtio device V1 to guest G2, and prays.
Now guest G2 issues a hypercall. Host H traps the hypercall, sees it
originated in G1 while in guest mode, so it injects it into G1. G1
examines the parameters but can't make any sense of them, so it returns
an error to G2.
If this were done using mmio or pio, it would have just worked. With
pio, H would have reflected the pio into G1, G1 would have done the
conversion from G2's port number into G1's port number and reissued the
pio, finally trapped by H and used to issue the I/O. With mmio, G1
would have set up G2's page tables to point directly at the addresses
set up by H, so we would actually have a direct G2->H path. Of course
we'd need an emulated iommu so all the memory references actually
resolve to G2's context.
So the upshoot is that hypercalls for devices must not be the primary
method of communications; they're fine as an optimization, but we should
always be able to fall back on something else. We also need to figure
out how G1 can stop V1 from advertising hypercall support.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html