Carsten Otte wrote:
Avi Kivity wrote:
We intend to bind our virtio devices to PCI too, so that they look the
same in Linux userland across architectures.
Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should seriously consider
using that over the current qemu device emulation based thing.
There are two solutions for this problem:
1. Use hypercalls and supply mechanism for hypercall patching for qemu.
This way we can make s390 & qemu/xen happy.
2. Have two transport mechanism for virtio.
Actually this is what we have today (but not yet merged) - lguest
uses the pci config space
but without using Anthony's pci module.
We'll have virtio host i(qemu/kernel) implementation for the shared
memory and interface.
We'll have pci transport for x86 that glues the above and a virtual
transport for s390 and paravirt_ops.
Both transports will be based on Rusty's config space.
This is the idea I suggested in Tuscon:
----- ------------ ---------
| 9p | | network | | block |
------ ------------ ---------
| virtio interface|
----------------
-----------
--------------------------------------------------
| virtio_pci| OR | virtio_vbus (includes
configs & hypercall/portio) |
-----------
--------------------------------------------------
----------- -------------
| virtio_ring| |virtio_config|
----------- -------------
Regards,
Dor
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel