linux-kernel - Re: [PATCH 1/7] KVM: userspace interface

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45387DEF.9060903@qumranet.com>
Date:	Fri, 20 Oct 2006 09:42:39 +0200
From:	Avi Kivity <avi@...ranet.com>
To:	Anthony Liguori <aliguori@...ibm.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/7] KVM: userspace interface

Anthony Liguori wrote:
>>
>>  writel(dst_x_reg, x);
>>  writel(dst_y_reg, y)
>>  writel(width_reg, w);
>>  writel(height_reg, h);
>>  writel(blt_cmd_reg, fill);
>>
>> then kvm would cache the first four in a mmap()able memory area and 
>> only exit to userspace on the fifth.  Userspace would then read the 
>> cached registers from memory and emulate the command.
>
> Letting QEMU do a certain amount of emulation after every transition 
> would the problem in a more elegant and generic way.
>

But what amount?  A basic block, or several?

Emulation has its costs.  You need to marshal the registers to and fro.  
You need to reset qemu's cached translations.  You need to throw away 
shadow page tables and qemu's softmmu.  You increase the time spent in 
single threaded code.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

-
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/