From mboxrd@z Thu Jan  1 00:00:00 1970
From: Fabrice Bellard <fabrice@bellard.org>
Subject: Re: Re: [PATCH 3/3] Add KVM support to QEMU
Date: Wed, 29 Oct 2008 15:16:09 +0100
Message-ID: <49087029.9020100@bellard.org>
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>
Reply-To: qemu-devel@nongnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Glauber Costa <glommer@redhat.com>, hollis@alumni.cmu.edu,
	Gerd Hoffmann <kraxel@redhat.com>, kvm-devel <kvm@vger.kernel.org>
To: qemu-devel@nongnu.org
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <49086E96.80809@redhat.com>
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>
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: 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.