Re: [kvm-devel] [PATCH 2/6] virtio_config
Rusty Russell wrote: A side effect of this is that Xen drivers can no longer use virtio. I'm not so sure. We were always assuming that Xen could do state management in its virtio layer. If this is not true, it implies we need hooks in the virtio drivers, and I don't think we've made it worse by making it translate xenbus config info into virtio_config. This means writing a low-level ABI in terms of a high level API. And while that describes virtualization fairly will, I prefer not to do this more than strictly necessary. However, this can be rewritten if/when Xen or VMware show interest in porting their drivers to virtio. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/6] virtio_config
On Thu, 2007-09-20 at 14:55 +0200, Avi Kivity wrote: Avi Kivity wrote: Rusty Russell wrote: Previous versions of virtio didn't commonalize probing. For every driver, every virtio implementation (KVM, lguest, etc) needed an in-kernel stub to join their bus to the probe code. To solve this, we introduce a virtio_config mechanism, which is simply a set of [u8 type][u8 len][...data...] fields for each device. Some convenient wrapper functions make this fairly easy for drivers to unpack their configuration data themselves. This configuration data could be PCI config space, or an unrelated bus (eg. lguest) or manufactured by the kernel itself. It's designed to be extensible: fields get marked as the device reads them so a host supporting some future extension can tell if the guest driver understood it. This also applies to bitfields: the guest explicitly acks the bits it understands. There's also a simple status bitmask useful for low-level host analysis of what the guest is doing with the device. Lovely. A side effect of this is that Xen drivers can no longer use virtio. I'm not so sure. We were always assuming that Xen could do state management in its virtio layer. If this is not true, it implies we need hooks in the virtio drivers, and I don't think we've made it worse by making it translate xenbus config info into virtio_config. Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/6] virtio_config
Rusty Russell wrote: Previous versions of virtio didn't commonalize probing. For every driver, every virtio implementation (KVM, lguest, etc) needed an in-kernel stub to join their bus to the probe code. To solve this, we introduce a virtio_config mechanism, which is simply a set of [u8 type][u8 len][...data...] fields for each device. Some convenient wrapper functions make this fairly easy for drivers to unpack their configuration data themselves. This configuration data could be PCI config space, or an unrelated bus (eg. lguest) or manufactured by the kernel itself. It's designed to be extensible: fields get marked as the device reads them so a host supporting some future extension can tell if the guest driver understood it. This also applies to bitfields: the guest explicitly acks the bits it understands. There's also a simple status bitmask useful for low-level host analysis of what the guest is doing with the device. Lovely. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/6] virtio_config
Avi Kivity wrote: Rusty Russell wrote: Previous versions of virtio didn't commonalize probing. For every driver, every virtio implementation (KVM, lguest, etc) needed an in-kernel stub to join their bus to the probe code. To solve this, we introduce a virtio_config mechanism, which is simply a set of [u8 type][u8 len][...data...] fields for each device. Some convenient wrapper functions make this fairly easy for drivers to unpack their configuration data themselves. This configuration data could be PCI config space, or an unrelated bus (eg. lguest) or manufactured by the kernel itself. It's designed to be extensible: fields get marked as the device reads them so a host supporting some future extension can tell if the guest driver understood it. This also applies to bitfields: the guest explicitly acks the bits it understands. There's also a simple status bitmask useful for low-level host analysis of what the guest is doing with the device. Lovely. A side effect of this is that Xen drivers can no longer use virtio. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
