Re: [kvm-devel] [PATCH 3/3] virtio PCI device
From: Avi Kivity
Date: Tue Nov 27 2007 - 04:25:58 EST
Carsten Otte wrote:
Avi Kivity wrote:
No, definitely not define a hypercall ABI. The feature bit should say
"this device understands a hypervisor-specific way of kicking. consult
your hypervisor manual and cpuid bits for further details. should you
not be satisfied with this method, port io is still available".
...unless you're lucky enough to be on s390 where pio is not available.
I don't see why we'd have two different ways to talk to a virtio
device. I think we should use a hypercall for interrupt injection,
without support for grumpy old soldered pci features other than
HPA-style Lguest PCI bus organization. There are no devices that we
want to be backward compatible with.
pio is useful for qemu, for example, and as a fallback against changing
hypervisor calling conventions. As Anthony points out, it makes a
qemu-implemented device instantly available to Xen at no extra charge.
My wording was inappropriate for s390, though. The politically correct
version reads "this device understands a hypervisor-specific way of
kicking. consult your hypervisor manual and platform-specific way of
querying hypervisor information for further details. should you not be
satisfied with this method, the standard method of kicking virtio
devices on your platform is still available".
On s390, I imagine that "the standard method" is the fabled diag
instruction (which, with the proper arguments, will cook your steak to
the exact shade of medium-rare you desire). So you will never need to
set the "hypervisor-specific way of kicking" bit, as your standard
method is already optimal.
Unfortunately, we have to care for platform differences, subarch
differences (vmx/svm), hypervisor differences (with virtio), and guest
differences (Linux/Windows/pvLinux, 32/64). Much care is needed when
designing the ABI here.
[actually thinking a bit, this is specific to the virtio pci binding;
s390 will never see any of it]
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/