From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KvBqR-0003ca-GH
	for qemu-devel@nongnu.org; Wed, 29 Oct 2008 10:16:23 -0400
Received: from [199.232.76.173] (port=55039 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KvBqR-0003c6-3Q
	for qemu-devel@nongnu.org; Wed, 29 Oct 2008 10:16:23 -0400
Received: from mx1.polytechnique.org ([129.104.30.34]:48235)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <fabrice@bellard.org>) id 1KvBqQ-0004sI-KV
	for qemu-devel@nongnu.org; Wed, 29 Oct 2008 10:16:22 -0400
Message-ID: <49087029.9020100@bellard.org>
Date: Wed, 29 Oct 2008 15:16:09 +0100
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU
References: <1225224814-9875-1-git-send-email-aliguori@us.ibm.com>		<1225224814-9875-2-git-send-email-aliguori@us.ibm.com>		<1225224814-9875-3-git-send-email-aliguori@us.ibm.com>		<49078707.5000109@redhat.com>
	<49078955.2090109@codemonkey.ws>		<5d6222a80810281604g39708040kf710725dce6413dd@mail.gmail.com>		<4907A1FA.2060106@codemonkey.ws>	<fb412d760810290651l5edf6c8cq1acf6a7be406f8eb@mail.gmail.com>
	<49086E96.80809@redhat.com>
In-Reply-To: <49086E96.80809@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Glauber Costa <glommer@redhat.com>, hollis@alumni.cmu.edu, Gerd Hoffmann <kraxel@redhat.com>, kvm-devel <kvm@vger.kernel.org>

Avi Kivity wrote:
> Hollis Blanchard wrote:
>> On Tue, Oct 28, 2008 at 6:36 PM, Anthony Liguori
>> <anthony@codemonkey.ws> wrote:
>>  
>>> Something I was thinking about this morning, and I think the first place
>>> where we'll definitely need a hook, is how to deal with
>>> kvm_load_registers().  I think there's overlap between KVM and the IO
>>> thread
>>> here.
>>>
>>> There are two reasons (I can think of) that most of the device model
>>> code
>>> can't run in conjunction with TCG.  The first is that TCG may modify
>>> CPUState in a non-atomic way.  The device model may need to access
>>> CPUState
>>> although there are very few places that it does.
>>>     
>>
>> Out of curiosity, where are those places?
>>   
> 
> local apic -- needs to access interrupt disable flag
> acpi sleep -- halts the current processor, so tied to cpustate
> vmport -- bad ABI requires access to registers

These accesses are the exception and should be done with specific CPU
methods. IMHO, direct access to the CPU state should otherwise never be
done from devices.

Regards,

Fabrice.