Re: [PATCH RFC] virtio-pci: new config layout: using memory BAR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes:
> On Mon, Jun 03, 2013 at 09:56:15AM +0930, Rusty Russell wrote:
>> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes:
>> > On Thu, May 30, 2013 at 08:53:45AM -0500, Anthony Liguori wrote:
>> >> Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes:
>> >> 
>> >> > Anthony Liguori <aliguori@xxxxxxxxxx> writes:
>> >> >> Forcing a guest driver change is a really big
>> >> >> deal and I see no reason to do that unless there's a compelling reason
>> >> >> to.
>> >> >>
>> >> >> So we're stuck with the 1.0 config layout for a very long time.
>> >> >
>> >> > We definitely must not force a guest change.  The explicit aim of the
>> >> > standard is that "legacy" and 1.0 be backward compatible.  One
>> >> > deliverable is a document detailing how this is done (effectively a
>> >> > summary of changes between what we have and 1.0).
>> >> 
>> >> If 2.0 is fully backwards compatible, great.  It seems like such a
>> >> difference that that would be impossible but I need to investigate
>> >> further.
>> >> 
>> >> Regards,
>> >> 
>> >> Anthony Liguori
>> >
>> > If you look at my patches you'll see how it works.
>> > Basically old guests use BAR0 new ones don't, so
>> > it's easy: BAR0 access means legacy guest.
>> > Only started testing but things seem to work
>> > fine with old guests so far.
>> >
>> > I think we need a spec, not just driver code.
>> >
>> > Rusty what's the plan? Want me to write it?
>> 
>> We need both, of course, but the spec work will happen in the OASIS WG.
>> A draft is good, but let's not commit anything to upstream QEMU until we
>> get the spec finalized.  And that is proposed to be late this year.
>
> Well that would be quite sad really.
> 
> This means we can't make virtio a spec compliant pci express device,
> and we can't add any more feature bits, so no
> flexible buffer optimizations for virtio net.
>
> There are probably more projects that will be blocked.
>
> So how about we keep extending legacy layout for a bit longer:
> - add a way to access device with MMIO
> - use feature bit 31 to signal 64 bit features
>   (and shift device config accordingly)

By my count, net still has 7 feature bits left, so I don't think the
feature bits are likely to be a limitation in the next 6 months?

MMIO is a bigger problem.  Linux guests are happy with it: does it break
the Windows drivers?

Thanks,
Rusty.
--
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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux