[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F3BB41E.60405@redhat.com>
Date: Wed, 15 Feb 2012 15:33:18 +0200
From: Avi Kivity <avi@...hat.com>
To: Anthony Liguori <anthony@...emonkey.ws>
CC: Alexander Graf <agraf@...e.de>, qemu-devel <qemu-devel@...gnu.org>,
kvm-ppc <kvm-ppc@...r.kernel.org>,
KVM list <kvm@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Qemu-devel] [RFC] Next gen kvm api
On 02/07/2012 05:23 PM, Anthony Liguori wrote:
> On 02/07/2012 07:40 AM, Alexander Graf wrote:
>>
>> Why? For the HPET timer register for example, we could have a simple
>> MMIO hook that says
>>
>> on_read:
>> return read_current_time() - shared_page.offset;
>> on_write:
>> handle_in_user_space();
>>
>> For IDE, it would be as simple as
>>
>> register_pio_hook_ptr_r(PIO_IDE, SIZE_BYTE,&s->cmd[0]);
>> for (i = 1; i< 7; i++) {
>> register_pio_hook_ptr_r(PIO_IDE + i, SIZE_BYTE,&s->cmd[i]);
>> register_pio_hook_ptr_w(PIO_IDE + i, SIZE_BYTE,&s->cmd[i]);
>> }
>
> You can't easily serialize updates to that address with the kernel
> since two threads are likely going to be accessing it at the same
> time. That either means an expensive sync operation or a reliance on
> atomic instructions.
>
> But not all architectures offer non-word sized atomic instructions so
> it gets fairly nasty in practice.
>
I doubt that any guest accesses IDE registers from two threads in
parallel. The guest will have some lock, so we could have a lock as
well and be assured that there will never be contention.
--
error compiling committee.c: too many arguments to function
--
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