On 02/05/2012 03:51 AM, Gleb Natapov wrote:
On Sun, Feb 05, 2012 at 11:44:43AM +0200, Avi Kivity wrote:
On 02/05/2012 11:37 AM, Gleb Natapov wrote:
On Thu, Feb 02, 2012 at 06:09:54PM +0200, Avi Kivity wrote:
Device model
------------
Currently kvm virtualizes or emulates a set of x86 cores, with or
without local APICs, a 24-input IOAPIC, a PIC, a PIT, and a number of
PCI devices assigned from the host. The API allows emulating the local
APICs in userspace.
The new API will do away with the IOAPIC/PIC/PIT emulation and defer
them to userspace. Note: this may cause a regression for older guests
that don't support MSI or kvmclock. Device assignment will be done
using VFIO, that is, without direct kvm involvement.
So are we officially saying that KVM is only for modern guest
virtualization?
No, but older guests may have reduced performance in some workloads
(e.g. RHEL4 gettimeofday() intensive workloads).
Reduced performance is what I mean. Obviously old guests will continue working.
An interesting solution to this problem would be an in-kernel device VM.
Most of the time, the hot register is just one register within a more complex
device. The reads are often side-effect free and trivially computed from some
device state + host time.
If userspace had a way to upload bytecode to the kernel that was executed for a
PIO operation, it could either pass the operation to userspace or handle it
within the kernel when possible without taking a heavy weight exit.
If the bytecode can access variables in a shared memory area, it could be pretty
efficient to work with.
This means that the kernel never has to deal with specific in-kernel devices but
that userspace can accelerator as many of its devices as it sees fit.
This could replace ioeventfd as a mechanism (which would allow clearing the
notify flag before writing to an eventfd).
We could potentially just use BPF for this.
Regards,
Anthony Liguori
--
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
