From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:48322)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <xiaoguangrong@linux.vnet.ibm.com>)
	id 1TTSJ9-0003wP-Dt
	for qemu-devel@nongnu.org; Wed, 31 Oct 2012 03:01:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <xiaoguangrong@linux.vnet.ibm.com>)
	id 1TTSJ3-0000OX-MW
	for qemu-devel@nongnu.org; Wed, 31 Oct 2012 03:01:47 -0400
Received: from e28smtp04.in.ibm.com ([122.248.162.4]:52387)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <xiaoguangrong@linux.vnet.ibm.com>)
	id 1TTSJ3-0000O0-0a
	for qemu-devel@nongnu.org; Wed, 31 Oct 2012 03:01:41 -0400
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <qemu-devel@nongnu.org> from <xiaoguangrong@linux.vnet.ibm.com>;
	Wed, 31 Oct 2012 12:31:34 +0530
Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65])
	by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q9V71VIG27132136
	for <qemu-devel@nongnu.org>; Wed, 31 Oct 2012 12:31:31 +0530
Received: from d28av03.in.ibm.com (loopback [127.0.0.1])
	by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q9V71URw021730
	for <qemu-devel@nongnu.org>; Wed, 31 Oct 2012 18:01:31 +1100
Message-ID: <5090CCC7.9060503@linux.vnet.ibm.com>
Date: Wed, 31 Oct 2012 15:01:27 +0800
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
MIME-Version: 1.0
References: <50890462.5010307@linux.vnet.ibm.com>
	<508904C4.7030409@linux.vnet.ibm.com>
	<508A6772.4040400@siemens.com>
	<508E2B98.4050700@linux.vnet.ibm.com> <508E33F5.2000001@web.de>
	<508E3ED6.5070605@linux.vnet.ibm.com> <5090BF35.6020101@web.de>
	<5090C6C9.2070403@linux.vnet.ibm.com> <5090C94C.8080808@web.de>
In-Reply-To: <5090C94C.8080808@web.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 3/5] Qemu: do not mark bios readonly
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: KVM <kvm@vger.kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel@nongnu.org, Kevin O'Connor <kevin@koconnor.net>, Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>, Liu Sheng <liusheng@linux.vnet.ibm.com>

On 10/31/2012 02:46 PM, Jan Kiszka wrote:

>> Please allow me to clarify it more clearly.
>>
>> The flash is ROMD device means guest can not write it, any kinds of guest write
>> access on this device can cause vmexit to kvm and return to userspace.
>>
>> We should pay more attention on it if we execute the code in ROMD since we
>> can not use ROMD as stack/page table/IDT table and all other implicitly write access.
>> Of course, if you do not use ROM as those purposes, it is okay. :)
> 
> So the problem is that there is KVM code that still blindly writes to
> guest memory and does not take the memory regions' protection flag into
> account? And we cannot mark those regions read only in the host's page
> table?

KVM has the ability to catch this kind of write access on ROMD, it is just hard to
emulate the implicitly memory access.