On Sun, Dec 14, 2008 at 02:28:23PM +0200, Blue Swirl wrote:
> On 12/14/08, Gleb Natapov <[email protected]> wrote:
> > There is a need for communication channel between host and various
> > agents that are running inside a VM guest. The channel will be used
> > for statistic gathering, logging, cut & paste, host screen resolution
> > changes notification, guest configuration etc.
>
> Isn't this exactly what the firmware configuration device was supposed
> to be used for? In the list of use cases you gave, I don't see
> anything that could not be done with it.
>
The requirement for firmware configuration interface was different. We
wanted something simple that we can use as early as possible in cpu init
code and performance was not considered at all. Obviously PCI device doesn't
fit for this. We don't want to write PCI driver inside a BIOS and PCI
initialization is too late in HW initialization sequence.
The requirement for vmchannel was that it should allow a guest
to communicate with external (to qemu) process and with reasonable
performance too. Firmware interface that copies data byte at time does
not fit. And obviously firmware interface lacks interrupts, we don't
want to poll for data in a guest.
> So, to avoid duplicated functionality, I'd add the missing pieces to
> the configuration device and if PCI compatibility is desired, the
> firmware configuration device IO port could be handled by a wrapper
> PCI device much like what you proposed.
>
vmchannel code uses virtio subsistem (which was not present in qemu when
firmware interface was added BTW). Theoretically we can use virtio for
FW interface too, but the in guest part of vitio is too complex to be
added to firmware IMO. Lets keep simple things simple.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
