[Lguest] [patch 37/43] lguest: Virtio helper routines for a descriptor ringbuffer implementation
Avi Kivity
avi at qumranet.com
Mon Oct 1 22:13:18 EST 2007
Rusty Russell wrote:
> On Sun, 2007-09-30 at 19:03 +0200, Avi Kivity wrote:
>
>> rusty at rustcorp.com.au wrote:
>>
>>
>>> These helper routines supply most of the virtqueue_ops for hypervisors
>>> which want to use a ring for virtio. Unlike the previous lguest
>>> implementation:
>>>
>>> 1) The rings are variable sized (2^n-1 elements).
>>> 2) They have an unfortunate limit of 65535 bytes per sg element.
>>> 3) The page numbers are always 64 bit (PAE anyone?)
>>> 4) They no longer place used[] on a separate page, just a separate
>>> cacheline.
>>> 5) We do a modulo on a variable. We could be tricky if we cared.
>>> 6) Interrupts and notifies are suppressed using flags within the rings.
>>>
>>> Users need only get the ring pages and provide a notify hook (KVM
>>> wants the guest to allocate the rings, lguest does it sanely).
>>>
>> This fixes an ABI. I don't think we have enough experience with this to
>> set an ABI for 2.6.24. I also owe you a patch for scatter/gather
>> indirection instead of chaining.
>>
>> It is okay to put this in as long as 2.6.24 drivers won't try to talk to
>> 2.6.25+ hosts (which presumably will have a stable ABI). We could do
>> this by having "stable API" feature bit which the new drivers will
>> require, and an "2.6.24 ABI" feature bit which the current drivers will
>> require, but the whole config interface itself is too new for this in my
>> opinion.
>>
>
> Yes, but this is what lguest is for, to play without fixing an ABI. I
> fully expect incompatible tweaks before KVM causes the ABI to nail down.
>
>
I'm worried about users tearing down the "caution, experimental ABI,
will invalidate warranty" sticker from the package, selecting
CONFIG_EXPERIMENTAL, CONFIG_I_REALLY_MEAN_ITS_EXPERIMENTAL, and
CONFIG_I_DONT_CARE_IF_THIS_BLOWS_UP, not reading your blog, and running
2.6.24 guests on top of 2.6.25 or vice versa.
I want the module not to load instead of the guest blowing up.
> And it's going to be far easier to manage lguest-kvm cooperation with
> this in tree than outside.
>
True.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
More information about the Lguest
mailing list