Messages in this thread | | | Date | Wed, 8 Feb 2012 17:20:37 +0000 | From | Alan Cox <> | Subject | Re: [Qemu-devel] [RFC] Next gen kvm api |
| |
> > 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
| |