lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 05 Feb 2012 10:36:06 -0600 From: Anthony Liguori <anthony@...emonkey.ws> To: Gleb Natapov <gleb@...hat.com> CC: Avi Kivity <avi@...hat.com>, linux-kernel <linux-kernel@...r.kernel.org>, KVM list <kvm@...r.kernel.org>, qemu-devel <qemu-devel@...gnu.org> Subject: Re: [Qemu-devel] [RFC] Next gen kvm api 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 linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists