From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Date: Wed, 08 Feb 2012 17:20:37 +0000 Subject: Re: [Qemu-devel] [RFC] Next gen kvm api Message-Id: <20120208172037.615a1fdd@pyramind.ukuu.org.uk> List-Id: References: <4F2AB552.2070909@redhat.com> <4F2B41D6.8020603@codemonkey.ws> <51470503-DEE0-478D-8D01-020834AF6E8C@suse.de> <4F3117E5.6000105@redhat.com> <4F31241C.70404@redhat.com> <4F3141E4.8080902@codemonkey.ws> In-Reply-To: <4F3141E4.8080902@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Anthony Liguori Cc: Alexander Graf , Avi Kivity , qemu-devel , kvm-ppc , KVM list , linux-kernel > > 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. Who cares If your API is right this isn't a problem (and for IDE the guess that it won't happen you will win 99.999% of the time). In fact IDE you can do even better in many cases because you'll get a single rep outsw you can trap and shortcut. > But not all architectures offer non-word sized atomic instructions so it gets > fairly nasty in practice. Thats their problem. We don't screwup the fast paths because some hardware vendor screwed up that bit of their implementation. That's *their* problem not everyone elses. So on x86 IDE should be about 10 outb traps that can be predicted, a rep outsw which can be shortcut and a completion set of inb/inw ops that can be predicted. You should hit userspace about once per IDE operation. Fix the hot paths with good design and the noise doesn't matter. Alan