"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. Since I'm going to have to reformat the spec and adapt it into OASIS style anyway, perhaps you should prepare a description as a standalone text document. Easier to email and work with... Now, the idea is that if you want to support 0.9 and 1.0 (or whatever we call them; I used the term "legacy" for existing implementations in the OASIS WG proposal), you add capabilities and don't point them into (the start of?) BAR0. Old drivers use BAR0 as now. One trick to note: while drivers shouldn't use both old and new style on the same device, you need to allow it for kexec, particularly reset via BAR0. Cheers, 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
