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? > > > > It's a delicate balancing act. My plan is to accompany any changes in > > the standard with a qemu implementation, so we can see how painful those > > changes are. And if there are performance implications, measure them. > > > > 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 -- 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
