Re: [RFC 7/11] virtio_pci: new, capability-aware driver.

[Stefan Hajnoczi <stefanha@xxxxxxxxx>]

On Wed, Jan 11, 2012 at 12:25 AM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> On Tue, 10 Jan 2012 19:03:36 +0200, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote:
>> On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:
>> > Yes.  The idea that we can alter fields in the device-specific config
>> > area is flawed.  There may be cases where it doesn't matter, but as an
>> > idea it was holed to begin with.
>> >
>> > We can reduce probability by doing a double read to check, but there are
>> > still cases where it will fail.
>>
>> Okay - want me to propose an interface for that?
>
> Had a brief chat with BenH (CC'd).
>
> I think we should deprecate writing to the config space.  Only balloon
> does it AFAICT, and I can't quite figure out *why* it has an 'active'
> field.  This solves half the problem, of sync guest writes.  For the
> other half, I suggest a generation counter; odd means inconsistent.  The
> guest can poll.
>
> BenH also convinced me we should finally make the config space LE if
> we're going to change things.  Since PCI is the most common transport,
> guest-endian confuses people.  And it sucks for really weird machines.
>
> We should also change the ring (to a single ring, I think).  Descriptors
> to 24 bytes long (8 byte cookie, 8 byte addr, 4 byte len, 4 byte flags).
> We might be able to squeeze it into 20 bytes but that means packing.  We
> should support inline, chained or indirect.  Let the other side ack by
> setting flag, cookie and len (if written).
>
> Moreover, I think we should make all these changes at once (at least, in
> the spec).  That makes it a big change, and it'll take longer to
> develop, but makes it easy in the long run to differentiate legacy and
> modern virtio.

This is also an opportunity to stop using CPU physical addresses in
the ring and instead perform DMA like a normal PCI device (use bus
addresses).

Stefan
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization